I have a singleton that contains some data that I want to hold globally for the app.
I know that if the user has navigated away from my app, and if the system needs resources it will kill my app (or just the activity, not sure). Then if the user opens my app again, it will restore the activity and wil have save the local activity variables automatically.
Will this process also restore the static variables that were set in my global singleton class out side of the activity?
No. Only what is in your saved instance state Bundle might be restored if Android terminates your process, and then only if the user returns to your app relatively quickly (say, within 30 minutes).
The saved instance state Bundle is mostly for "in flight" data (e.g., partially-filled-out forms) that you would not mind losing if the user does not return to you for a while. For anything else, save the data yourself, whether to local storage or "the cloud".
If you want to save the state of that variable you can either save that in sharedpreference in your onPause method of an activity and then retrieving that variable again in your onResume method
Related
So, as far as I have understood, once the App is not destroyed and is in the background; if the OS requires more memory the OS kills the app but saves the state (onSaveInstanceState). And when we re-open the app, it would seem like we are facing our previous activity but it actually has been destroyed and created again. If my interpretation is correct, how does the App retrieve the saved state? Does it store it in memory? For how long are we able to retrieve the saved state?
If my interpretation is correct, how does the App retrieve the saved
state?
From the Android documentation
If the system destroys the activity due to system constraints (such as
a configuration change or memory pressure), then although the actual
Activity instance is gone, the system remembers that it existed. If
the user attempts to navigate back to the activity, the system creates
a new instance of that activity using a set of saved data that
describes the state of the activity when it was destroyed.
Regarding your second question - it's the implementation detail how the OS does it and it's actually shouldn't worry us :). What's important is that it should do it reliably.
The system will keep the saved state as long as the user doesn't press Back or finish() of your Activity is not called.
The OS stores it. It calls onSaveInstanceState to let you generate a Bundle it stores, and will call onRestoreInstanceState to let you restore yourself from the state. How the OS stores it doesn't matter- maybe it saves it in RAM, maybe it serializes it to disk. What is assured is that if you go back to that activity you will be passed a Bundle object with the information you previously filled in. You do not need to retrieve the state- if it exists it will be passed to you.
I know that a Bundle can be used to pass data between activities, as well as for saving and restoring data in cases of configuration changes like a screen rotation.
I also read that SharedPreferences is the preferred way to store persistent data, rather than a Bundle.
Why exactly is this the case? In order for a Bundle to handle a configuration change, it would have to persist even after an activity is destroyed. So what exactly is the lifespan of a Bundle? Is there a certain point where it arbitrarily gets eliminated by garbage collection, or does a Bundle's data persist for as long as you don't manually choose to clear it?
Bundle lasts while the Activity exists, aka it has not been finished.
An interesting fact to note is that when process death occurs and Android massacres your application and the Application class is recreated (onCreate() is called), then the Activity stack is reconstructed, and the activity is reinitialized from the saveInstanceState bundle.
The SharedPreferences literally stores the data you give it in an XML file in the data/<applicationname>/preferences folder, if I remember the location right.
SharedPreferences are for simple persistent settings storage. Like the home page on a Browser that should be available every time the user opens the app. These are just key:value pairs designed to hold simple things.
Bundle is a way of storing data to either pass to another Context (another Activity, Service, etc) or to save and restore your own current state in onSaveInstanceState and onRestoreInstance state. This data is NOT persistent and used while the application is in use.
I have implemented onRestoreInstanceState and onSaveInstanceState. They both work successfully when the app is minimized (by pressing the home button, or another activity is in the foreground). However, when I minimize the app and the kill the process (by opening the list of current processes and ending that one) the app does not restore the saved instance state. How can I make it restore that saved state? Is my best option to write the savedInstanceState bundle to a file using serializable (thus having something stored that on the hard drive, rather then RAM), then reload the savedInstanceState from the file?
How can I make it restore that saved state?
You can't. That's not what the saved instance state is for.
Is my best option to write the savedInstanceState bundle to a file using serializable (thus having something stored that on the hard drive, rather then RAM), then reload the savedInstanceState from the file?
Your "best option" is persistence, such as a file, database, or SharedPreferences. Your specific approach seems odd.
Saved instance state is only for temporary information, such as the contents of a form that the user has filled in but not yet submitted. Anything beyond that does not belong in saved instance state, but rather in some sort of persistent data model. This is no different than building a Web app, where the data that you have in your DOM and JavaScript variables are not going to live forever, but instead need to be store somewhere (typically on a Web server).
It's probably too late for the answer, but you can save state (and it will survive the process killing) with SavedStateHandle from Android Jetpack.
See more here:
https://developer.android.com/topic/libraries/architecture/viewmodel-savedstate
What is the best way to maintain session information across multiple activities?
The question What is the best practices on Android to keep data between activities deathes/restarts for the whole application session? has some ideas, but does not really help me.
*My application has multiple activities with the manifest tag singleTop. They essentially work as different tabs - they each maintain their own set of fragments and back stack and so putting it all into one activity would break navigation for the user.
I am currently saving the session data as a static singleton created by my Application subclass. This works fine most of the time, except when the entire application is killed by the OS to save memory (as mentioned in the above link), say, when the user gets a call on a device with low RAM.
The only notification the app has that it is going to be killed (as far as I know) is
Activity.onSaveInstanceState(Bundle outState)
So the problem is this: onSaveInstanceState will eventually be called on every activity, not just the top-most one (the one that will appear when the user eventually returns to my app). When each non-top activity resumes, I could use Activity.onRestoreInstanceState(Bundle savedInstanceState) to restore my singleton session, but non-top activities would have old copies of the data (they may have been navigated-away from long before the user got the call).
One solution would be to only restore data to the singleton session Only if it is currently empty, but this relies on the first activity to receive Activity.onRestoreInstanceState being the top activity. This is not always the case - if the user gets a call and then returns to the app via the launcher icon, then the Main activity will be resumed first and brought forward, not the activity the user was on when they got the call.
A simple notification in the Application class that the application is being killed by the OS (not the user) is really what I need - I would then save the session to a file, and read it back on the first call to Activity.onRestoreInstanceState, but AFAIK this doesn't exist.
If you have some data that you want to store when app closes and reload them when app starts, you can have a mechanism to store and retrieve them on application's shutdown and startup. To do this override onStop() and onStart() methods on Activity's lifecycle.
And I think the best way to store and retrieve data in these two methods is SharedPreferences.
I would simply insist to use Application class to save the session. Using Application class you will be able to access the session everywhere were you are having Context so probably you can access in your whole Application. Application class also maintains the value after you Application is closed so its better to clear previous session when your Application is re-launched.
As the main use of Application class is to maintain global state of variables so that they can be used throughout the Application with updated values.
When I want to save some state behavior of the activity, The docs says that we should implement OnSaveInstanceState and OnReceiveInstanceState.
They say that this will save the activity state even after destroy or restarts. I care more about destroy (the activity is completely gone) , does that mean the bundles are considered persistent ?
when I open a pdf reader, clost it and open it again i see that it opens in the same page I was in. is this implemented using Bundles or oth
To store persistent application data use Shared Preferences. Shared Preferences are simply sets of data values that are stored persistently. By persistence, we are talking about data that persists across application lifecycle events. In other words, the application (or device, for that matter) can be started and stopped without losing the data. The next time the user launches the application, that data will still be available.
Some Games use Shared preference for exemple to store the level of the game reached, the player's name ...
see this link to learn how to use Android Preference API
Preference are simular to bundles However they are persistant and bundle are not!!
Keep in mind that if you need to store persistent data you have 4 options to do this:
Using Shared Preferences
Using SQLite Databases
Using Internal Storage
Using External Storage
Bundles are not persistent, the documentation says not to count on it, onSaveInstanceState() is called when the activity is about to be killed by the system, but for a known restart (for
instance on a screen rotation.) If your activity is killed because the system needs more resources (while the
activity is in the background), onSaveInstanceState() will not be called, but onPause() will. onSaveInstanceState()
really is not meant to save persistent data, as the doc states.
You can sorta consider SavedInstanceState() permanent but it's not recommended to use it for saving application related data in a persistent manner as It's not guaranteed to be called and it's not recommended by the authors themselves.
so, Only use them for saving user interface state changes (background color, currently selected items ,..) and use other method for persistence like : SharedPreferences, Files and SQLite.
Bundles are not persistent, and the documentation for them specifies that using them for persistence is not a good idea as their internal format may change between devices or even OS versions.
SharedPreferences, on the other hand, can be persisted and are the recommended way to store information like current app state.
Some relevant parts from SavingActivityState
:
Note: There's no guarantee that onSaveInstanceState() will be called before your activity is destroyed, because there are cases in which it won't be necessary to save the state (such as when the user leaves your activity using the Back button, because the user is explicitly closing the activity).
There is no guarantee data will be stored, especially in the case where your user exits the app.
Note: Because onSaveInstanceState() is not guaranteed to be called, you should use it only to record the transient state of the activity (the state of the UI)—you should never use it to store persistent data. Instead, you should use onPause() to store persistent data (such as data that should be saved to a database) when the user leaves the activity.
So like K-ballo said, used SharedPreferences if you have persistent data to store. onSavedInstanceState() is mostly useful for storing UI related data.
As every one else has recommended use shared preference and you should do this saving in onDestroy and onSavedInstance both.
When android is going to run low on memory, its just going to kill your application and call your onSavedInstance without calling onDestroy etc. Save your context in bundle it passes in onSavedInstance. When your app comes in foreground again, android will take care of restoring your back stack of activities. But this time it will pass you the bundle in your onCreate for each activity which will have all the values you saved in your onSavedInstance while your app was getting killed.
Hope this helps.
Short answer: It's not permanent.
Long answer: From "Android Programming - The Big Nerd Ranch Guide":
When onSaveInstanceState(...) is called, the data is saved to the
Bundle object. That Bundle object is then stuffed into your activity’s
activity record by the OS
...
So when does the activity record get snuffed? When the user presses
the Back button, your activity really gets destroyed, once and for
all. At that point, your activity record is discarded. Activity
records are also typically discarded on reboot and may also be
discarded if they are not used for a long time.