I recently launched my first iPhone app and it seems to have people in the Android community asking for it ... so I started developing w/ the SDK.
The first thing I noticed is that in my iPhone app I would store certain session wide variables in the appDelegate. As I don't have this structure in Android I'm curious how Android developers keep track of application state across the app (hopefully w/out a ton of singleton objects?)
If the singleton object approach is how most developers do this - how can I ensure the application starts at a clean state each time the user clicks the "home" button and re-clicks icon (is there something I can add to my manifest to ensure it doesn't support multitasking in this way?)
My app has a lot of session specific state and for the first iteration won't yet support multitasking :(
First, android app can consist of multiple Activities.
If you want to share state between Activities use Application class: How to declare global variables in Android?
If you only have one Activity, then you can save state there.
Beware: when activity is not Active (it's GUI not showing) it does not mean that it is killed. So if you use your app and then close it, open another app, then go back to you app, it might be still "alive" (kept in memory) and the state would be preserved.
The best way to handle this is to hook into Activity lifecycle. Then you can set/reset data at will.
If you want to close the app when the user hits the "home" key, you can call finish() into your onPause method.
See this link:
Killing android application on pause
I find Singletons to be the best way to retain application state in Android applications. You can listen for when the user leaves the application through the onPause() and onStop() methods of the currently focused Activity, and do whatever you want with your data at that point. It's not good practice to try to override the OS's lifecycle management of your application (e.g. trying to kill your process when Back is pressed). If you want the app's state to reset every time the user leaves the application (via pressing Home, or being interrupted with a phone call or notification or what have you), simply put all your session data in the Activity itself. When the user leaves it will be destroyed and recreated when the user returns.
There are obviously specifics that I don't know about your application, but once you get familiar with the lifecycle of each screen (Activity) and of the application, you'll be able to use the callbacks to manage your state however you see fit.
http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
Related
As far as I know, an app that is already destroyed by Android System resides in recent apps. For example, I launched my app and navigated through several activities. Then quit, and opened several other apps and not launched my app again for several hours. My last opened activity will stay in the recent apps even though it has been destroyed by the system. My question is what life-cycle methods will be run when I touch my app from the recent apps list and in which order? Also what will happen to my data in the activity that is still shown on the recent apps? Does it get created from the start? Do I still have an activity stack? and will my base application class be re-created also?
According to LifeCycle of an activity, after your app will be killed by the android OS (to get memory for more prioritized apps), your activity will start from onCreate() method, and go through the cycle, as usual) What about your data:
values in views (like EditText) will be restored if your view have ids.
your variable values I suggest you to save and restore with onSaveInstanceState() and onRestoreInstanceState().
There is two scenario here:-
If your app still in recent apps much time and other apps need memory your app will be killed by Android OS, and if you open it again it will start from splash-screen.
If your app stayed short time in recent-apps without need for memory the last activity you used will be opened, starting it's lifecycle from onStart().
Once you press home button It will call onStop without destroying it unless OS or user do.
I have an app, a single activity app with fragments in it.
The usual use case for this app is, that you start it and put the phone away and every now and then, you get back to the phone and insert some data... It's a logging app, you are doing something and insert your results into the app...
I have the problem, that every now and then, my activity get's destroyed and is recreated with an empty bundle... (Most of the time this is not the case, but every now and then this happens...). My app sometimes starts a service, even this service is killed in this case...
This means, that the system has killed my app, does it? How can I avoid this?
I need to keep the user data and the current top fragments... And they are saved to the bundle and everything works as long as their states and the data get saved...
Btw., my activity is always the TOP ACTIVITY, only that the screen turns off often... I just want to keep my activity alive as long as possible until the user leaves it with the back button... Or to save the state reliably
IMPORTANT NOTE
onSaveInstance does not always work (it's not part of the lifecycle and therefore not guaranteed to be called)... it only works most of the time... I need a way to that works always... If android kills my app...
don't keep your app in memory
You don't want to block Android from killing your app. What you want is to restore your app's state properly. Then the user will never notice the app has been destroyed and the user still gets the benefit of an app that was destroyed when not in use.
If you really want this use a wakelock. This will drain your users battery so I think twice before implementing this... Info at How do I prevent an Android device from going to sleep programmatically?
onSaveInstanceState explained
To do so check what information is needed in the bundle and persist that information with the onSaveInstanceState(bundle:Bundle) method so you can reuse it in onCreate(sameBundle:Bundle).
More information available from Google documentation at Save your Activity state and Restore your Activity State.
About Android Activity lifecycle
As stated by #prom85 in the comments below it's not guaranteed that the onSaveInstanceState method will be called because it's not part of the lifecycle. Workaround for this is using the onPause lifecycle hook to ensure your data is stored.
More information at Android: onSaveInstanceState not being called from activity
I had a similar problem, I arrived at this post while searching for a solution, you have to play with the manifest to achieve this and also understand what exactly activity is, in Android eco system,
In Android activity is a task which has a pre defined work.
I dig a lot in the documentation, I found that, we can configure activity in two ways,
Persistent
non persistent
if you mention for the activity in the manifest as
android:persistent="true"
and run the below use case
Start the APP
Press back or home button
you select the activity in the back stack again to bring it to front
Activity enters start -> pause -> stop - > resume , it does not get into onDestroy method.
if do not mention
android:persistent="true"
for the same use case
Activity enters start -> pause -> stop -> destroy, and if you select the activity from the back stack
Activity enters resume->create->start
If you want to run a service/task on activity start which keeps running when the app is in back stack, then you have to start that in the onCreate method, and kill them onDestroy by specifying your activity as persistent in manifest.
I hope my above solution might help others who arrive here for the same problem
I have an offline-online application, i found a strange issue in it, may be it is not, but i did'nt understand about it..
App requirement is that, if internet is available, even from starting app or from resuming, i call webservices and store data in sqlite, otherwise app stays in offline mode,
I have 2 activities, second activity contains an id, that i passes through intent (that point is important),
My Problem:
if i am in second activity, and internet is running, and i press home button , then this 2nd activity pauses, then stop which is a default behavior in android, i goto settings, turn wifi off, then press app icon again to get back in my app, here i got confused, i expect that my app now will be in onResume, but when i see in logcat its onCreated called and app
crashes, nullPointerException occurs, because this 2nd activity does not have that id, i passed through intent..
Note:
If i use recent app button to go to "settings", then come back again after turing wifi off, and repeat all this behavior, then working fine, its onResumes called not oncreate..
My Question
Why it is going in onCreate while i my expectation is to be onResume while i came back from app icon?
The NPE reason is clear, your second activity doesn't have the value and it crashes.
Why do you get different behavior then!?
It's because the launching intents are different. When you "task switch" Android is merely stopping your app but leaving it there (no guarantee) in case you want to switch back.
Going home (with home) is a clear indication that you want to leave the app, and although it will remain in memory and cached (as long as there is available memory), going back through the launcher (or App Icon as you call it) fires the LAUNCHER category (which goes to your Activity 1 first).
Take a look at this StackOverflow question (and answer) to better understand the consequences.
In any case, your problem is that your app must always be designed to resume in an inconsistent state and be able to recover. Android will kill your references, will destroy your variables and most likely send your app to hell overnight even if you have it running… if the phone goes on standby, chances are processes that aren't doing anything will be paused/stopped and likely killed.
Re-design your app so this is not a problem.
You say:
"I have 2 activities, second activity contains an id, that i passes
through intent (that point is important),"
Well, why not make it easier and have ONE activity and TWO fragments? Then use Fragment Arguments to pass the value?
Or why not store the value in the preferences and/or a local database and recover it during onCreate?
And also why not make it so that if Activity 2 doesn't have a value, it calls Activity 1 and closes itself (better than a crash, huh?).
Etc.
As you can see there are multiple things you should consider. All in all, never trust that your app will be alive, because it won't.
Once your activity's onStop gets called it's susceptible to be killed by the android system to collect resources for other apps which is what i think happened in your case.If it is killed, android will obviously call OnCreate when you get back to the activity.Check this for clarification. For experimenting you can try opening more than one apps from your recent apps and then return to your app. It may crash there too now.
You stated that you can see that the activitiy is stopped (onStop) if you go to the settings. That is the behaviour shown in the Android activity lifecycle. The counterpart for onStop is onCreate. So it does what the documentation tells us. Btw activities are paused if they are visible in some way and get stopped if they are not visible anymore. This would explain why your activity get paused. For further information read Managing the Activity Lifecycle. You can find a whole picture of the lifecycle here.
This type of behaviour can be seen when you change some system configurations like font type,font size or language. But turning wifi on/off won't destroy the app and recreate it again. Check http://developer.android.com/guide/topics/manifest/activity-element.html#config for more information
I made this app that works fine, but when i leave the app and open it again it always force closes. how can i make it so when the user presses the home and or back key it will kill the app process?
Making it so when the app is opened again it has a fresh start.
You are not supposed to "kill the process". You should handle home button presses and other such interactions that navigate away from your app via the onPause() and onResume() methods.
In your onPause() method, you should save the state of your app. This can range from saved it in Bundles, SharedPreferences, sqlite or whatever form of persistence is appropriate for your app.
In your onResume() method, you should restore the state of your app so that the user is given an illusion that nothing has changed at all.
This is how android handles multitasking and this is how you must accommodate it within your app as well to efficiently and reliable suit your app to the android framework.
I suggest you go through the activity life cycles guide here first:
http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
More on pausing and resuming an activity specifically here:
http://developer.android.com/training/basics/activity-lifecycle/pausing.html
Also, you might want to read up on data storage options here:
http://developer.android.com/guide/topics/data/data-storage.html
I am seeking short characteristic of Android Multitasking. I have found, that when you minimize Android application, it is ended and it's process remains on the background. When user wants to reuse his app, this process alive it's application. User will be at the same state, when he left (if there was enough memory while working with it), or it will be loaded from scratch, because there was no free RAM for other work and Android exited this process. Am I right? Everywhere there are articles with 20 pages and more about Android multitaksing. I need to know key points because I am lost in a such long artices.
Thanks
Short Answer: Yes. If your app can live in memory despite being 'closed' then it will stay in RAM and processing will continue when you click on it again. Otherwise it will be restarted and you will get an onResume().
Long Answer: Please just read the Activity Lifecycle:
When Android activity is covered by other windows it will enter into paused state and method onPause will be called. It may also me destroyed by OS and then onDestroy will be called. You have very little control over it and can't expect your application to come back up with the same state. However, when activity is brought up again to foreground in will go through steps of onCreate and onPause. Those methods can be used to restore its state.
Here you can find nice diagrams describing Activity lifecycle. Similar but slightly different lifecycle is applicable to service.
http://developer.android.com/reference/android/app/Activity.html
Android activities are the main visible screens that user see while the application is running. If you close the screen or switch to another application, the current activity is put to hibernate and you can save the state with
Activity.onSaveInstanceState(Bundle bundle)
After your activity gets the control back, you can restore the state with
Activity.onRestoreInstanceState(Bundle bundle)
Note that you need to be careful not to store any context references within the activities and related classes as the activity and thus context has changed between pause and resume. Instead, you should always pass the current activity as the active context to avoid having exceptions from invalid context.