Recent Updates to Sugar Almanac

[James Simmons]

Faisal,

Look at the code for the Read activity.  It never creates a Journal 
entry itself.  What it does is to resume from a directory entry created 
by downloading a PDF through the Browse activity or perhaps one copied 
from a USB key using the Journal activity.  So there *is* a file in the 
Journal entry, but there is no desire to update that file.  If you have 
that situation you can save metadata without writing a file, just like 
Read does.  No special code is needed.

Metadata not being preserved across a reboot is a known bug.  Metadata 
not being preserved for entries on SD cards and USB keys is a 
*feature*.  These devices are not considered part of the Journal proper, 
although the current UI makes them *look* like they should be.  There 
are good reasons to treat files on USB devices differently from Journal 
entries.  I understand that the USB and SD parts of the Journal may be 
given a different look to avoid this kind of confusion.  I don't know 
when this will happen.  The developers who could do this have a lot on 
their plates. 

If you have no data file, it would be a good idea to use a file to store 
persistent information about options, etc.  The only time you wouldn't 
do that is when you have a file in the datastore that must not be 
modified, as in the Read activity.

James Simmons


Faisal Anwar wrote:

> Hi James,
>
> Thanks for the feedback. I had two follow up questions for you or 
> others who are in the know with datastore:
>
> 1. You said: 'However, if your application is like Read, Read Etexts, 
> or View Slides, which are always resumed from existing Journal 
> entries, there is no need to write a file.  You can still save 
> metadata, even if you don't write a file.'
>