[sugar] Sharing data between activities.
Fri Aug 24 09:39:12 EDT 2007
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
> >> 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
> > like a really bad idea to me, given our space limitation
> > (independently from the fact that you want them share between
> > 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
> 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?
More information about the Sugar-devel