[Sugar-devel] Killing activities when memory gets short

[Lucian Branescu]

On 9 August 2010 11:25, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 09.08.2010, at 01:21, John Gilmore wrote:
>
>>> As long as activities are saving and restoring properly it could be
>>  made pretty much transparent to the user. Of course that's easier
>>  said then done...
>>
>> Android has a whole mechanism for this:
>>
>>  http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html
>>
>> That explains the problem, but doesn't explain the Android answer
>> to it, which is here:
>>
>>  http://developer.android.com/guide/topics/fundamentals.html
>>
>> The section "Component Lifecycles" gives the summary.  They call each
>> app's onPause() method when it is obscured from visibility on the
>> screen, and that method is responsible for recording everything the
>> app needs to restart itself and get back to the same screen display
>> (what file it was working on, how far down the file it was, etc).
>> Then, any process whose onPause() method has been called is considered
>> a cache, and can be killed without warning by the kernel.
>>
>> (I'm not advocating using this system -- I've only barely been
>> exposed to it.  But it's useful to see how others have solved the
>> problem you're facing, before making your own solutions.)
>
> 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.
>
> - Bert -
>
> (*) 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.

On Android, all (good) apps always save their state. There may be some
bad ones, but all the ones I've used do it properly. Since apps are
made out of activities (views) connected by intents, all the
activities in an app save state. When starting an app, the main
activity decides what to show (saved or new state) or it can switch to
another activity that was active when the app was killed.