I got two activities. When I jump from first to second activity and then come back to first one, the activity gets recreated in some phones. Can anyone tell me how to prevent it?
I don't believe you can prevent it. If you have some state to save, consider saving it. If you need things to keep running in the background, consider using a Service.
You can't stop the recreating from an App, but you can save your state in onSaveInstanceState(Bundle) and retrieve the state in onCreate(Bundle) or onRestoreInstanceState(Bundle).
It's the intended behaviour, and you shouldn't be trying to stop it. But, as mentioned by gnobal, you will need to save the state, and recreate your data to handle these situations properly.
Some phones with low memory, will always do that. A good way to test your implementation is to go to "Developer options" and enable "Don't keep activities".
Related
When do not keep activities is checked under developer option of android device then after on pause onDestroy called for that reason I am unable to get resume my activity. Is there any solution to ignore do not keep activities is checked or unchecked to avoid calling onDestroy. Thanks in advance for help.
No, there isn't. If your app doesn't restore properly after being destroyed you just need to fix it. Save your state in onSaveInstanceState() and restore in onCreate(); move any data loading out of the activity; etc.
Without seeing code, all I can say is read up more on the Activity lifecycle and make sure you're handling it properly. If you are, then it shouldn't matter whether or not this option is selected -- your app should behave the same way.
I am trying to simulate Activity and Fragment re-creation and also to check onSaveInstancestate() and onRestoreInstanceState() and generally so check if I am handling activity re-creation in a good way in all cases, for example, just like when screen rotation causing the activity to re-create it self.
But in my case I want to check more options/cases which can cause re-creation because my app cannot be rotate(all activities are in portrait).
I saw many articles, blogs and stackoverflow question/answers about this topic, for example here, here, and here.
And as this stackoverflow answers says Why not use always android:configChanges="keyboardHidden|orientation"?
there are many more events which can cause activity re-creation, so after I read it I wanted to test my app for some of those events.
For example I pressed the home button in my activity and then I went into settings and tried to change the language, change the font size , etc... , but non of those actions made my app re-create as I would expect.
When I returned to my app , it just resumed and onCreate() never called.
So I even check the official documents about this. and they also says that it should cause my activity to re-create: Quoting:
"When a configuration change occurs at runtime, the activity is shut down and restarted by default"
but as I said it didn't happen to me.
This is I huge for me because I was very naïve and thought that if my app will be only in portrait or if I will add to the manifest this line :
android:configChanges="keyboardHidden|orientation|screenSize"
then every thing will be ok and obviously its not because there are many more configurations changes which can restart my activity, so I can't run from it anymore and I want to handle it in a good manner and now I want to also test it.
Changing the device language is one way to force re-creation of all activities that doesn't involve orientation change.
You said that it wasn't being recreated when you change the orientation of your device while in the app. Normally it would. When you added the lines android:configChanges="orientation" it means that you're telling the system you will deal with orientation changes in your app and not to worry about the normal behaviour.
If you remove that from your activity declaration in the manifest, you'll see it operating as expected (destroying/recreating on orientation change).
Hope that helps.
Pressing the home button will only initially cause onPause to be raised. Your Activity will not go through onCreate again until it has been fully destroyed, which won't happen unless Android decides it needs the memory for other processes.
The easiest way is just to remove orientation from configChanges and then rotate your Activity and see what happens. The layouts might not work correctly, but your should be able to inspect your lifecycle code. Similarly, remove keyboardHidden and then toggle the soft keyboard. Your Activity should go through the lifecycle sequence.
Changing the locale for the device should cause your Activity to be recreated. Note that this is the global locale that needs to be changed, not the language the keyboard is typing in.
Other ways come to mind such as manually destroying the app either via a key sequence on the phone (for example, holding down the Home button and swiping left on the app to kill on some phones), or by terminating it from your debugger.
On your device/emulator Developer Options, activate the option:
"Don't keep activities".
With it on, anytime the activity is paused and returned the cycle for saved instance is called (e.g. another activity in front of it or home button pressed to minimize all apps, ...). It's useful to test and simulate recreation and related bugs.
I'm having an issue with an android app I'm writing that seems like it should be a common issue but I can't find any information on it.
I have a scoreboard activity in my app that just stores a grid of scores in textviews, it's the kind of thing that the user will update, then hit the back key and look at some other activities, then come back later to update it, leave again, etc...
The problem is that every time they leave and come back the whole activity gets reset, losing all their scores. I can't use saveInstanceState because it isn't called on back key pressed. I really don't know where to go from here except for saving thew hole grid in sharedpreferences, I feel like there has got to be a better way though
Any ideas?
In general, you need to save any state information in onPause(), and recover it in onResume().
I was under the impression that various state information is kept automatically when you close the App, and automatically restores itself when start it back up again (until Android removes the App from its memory to make space, calling onDestroy()).
If I were you, I would store the grid in SharedPreference. It really is the most reliable solution.
You can also use the details in this topic:
https://stackoverflow.com/a/151940/503508
May this help you
When the user presses the BACK button, your foreground activity is destroyed. That activity will be called with onPause(), onStop(), and onDestroy(). That activity object will then be garbage collected (unless you introduced a memory leak).
onSaveInstanceState() will be called periodically if there is a chance that the activity will be destroyed shortly but in a way where the user might be able to navigate back to it. The prominent case for this is during a configuration change, such as rotating the screen.
What you should be doing in onPause(), if anything, is persisting data using "sqlite, file saving and other persistance methods". Once onPause() is called, there are no guarantees that this activity will stick around, or that your entire process will stick around. Anything you value, therefore, should get written out to persistent storage.
The "state" for onSaveInstanceState() would be things that affect the activity's UI but are not part of the persistent data model. Much of this is handled for you automatically by Android's built-in implementation of that method (e.g., the text in an EditText), but you can add your own information to the Bundle if you wish. However, your instance state is not your data model, so anything you want to stick around needs to be written out to persistent storage.
As you all knows all android activities create, start, resume, run, pause, stop, destroy. This process is shown well in the android manual.
In this lifecycle is there any possiblity to understand activity is created which way? I mean how can I understand whether activity is called directly or activity is created once then killed by android os and then recreated since user navigates back?
More basically how can I understand whether an activity is in its second life or first life?
Edit: Why do I need this?
In my design I have a main page where the data is loaded from the net. And when the user clicks some details, it puts the data in a static object just like session in web. This works well normally.
But when a user starts detail activity in second life, he data in static object is killed, and I got nullpointer exception.
I have 4 projects having same architecture so I want to solve this problem.
You've already got the flow chart information there. You can always keep some state for later use by storing the fact of your Activity's demise during onDestory() or similar. Then, the next time your Activity is resumed, you will know if you were actually destroyed or just stopped. I don't think you get any of that information for free from the OS, since it's not supposed to matter in the ideal case.
you should not distinguish between these, since even after it has been destroyed (at least the method has been called) it might "come back" just in the state as it was when it was destroyed. Which could be different than from the very initial state when it was created the first time.
Please explain the reason why you need this - you should "rethink" your issue, since Android is really behaving "strange" concering this question.
It is better to design your project livecycle according to Android system behaviour - which is actually not documented anywhere regarding this point (at least I have not come accross any good doc so far)
If I understand your question, you want to know when your activity has been destroyed by the OS or when it has only been paused. Simply use logcat statements:
onPause() {
super.onPause();
Log.v("Activity", "Paused");
}
onDestory() {
super.onDestroy();
Log.v("Activity", "Destroyed");
}
You can do the same for onCreate(), onResume(), anything really.
I dont think putting finish() in onPause() is cutting it.
I have a Location activity and it is proving very hard to test, what I would like to do is be able to, when I leave the activity, completely destroy/kill any existence of it. So that when I go back, both when I leave the app or just the activity, everything is new, there is no cache, nothing and it has to start all over again.
The reason being is I don’t want it to remember Last Know Locations, they are not useful in this app, all I want is the current location and if it can’t be found, it can’t be found.
Cheers,
Mike.
This gets into some deep discussions about how android manages activities and memory and all kinds of things which you probably don't want to think about.
If you are currently trying to finish the activity in your onPause method (sounds like a horrible idea to me since your phone will call this whenver your screen goes to sleep -- after about 15 seconds of inactivity depending on your settings). But if that really is what you want to do then why not just make the call to get the last known location in your onResume method?
Put finish in onPause and in manifest add this for that activity android:stateNotNeeded="true"
so it want remember your last state on relaunch of that activity
For solving this problem you can use preferences for storing the data and you can use it for future.