[sugar] Sharing data between activities.

[Carlos Neves]

Eben Eliason wrote:
>
>     >> - The images bundled are art done by kids on the MaMaMedia
>     site. They
>     >> are examples and can be trimmed down considerably, but they are
>     also
>     >> reasons to be proud for the kids that did them, so I guess that
>     if we
>     >> can keep the whole bunch, we will.
>     >>
>     >
>     > Installing a bunch of example images with the activity bundle
>     sounds
>     > like a really bad idea to me, given our space limitation
>     > (independently from the fact that you want them share between
>     multiple
>     > activities). Why don't we just make these available separately,
>     as a
>     > content bundle (.xol)? That way kids can install and uninstall these
>     > when they want through the journal.
>
>  
> Well done Marco!  I came up with this in bed last night and thought it 
> hit the nail on the head, excited to suggest it, and it was already 
> here waiting for me.  I agree with this idea. If the media is not an 
> integrated part of the activity itself, then a content bundle makes a 
> lot of sense, and eliminates the redundant data and other problems.
>
>     Well, that is by far the best idea I've heard on the shared content
>     issue! So I could provide the data as a separate bundle and kids
>     use it
>     from the Journal. And, if I can get my way with tagging and listing
>     stuff from the datastore programatically I can even keep the
>     categorized
>     view in the activities...
>
>
> I have to apologize as well, since I really haven't had time to test 
> out all of the various activities that are under development.  It's 
> truly fantastic that so many of the points I suggested in my little 
> example are already underway!
>
> That said, the one point I'm going to continue to fight for is to rid 
> the UI for these activities of any internal list of images altogether. 
>  The Journal is perfectly suited for tagging, starring, searching and 
> filtering everything (and will be accessible through a chooser), so I 
> really don't see a reason to require this bar.  Let the activity be 
> solely about actually doing the puzzle, and let the management of 
> images etc. be left up to our standard object chooser, which will be 
> consistent, powerful, and secure and save you the coding trouble and 
> screen real estate.
>
> Like I said, each puzzle is it's own object, so each puzzle should 
> really only need to have a reference to its own single image.  This 
> will give you more space, too, so that you can use the entire screen 
> area for putting the puzzle together.  The list of files is unneeded 
> fluff, since chances are I'm not going to change the picture on a 
> puzzle I've half completed.  If I did decide to do that I might as 
> well just create a new puzzle instance and start there, right?
>
> - Eben

Heh, you always make things sound so logical and obvious :)

Ok, so the suggested workflow has a somewhat deeper change than I had 
envisioned yesterday. You say that a half completed puzzle should not 
need to have it's picture changed.
Granted, that makes sense, but while searching for the correct image I 
may try multiple ones, so what I do with a timer is detecting a game 
action (moving a piece) to start it automatically, which is perfect to 
remove the button for opening a new image...

Open a puzzle, get a popup asking for the image (through the Journal), 
show the image in the puzzle. A button to 'Select another' is presented.
Start working on the puzzle, the 'Select another' disappears.
Drop an image on a new puzzle loads that image.
But what if you drop an image on a running puzzle? Do I:
- save the current state and open the new image
- request that a new instance is spawned (will I be allowed to?)
- ignore the drop.
- Open the new image as if the puzzle activity had been started anew.

What do you think would best fit the intended UI workflow?