[sugar] Sharing data between activities.

[Eben Eliason]

>
> 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).


Well, I see it being perfectly acceptable to bundle half a dozen or so
images in each activity, the same or otherwise.  I would say that, with a
camera on the laptops and an emphasis on creation, the more common case
should be to let the kids drop a drawing of their house or a picture their
family anyway, so bundling a large set of default images shouldn't be
necessary in the first place.  Take advantage of the tool and the kids'
desires to create things.

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...


That would work.  The point is, I might for instance get really frustrated
by slide puzzles;  I could think they are impossible and never want to open
it a second time.  Jigsaws, on the other hand, I may love.  By keeping these
separate, I can simply delete the slide puzzle activity, thus saving all
that space, including that the shared code and images would take up anyway.

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.


I think I'm missing an aspect of this argument.  First, you will have access
to the filesystem via an "import object" type palette (provided by the OS
itself via an API being worked on).  Furthermore, you'll be able to provide
a list of MIME types that you want to accept, so that the object chooser
presents only a list of images, and nothing else.  In that way, you will be
able to ask for references to images the user selects from their collection.
 You should also certainly support drag'n'drop of images directly onto the
puzzle.

I don't really think it's necessary to keep a list of these images though.
 I'll take more photos, make more drawings, and get tired of the old ones
eventually.  Also, it's just as easy to reselect one from before, via the
same palette, than to require some sort of file manager within the slide
puzzle activity itself for tracking those.  You could likely let the slide
puzzle be good at puzzling, and leave the file/list management stuff out
completely.

I especially don't see any reason that the jigsaw puzzle should need to know
what image I placed in the slide puzzle activity.  There might be some
instances where the lack of shared space will take more effort to overcome,
but I think these are two separate activities and shouldn't ever need to
know what each other are doing.

- Eben

PS.  I'm also aware that some of this may not have been known to you at all.
 Things are moving fast, and documentation is a bit behind, but I assure you
these things, such as a pretty cool file importers for specific types of
media, will come down the road.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20070823/8f9671b3/attachment.htm