[Sugar-devel] A prototype of SugarWeb / SugarAndroid - Technical questions

[Daniel Narvaez]

On 14 November 2013 10:03, Lionel Laské <lionel at olpc-france.org> wrote:

> Here are the major issues I've faced building the prototype (all source
> code is here [2]):
>
>
>
>    - Multiple copy of Sugar Framework in each activity. My work was
>    mostly a way to group existing Sugar Web activities. BTW I need to upgrade
>    a part of the Sugar Web Framework to implement few features (Stop button,
>    XO Colors, …). This upgrade concern today the bus.js file (most of the hack
>    is here [3]) but this file is copied in each web activities :-( So I had to
>    upgrade this file in each activity directory. I think we must find a way to
>    allow the Sugar Web Framework to be deployed/referenced one time only.
>
>
You could put them outside the activities directory and change the
loader.js to look there.

Though ideally we would add the activities as git submodules and avoid
making any change to them... I can't think of a good way to dinamically
adjust the loader on both Sugar Linux and Sugar Web though. You could check
the protocol or the user agent I guess, but it feels like a pretty bad hack.

Consider if you really want all the activities to always use the latest
version of the library. When you make an API change you will need to fix
all of them. Volo makes it pretty easy to update the local library copy,
I'm not sure we really need a global library here.

>
>
>    - Server side stuff. Today the Sugar Web Framework use Web Sockets to
>    communicate with the system layer. It's good when running on Sugar but it's
>    not a good idea in a Web-Browser only world because you can't have a
>    process to listen Web Sockets. I think we should imagine a way to have a
>    Sugar Web Framework that could work in stand-alone mode (without any server
>    side). For example by using directly LocalStorage instead of waiting for a
>    bus call. It's what I've done to retrieve xocolor [6]
>
>

I wonder if we should first just fork sugar-web, implement the ideal API
for Web/Android there and later figure out how reconcile with Linux.
Reconciling is going to be a bit tricky I think, even more without a clear
idea of what API we will need for Web/Android. (Thinking of the datastore
mostly).



>
>    - HTML5 compatibility issues. Running existing Sugar Web Activities on
>    tablets (XO Tablet and Samsung GalaxyTab) raise some issues regarding HTML5
>    compatibility. Specifically some features (CustomEvent object, Blob object, window.webkitRequestAnimationFrame,
>    …) used by the framework or by activities don't work everywhere due to
>    WebKit compatibility. I think we should isolate these features (or avoid
>    using it).
>
>
Yeah or use them conditionally.

Perhaps we need to choose one or two target browsers initially, being
compatible with everything is going to be a lot work or too limiting anyway.


>
>    - Of course one another major issue is that the screen size could be
>    very different from a device to another. Unfortunately activities are often
>    linked to the XO screen size.
>
>
It would be good to come up with a set of strategies to do layout on
multiple screen sizes and document them. Manuel figured out some of that
stuff if I remember correctly.


>
>    - Environment. The Sugar Web Framework use an environment object
>    (env.js), it seems to be used to detect the current platform but that I
>    don't understand exactly how it works. Any explication regarding this point
>    will be appreciate.
>
>
It's a way for the native python activity to pass some  initial environment
variables to the web layer (like the activity id and the datastore object
id). As for bus.js etc I would fork and get rid of these initially, then we
can figure out the best way to reconcile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131115/83f89d78/attachment.html>