[IAEP] Sugar on Android via HTML5

Walter Bender walter.bender at gmail.com
Thu Sep 12 20:48:22 EDT 2013

On Thu, Sep 12, 2013 at 7:54 PM, John Watlington <wad at laptop.org> wrote:
> On Sep 10, 2013, at 5:04 PM, Sameer Verma wrote:
> On Thu, Sep 5, 2013 at 7:51 PM, Caryl Bigenho <cbigenho at hotmail.com> wrote:
>> One of the things that makes Sugar the ideal learning platform for
>> children (and youth) is the wonderful compatibility of so many of the
>> Activities ... both from Activity to Activity and from student to student.
>> This facilitates the sort of learning we are all hoping to see more of...
>> creative problem solving, project based learning and cooperative learning.
>> Without this ability to integrate parts of projects, it would just be
>> another collection of apps.
> I did not want to muddy the picture by injecting my own viewpoint, but now
> that I've heard from others (on and off list) it is clear that the split is
> driven by the role they play in the ecosystem.
> Most technologists have come up with reasons why they don't think a complete
> Sugar experience would work on Android. Therefore, activities must run like
> any other app on Android. On the other hand, as Caryl said, "Without this
> ability to integrate...it would just be a collection of apps".
> Somewhat knowing the limitations of what can be done with Sugar stuff on
> Android, but disregarding that for a minute, I would say that Sugar as a
> *platform* is an experience. It has a UI. It has a UX. Everything from the
> Zoom interface to the activities to the Journal is Sugar. We have taken the
> original "Sugar on the OLPC XO" experience and replicated that to the
> classmate PC, SoaS, and other spins and distros, but in none of these cases
> did we break the holistic Sugar experience. Now, along comes a popular OS,
> and because the tech parts don't fit, we are advocating breaking up the
> pieces and taking whatever flies. Memorize will become one of the few
> hundred thousand apps on Android.
> I disagree.
> It's like saying we'll do the cat sprite from Scratch, but nothing else.
> It's like saying we'll do the birds and pigs from Angry Birds, but not the
> slingshot. Sugar, without all its pieces isn't worth the trouble.
> Sameer,
>    I disagree somewhat with your thesis (and am very glad you started this
> discussion.)
> From a technological standpoint, it is actually probably easier to implement
> what you describe:
> Sugar as a monolithic Android application, which takes over the entire user
> interface when
> launched.   The reason I never considered it seriously was the larger
> ecosystem.
> The reason to move to Android from Linux is two-fold:
> - Chip vendors are dropping Linux support in favor of Android.   The cheap
> chinese ARM
>  vendors only support Android.
> - Android/iOS are where application development is happening.  There is a
> much larger
> community of Android developers than Linux or Sugar developers.
> The hope was to provide the infrastructure underlying Sugar (the Journal
> datastore and
> collaboration) as Android services, encouraging their use in new Android
> applications.
> In this model, the Journal is another Android application, accessing the
> Journal datastore service.
> New Sugar activities written in HTML should be capable of running in Sugar
> on Linux
> or as Android activities (although perhaps with different execution
> wrappers).
> In this manner, perhaps we can enlarge the Sugar community with developers
> mainly
> targeting Android.   If we pursue Sugar as a single Android application,
> with embedded
> Python activities, we are isolating ourselves from the Android community.
> The danger of this approach is the loss of an integrated UX.  This could be
> addressed
> by customizing the home UI, in the same manner that the XO tablet has a
> custom home UI
> implementing the Dreams interface, but that would require "rooting" the
> tablet in some manner.
> But the native Android UI isn't that bad...
> Cheers,
> wad
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel

My two cents:

To add to Caryl's point about tools vs applications, there is no
reason why we can port the tool-like nature of the core Sugar apps to
Android. Solving the datastore problem means we can interoperate
between objects with these tools... a Sugary approach that is largely
missing in Android.


Walter Bender
Sugar Labs

More information about the IAEP mailing list