> 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. > (*) 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
