[sugar] Sharing data between activities.

[Carlos Neves]

Eben Eliason wrote:
>
>     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.
That is also part of the game design, and the whole experience we're 
targeting.
>
>     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.
But if you don't dislike any of the now 2, but potentially more 
activities that share images between them, you'll end up having a lot of 
wasted space, but of course the file hashing and linking would take care 
of that.

What about if the activity, on first start, would feed the images to the 
datastore (the ones not already there) and then delete them from the 
activity installation folder? This would solve both the image sharing, 
update syncing and space saving issues all at once, while also making 
the images available to other activities such as Paint and the like?
>
>     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.
Think of 'My Own Images' like Bookmarks are on a browser. You don't 
store the content, you don't see the whole set of available data, you 
just mark them as 'cool'. Maybe there is tagging in the datastore 
objects and I never crossed it? That would work really great and without 
ever needing to do special kungfu or corner cases.
>
> 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.
It's a 'personal preference' thing, the bookmarks. You really like that 
image of an XO completely dismantled, so you use it for everything... 
but then again, maybe user tags would work better? If the user feels so 
inclined, he/she/it can tag images and apply that as a filter when 
selecting an 'external' image.

There is an extra piece of information I didn't give you, which is the 
fact that images are categorized. I have a folder that holds folders 
(categories) that holds images. You have a list of categories presented 
to you and a separate widget that holds one image of the selected 
category and has left/right arrows to walk through the other. 'My Own 
Images' is a special category.

But by putting our images in the datastore and allowing for filter by 
tag, there's a good chance the interface has to be rethought.
>
> - 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.
Yes, I've been aware of that for some time now, and I learned it the 
hard way :) The Mesh support has been somewhat of a moving target for me.

Thanks,

Carlos Neves
cn at sueste.net