On 9 August 2010 14:44, NoiseEHC <noise...@freemail.hu> wrote: > >> Sugar has a similar mechanism. From the Low-level Activity API docs: >> >> org.laptop.Activity.SetActive(b: active) >> Activate or passivate an activity. This is sent when switching activities, >> there is only one active activity at a time, all others are passive. A >> passive activity must immediately release resources like sound, camera etc. >> Also it should prepare for being killed without warning at any time in the >> future (see OOM) by auto-saving to the datastore. >> >> The issue is that it's hard to estimate how many Sugar activities actually >> do this, because until now they usually have not been killed (*). Might be >> an interesting test - just randomly kill activities from Terminal and see if >> they resume correctly ... >> >> Maybe "good" activities could "volunteer" to be shut down first. Or "bad" >> activities would have to "beg" to live a little longer. Might just take an >> entry in the activity.info file. >> > > It will not work, because the application startup time is horrible on > the XO. The Dalvik VM goes a loooong way to have fast application > startup and to share most of the memory among applications (the Zygote > process does this). Actually that was the exact thing I tried to do with > the Python VM. Just at the exact time when I started to hack Python I > have seen the Google I/O video about the Dalvik VM and thought that > duplicating that work would have been a waste of time. So if you wanna > fix the Python VM, good luck, but you know it is already been coded... > :) Without fast activity startup, killing activities will be a horrible > user experience. Maybe not that bad as a totally unresponsive XO though.
It wouldn't be a duplication of efforts since Dalvik does not run Python and it is unlikely that it ever will. Perhaps a simple fork zygote for python wouldn't be that hard to accomplish in the sugar shell. > >> (*) Apple seems to have foreseen this "developer psychology" issue and >> actually killed all apps in the first three iterations of its iOS. So apps >> had to implement this state saving if the user was to be able to continue >> after leaving an app. Would be interesting to know how many Android apps >> actually implement it. >> > > All of them. If an Android application does not implement it correctly > then there will be big problems while switching apps and while > navigating among application screens. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
