<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Take my specific use case: I have a Slider Puzzle and a Jigsaw Puzzle.<br>These are two separate activities, but both have bundled images, the
<br>same bundled images. It is somewhat desirable to share the images across<br>these activities (and other on the make) because not only of the space<br>constraint but also to allow for easier upgrading of the image set, not
<br>being dependent of applying the upgrade to all activities (assuming<br>that&#39;s the only case).</blockquote><div><br class="webkit-block-placeholder"></div><div>Well, I see it being perfectly acceptable to bundle half a dozen or so images in each activity, the same or otherwise. &nbsp;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&#39;t be necessary in the first place. &nbsp;Take advantage of the tool and the kids&#39; desires to create things.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">As for the code sharing, well, it just makes sense to me to keep it<br>packaged that way, but since space is of much lower importance here, I
<br>could easily create a common code repository and just import that on<br>each activity, thus keeping things in sync. Just thinking out loud...</blockquote><div><br class="webkit-block-placeholder"></div><div>That would work. &nbsp;The point is, I might for instance get really frustrated by slide puzzles; &nbsp;I could think they are impossible and never want to open it a second time. &nbsp;Jigsaws, on the other hand, I may love. &nbsp;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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Still have the shared &#39;My Own Image&#39; problem though. This is a<br>collection of (links to) images the user has selected from the
<br>filesystem. Assuming the user will be allowed to upload files from a<br>thumb drive or the internet into the XO&#39;s journal, I can dump the<br>filesystem access. But for keeping the images I need a single, shared<br>
list of objects to be found on the datastore. This could, I guess, be<br>itself an object in the datastore, assuming I can create a single<br>object, searchable by some id and metatype, which is not presented in<br>the Journal.
</blockquote><div><br class="webkit-block-placeholder"></div><div>I think I&#39;m missing an aspect of this argument. &nbsp;First, you will have access to the filesystem via an &quot;import object&quot; type palette (provided by the OS itself via an API being worked on). &nbsp;Furthermore, you&#39;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. &nbsp;In that way, you will be able to ask for references to images the user selects from their collection. &nbsp;You should also certainly support drag&#39;n&#39;drop of images directly onto the puzzle.
</div><div><br class="webkit-block-placeholder"></div><div>I don&#39;t really think it&#39;s necessary to keep a list of these images though. &nbsp;I&#39;ll take more photos, make more drawings, and get tired of the old ones eventually. &nbsp;Also, it&#39;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. &nbsp;You could likely let the slide puzzle be good at puzzling, and leave the file/list management stuff out completely.
</div><div><br class="webkit-block-placeholder"></div><div>I especially don&#39;t see any reason that the jigsaw puzzle should need to know what image I placed in the slide puzzle activity. &nbsp;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&#39;t ever need to know what each other are doing.
</div></div><br><div>- Eben</div><div><br class="webkit-block-placeholder"></div><div>PS. &nbsp;I&#39;m also aware that some of this may not have been known to you at all. &nbsp;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.
</div>