Monday, June 24, 2013

Re: [android-developers] Re: Handling process killed by system

I think the documentation intentionally stays abstract on what happens
when the process is killed. I agree it's sort of strange this isn't
explained better, but in reality using statics in Android is usually a
bad idea for the reasons that have been described.

I agree with Piren, you should serialize state inside some other
facility unless you want to roll your own persistence code.

Kris

On Mon, Jun 24, 2013 at 5:08 AM, Benoit Vermont <redwarp@gmail.com> wrote:
> Well, I agree that using a singleton is a mistake. But, I think that the
> documentation is rather shallow, and should maybe explain the "process being
> killed" behavior more thoroughly. I mean, when you read the documentation,
> nothing let you guess that your singletons will be deleted, while the stack
> of activity and bundles are saved. (If it's said anywhere, I still havent
> found it).
>
> I will rewrite everything for persistance, but still think it would be best
> if the documentation explained a bit more...
>
>
> --
> Benoit Vermont
>
>
> 2013/6/23 Piren <gpiren@gmail.com>
>>
>> Seems to me your mistake is storing the information as a singleton... why
>> save everything in memory where it is volatile? store everything in a
>> database and you wouldn't have to worry about it being gone or using too
>> much memory. There's no reason to limit the user's ability to complete an
>> order to the current instance of the app... and then make a complex
>> workaround to allow the information to traverse instances.
>>
>>
>> On Friday, June 21, 2013 5:25:33 PM UTC+3, Benoit Vermont wrote:
>>>
>>> Hi, I've been reading intensively the Android Application Framework FAQ
>>> (http://developer.android.com/guide/faq/framework.html) and it says that the
>>> system can kill process if needed to free memory.
>>>
>>> Well, fair enough, only it also destroys singletons and static instances.
>>> So when we launch the application back after that, it tries to restore
>>> itself, but fails miserably because all static singletons are no more
>>> available.
>>>
>>> What bugs me is that the same documentation (Framework FAQ) specifically
>>> says : "You can take advantage of the fact that your application components
>>> run in the same process through the use of a singleton. This is a class that
>>> is designed to have only one instance. It has a static method with a name
>>> such as getInstance() that returns the instance; the first time this method
>>> is called, it creates the global instance. Because all callers get the same
>>> instance, they can use this as a point of interaction. For example activity
>>> A may retrieve the instance and call setValue(3); later activity B may
>>> retrieve the instance and call getValue() to retrieve the last set value."
>>>
>>> But it's not so true, as these singletons are not reliable at all.
>>>
>>> I mainly use singleton in my apps to store session variable. But some of
>>> this variables are quite complex (it can be information about the user,
>>> trees of object, etc). For exemple, I'm working on an ordering application
>>> that stores in a singleton a map of stuff the user wan't to buy. This maps
>>> is complex, it could also store information such as "what kind of shipping
>>> option does the user want", etc...
>>>
>>> But let's say I start the app on a cheap device (with low memory), I
>>> start shopping, but I then receive a call from a friend, I hang up, then I
>>> forget what I was doing, and launch Angry Birds, and then "hey, that's
>>> right, I was buying stuff", etc... I go back to the application, and the
>>> singletons don't exist anymore.
>>>
>>> Okay, looks like it's a bad idea to use static. But the FAQ is
>>> misleading, is it not ? The singletons are not really persistant : Once the
>>> order is finished, they are gonna be destroyed straight away.
>>>
>>> I guess that if running the app on api level 14 or more, I could use the
>>> onTrimMemory method from the Application class
>>> (http://developer.android.com/reference/android/app/Application.html#onTrimMemory(int))
>>> to save/serialize my singleton there, and when the application is
>>> relaunched, and the singleton is null, restore it.
>>>
>>> But what would be the good/best/not so sucky way to handle with
>>> not-really-persistant-but-it-might-be-nice-to-exist-one-hour kind of object
>>> ?
>>>
>>> Thanks.
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to android-developers@googlegroups.com
>> To unsubscribe from this group, send email to
>> android-developers+unsubscribe@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Android Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/android-developers/DnA7Z0pjSnI/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> android-developers+unsubscribe@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-developers+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home


Real Estate