I am using Singleton pattern. When application goes into background the OS kills the app to release memory. When user comes back to app my application starts from same Activity User left off but my singleton instance is not available because it was released too when OS released memory.
Suppose I am at Activity 5 and I have values int a = singleton.getInt() it will give me a null pointer exception. Other local views initialized are null too. But if my application restarts from splash screen then its all good because app flow is starting from scratch. Sometimes it starts from Splash, some times it goes to Activity 5 or whatever activity User left off (which will cause null pointer exception). I have used a lifecycle Observer to monitor application state in MainApplication but what exactly is the root of this issue. Any ideas?
Why does this happen?
When the system kills your application to free the memory it saves a few pieces of data about the current state of your Application into the internal OS storage. Later on, when the user opens your app once again, the system takes that saved data from the storage and tries to restore the state of the Application.
The reason for that behavior is to make the user experience smoother. By restoring the state - the user can quickly continue doing things he was doing before quitting your application.
Some of the data that is stored in the OS storage:
Activities back stack (back stack of the Task)
FragmentManagers back stack
Bundle that you saved in the onSaveInstanceState methods
Please note: ViewModels are not saved between application re-creation. Even though they are saved upon Activity recreation(configuration change, such as screen rotation). So data that you store inside of your ViewModels (if any) would be lost!
In order to support this OS feature and ensure a smooth user experience in your application, you must design your application to not depend on any Launcher Activity to instantiate your singletons and instead use some other architectural approach that would not require your Launcher Screen to launch every time the application restarts.
What can you do?
You could try one of the following:
Save all the user input data (if any) to the Bundle in onSaveInstanceState method.
Migrate from Splash Screen Activity or Launcher Activity in favor of the Reactive approach to data instantiation.
Move your Singleton instantiation to Application class. Note: This could significantly increase the launch time of your application.
That is by no means an exhaustive list of actions you could do. I bet you would have better ideas that are applicable to your own application.
If migrating away from Launcher Activity is not possible at the moment, I suggest adding to your Activity onCreate method a check that everything is instantiated and ready to use. If not - immediately navigate the user to your Launcher Activity.
Please note: It would be good UX to save back stack and navigate back to the current activity as soon as your logic on Launcher Activity is done working.
I've noticed an odd behaviour in an app I'm analyzing and I would like to know if this is by design or it's simply a bug of the platform?
I have a complex application but to simplify my example lets say I have an application with Activity A and B. Now if I run my application and go from A -> B, given that I won't finish Activity A, then I will kill the process (but the app window is still visible in Recent applications) then if I tap the window in recent apps what would happen is:
1) Process is being created
2) Application object is being created
3) Stack is untached (A -> B) and after analyzing it by the framework Activity B is recreated
4) Activity A is "dead" untill I hit the back button
Now the interesting thing happens if I introduce a large singleton instance, lets say an instance of "Dictionary" which can hold many key-value pairs. If that dictionary instance is large enough the above scenario will not happen, meaning that the stack appears to be cleared and my application will follow a typical launch scenario so Activity A is being created instead of Activity B.
Is this a proper behaviour of the Android Framework and if so... why is that proper? I'm interested in the reason and why this occurs.
I found and read a lot of articles talking about global variables in Android, some of them suggests using an subclass of Application + declare it in the manifest file as a glbal variable container.
But some articles mentioned that This class could also be killed when system memory gets low, is this correct?
So, is it 100% reliable to use an Application subclass as a global variable container? And could somebody give me a link to some documents explaining the life cycle of an application in Android (not activity)?
EDIT:
Thanks for the answers, I think I need to explain a bit more of my question.
The situation is, I just want to share a global String variable, Activity A modifies it, and activity B reads it.
When B is currently visible and user receives a call,
If A and B are killed but Application keep untouched (is this what Google calls an empty process?), I'm OK with it.
If A, B, and Application class are all killed and when user come back my app gets a clean start, I'm OK with it.
Which I'm not OK with it is, everything was killed including the Application class, when user come back my app doesn't start fresh, I mean, it starts from Activity B, will this happen? then should I start A manually or let Application class to do the initiation? none of these ideas looks good to me...
The answer is both "YES" and "NO" - the Application class can be used as a "global variable container" in that all activities and classes can rely on it.
However, you cannot rely on the Application class (or any other class) to persist indefinitely. In other words, if the user answers their phone, your application could be destroyed and then re-created when the user completes the call and returns to your app. So, you definitely cannot rely on it to persist data, but you can rely on it to provide global access to data when you app is active.
This is the Android documentation:
http://developer.android.com/training/basics/activity-lifecycle/index.html
This is a really good post on it - read the SECOND highest voted response, in addition to the "accepted" response:
Using the Android Application class to persist data
It explains pretty clearly how your app can be killed/destroyed whether you expect it or not.
EDIT:
To clarify, if you have a variable (call it "myVar") in the Application class and a user sets it in Activity A, then proceeds to Activity B, Activity B will be able to read the change.
If Android "destroys" the application class, which can occur anytime the user is not in your app (and in rare instances even if they are...), the app will be reconstructed so that the Activity Stack is still valid but "myVar" is not set, unless you persist the data.
In other words, Android will recreate the Application class and Activity B, but there is no guarantee that it will recreate Activity A until the user does something to destroy Activity B. Also, it will certainly not "replay" the user actions in Activity A in order to recreate the app state, and in your case that means "myVar" is not reliable.
If you read the references provided, you will see that this is the case (and also I have tested it).
EDIT 2:
To persist data, consider SQLite (which is pretty complicated and there are many references) or SharedPreferences:
How to use SharedPreferences in Android to store, fetch and edit values
This class could also be killed when system memory gets low, is this correct?
Yes.
So, is it 100% reliable to use an Application subclass as a global
variable container?
If you want to use it to pass values it is not reliable.
why?
EDIT:
Which I'm not OK with it is, everything was killed including the
Application class, when user come back my app doesn't start fresh, I
mean, it starts from Activity B, will this happen?
yes. It is possible that you set a value in your application from activity A and then when you are in Activity B user leaves your app and after a while android kills your process. then user comes back wants to look at your app. android again recreates application and activity B but not Activity A and instead of fill the application variable with what has passed Activity A to it, it recreates it from default initialization. So simply you missed what has passed or set by Activity A.
Don’t Store Data in the Application Object
Please help me to resolve this problem.
1 > I am having application which Uses Service to retrieve data from server.
2 > Now on Pressing Home key and i have opened new application..
3 > I have opened around 20 application.
4 > So my application might go out of memory stack.
5 > now i am resuming my application, application crashes as i am opening activity of my
application which is not in the stack.
Is there anyway by which i can handle this exception and redirect my activity to Homepage or relaunch application resume and is not in stack...
Indeed a very good question which I try to puzzle out myself.
I even wonder What's the difference between killing an app and restarting the phone.
If a user manually kills an app or opens 20 other apps, he'd probably want the app to start from the beginning.
Why Android aren't restoring state after phone restart?
Also, I see that when an app is killed (by the system), global variables turn to null upon activity reinitiating.
This kind of breaks the concept of Java. If you have some kind of state in the application and the application erases it, I would expect the application to restart.
The solution I propose:
1. Handle the case of a state problem: Initiate a simple state (new Object()) as a global variable. For each Activity, in the methods onCreate/Start/Resume check that the state is null. If it's null launch the first activity with 'Intent.FLAG_ACTIVITY_CLEAR_TOP' - as if the application is relaunched.
2. Try not to use global variables - Always put data in the intent.
3. Lazy load global variables - If you do want to use global data, don't count on one time initialization. Lazy load them 'if (A.MY_DATA == null) {A.MY_DATA = new ...}' - Don't forget to do it in the background if it will take a long time (AsyncTask). Loading partial state needs to be done carefully because it may not comply to other loaded state objects.
The downside of the first point is that the state problem handling needs to be done on every Activity (AOP is not yet implemented in Android).
Hope that helped.
Use SharedPreferences for save Application state
Often when I open my Android app from either my Home screen shortcut or from the apps menu it restarts the main activity.
How can I prevent this behavior and make it bring the existing instance to the foreground if there is one running?
I've searched quite a bit to no avail. It would seem as though most others are not having this problem?
Thanks!
You can never assume that Android retains the state of your app after you move away from it - because of a low memory situation, it may have removed it from memory.
Your best bet is to store the current state (including the current activity) in your SharedPreferences, and in your main activity (the one marked as LAUNCHER in your manifest), you check the shared preferences and go to the activity marked there. You can also use the SharedPreferences to store other information about the activity, i.e. you can use it to fill out text fields and other things with whatever values they had when the user left.