[sugar] Sharing data between activities.

[Carlos Neves]

Eben Eliason wrote:
>
>     I think you're attempting to solve a non-problem, however. The
>     activity installation system will take care of not downloading (and
>     not storing) duplicate information, based on file hashes. Making
>     three activities that all incorporate the same shared files is
>     sufficient; the OS will make sure no space is being wasted by storing
>     multiple copies. If you really want to manage things yourself, you'll
>     need to package up all three activities as one activity whose
>     frontend is the launcher.
>
>
> Actually, we're avoiding the launcher system in general, including the 
> concept of "intro screens" which brach a single activity instance into 
> a number of pseudo-independent ones. The self-contained bundle 
> structure was chosen for a number of reasons, and despite the 
> possibility of some shared data taking up extra space (though it seems 
> even that may be taken care of), it makes things a lot simpler. 
> Foremost, we explicitly want to avoid dependencies between bundles; no 
> activity should ever require the presence of another to run.
>
> - Eben
>

Take my specific use case: I have a Slider Puzzle and a Jigsaw Puzzle. 
These are two separate activities, but both have bundled images, the 
same bundled images. It is somewhat desirable to share the images across 
these activities (and other on the make) because not only of the space 
constraint but also to allow for easier upgrading of the image set, not 
being dependent of applying the upgrade to all activities (assuming 
that's the only case).

As for the code sharing, well, it just makes sense to me to keep it 
packaged that way, but since space is of much lower importance here, I 
could easily create a common code repository and just import that on 
each activity, thus keeping things in sync. Just thinking out loud...


Still have the shared 'My Own Image' problem though. This is a 
collection of (links to) images the user has selected from the 
filesystem. Assuming the user will be allowed to upload files from a 
thumb drive or the internet into the XO's journal, I can dump the 
filesystem access. But for keeping the images I need a single, shared 
list of objects to be found on the datastore. This could, I guess, be 
itself an object in the datastore, assuming I can create a single 
object, searchable by some id and metatype, which is not presented in 
the Journal.

---

Carlos Neves
cn at sueste.net