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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
