Is read_file() always called after an activity __init__?

[Tomeu Vizoso]

On Thu, Feb 28, 2008 at 10:56 PM, Gary C Martin <gary at garycmartin.com> wrote:
> >> It does seem like read_file() is only triggered if you have
>  >> previously
>  >> saved an actual file to filesystem, if you just have metadata, no
>  >> call
>  >> is ever made to read_file() so it's a rather bad place to pick-up the
>  >> metadata. At least this is what I'm seeing here – I've just created a
>  >> 0 size file in my write_file() and now a resume from that journal
>  >> entry is triggering read_file() every time.
>  >
>  > You are right again. Perhaps we should add a read_metadata() method?
>  > An alternative would be to have a 'datastore-loaded' method, but that
>  > would be less consistent with the current API.
>
>  Hmmm, so if my activity needs it's preferences before it can display
>  anything to the user, potential future lazy loading of the data-store
>  (to try and speed up general activity start-up time) is going to leave
>  folks watching my activity with a blank screen for a lazy while? Ouch.

Well, metadata loading shouldn't be as slow as for the user to notice.
But if you add this to all the other initializations, it is
significant. Also, the user wouldn't see a blank screen, just startup
will be (say) 100ms slower than for an activity that can start without
reading the metadata.

>  > But the determining reason would be that metadata properties other
>  > than the custom ones are not preserved across reboots :/
>  >
>  > http://dev.laptop.org/ticket/4662
>
>  Oooh thanks, double ouch, I hadn't spotted that gotcha yet!
>
>  I'm getting the distinct feeling I should avoid current metadata
>  interactions by an activity (too flakey and in transition just now)
>  and just create a custom preference like file format, it only needs to
>  store two key/value pairs at the moment, probably will eventually need
>  only half a dozen at the most for future display options. Though I
>  guess even that's still going to be a problem if lazy data-store
>  loading is ever implemented (though every activity that needs to load
>  a file for display will suffer there).
>
>  Leave the metadata alone for the Journal and lower level activity
>  class behaviours.  Pity, metadata looked like a nice solution for
>  storing simple custom activity state information, maybe in update. 2...

Right, metadata in journal entries was thought exactly for that. Using
some other kind of preferences file may be the best for now.

Regards,

Tomeu