I have a problem with Activity life cycle. In my server communication Activity I am downloading the list of items from the server and then setting up the Adapter for the ListView.
Everything is fine but if I press Home button on this screen and after some while (e.g. 3 hours or more) return back to the screen via application manager, application crashes. The problem is in the onTextChanged() method (which is usefull for searching via EditText) where I am calling the setAdapter() method again. There is nullPointerException because my array was somehow erased.
Why is the onTextChanged() method called again during restoring? And why was the array erased?
Thank you for your help.
Please check the activity lifecycle diagram on:
https://developer.android.com/reference/android/app/Activity.html
Your Activity goes to Pause state after you press Home.
And after 3hrs or even a shorter time,it may be killed by system for resource management.
So it need to be created again on next launch.
I think you should add code to handle onDestroy() and onStop().
Retrieve the data the same way you did originally, by overriding the
onResume()
method, checking if the data is existent or not beforehand.
Related
Hi I have gone though activity lifecyle on many threads, but I could not find what we should do in onStart, onResume, onPause method of the activity.
In the onStart() method, you add code that's relevant at the beginning of the activity.
Let's say, you have an app that reads the temperature of the device's battery. You'll want to have an initial value, so as to show the user.
So in the onStart(), you'd add code that goes ahead and fetches the information you'd need, and displays it for the user, before your timer (for example) goes and reads the information a minute later.
The onPause() method is called before the application goes in to the background.
To stay with our example, in the onPause() method, you'd save the last recorded temperature to the device; so you can show a comparison when the user next opens the app.
The onResume() method is called when the application is brought back to the foreground (i.e.: you've gone to the task manager, and tapped on your app to show it again).
Again, staying with the going example; in the onResume() method, you'd go ahead, read your saved data, load fresh data, and show a comparison of the two in the application.
Then, when your timer ticks next, only fresh data will be shown.
Your question is a bit vague, so answer might not be super specific..
I would say there are no strict "rules" around what we should do in corresponding activity lifecycle methods.
In fact, you can do nothing there (just make sure you call super method if you decided to override those). I.e. your custom activity might not even override these methods - it will work just fine.
onStart, onResume and onPause methods are just hints to you about activity lifecycle change, so you can react accordingly, i.e. start/stop specific to your activity operations at the appropriate time.
For instance, when onResume is called it means that activity became fully visible to the user, so you might want to start some animation (if necessary)
Again, you are not obligated to put any code in there.
Usually most of the operations are performed within oncreate and onresume.
However for your info let me brief it out,
Onstart- this is called after Oncreate, once activity is visible to the user, if you want to perform some operations before the visibility do it in Oncreate, because most of codes should be operated before user views the activity.
OnResume-Be cautious on Onresume is it is quite tricky it will be called whenever you activity is brought to foreground.
Onpause-Called before Onresume, codes wont be executed here, so strictly avoid adding codes in Onpause instead add inside Onresume.
Hope it helps,
I have a MainActivity and a second Activity which has an EditText. I want that the content of EditText always gets saved. However I don't want a EditTextChangedListener which writes a file after 1 char has changed.
What is a good solution? I thought about onPause or onBackPressed.
What about the home button? I think the app remains open, so is there any need to save? And what about other interrupts like phone calls? Does onPause catch all that?
Thank you.
Yes onPause gets called whenever your app gets interrupted or goes to background check Activity life cycle
A good solution is to include such logic in the onPause() method. It will always be called in all situations. This is what the developer documentation says:
you should use the onPause() method to write any persistent data (such as user edits) to storage.
One thing you should keep in mind is that this method may be called more frequently than desired, for example, when your screen light goes off (some ppl have 15sec screen light timeouts). So, you should not put in too many expensive operations inside there.
As for pressing of home button, it is recommended that you save the data (at onPause()). The reason is that your activity is in the background but it may get destroyed. The system may destroy the activity if it needs to reclaim the memory. (For example you start too any other apps afterwards and put them all in the background) From the documentation:
Stopped: The activity is completely obscured by another activity (the
activity is now in the "background"). A stopped activity is also still
alive (the Activity object is retained in memory, it maintains all
state and member information, but is not attached to the window
manager). However, it is no longer visible to the user and it can be
killed by the system when memory is needed elsewhere.
No. The correct answer here is to listen for the "return" key event. That signifies that the user has completed input to the field, and trigger the save of the field contents to the file. It's useful in many other circumstances too.
See this answer: Android Use Done button on Keyboard to click button
Peter.
I need to know when an application finishes to stop all the local services that it starts.
How can I do it?
You could try using onDestroy() (not recommended, though) to know when Android is cleaning your app from the memory. or can also use onStop() to know when the Activity is being sent in the background.
Do implement these two methods in the first activity of the Activity stack.
Lets see if it helps, since I also haven't tried it so far.
One idea is to use BoundService despite the fact that it's your app own service. By definition Bound Service stops when the las connection is dropped.
Another idea would be to define count in Application object (you can override global Application object). You can increment the count in each onResume and in decrement in each onPause.
You could use try / finally on the main function and do the service clean up in the final block
You could use object finalizer to issue shutdown commands. You wont know exactly when it happens since the Garbage collector will run at its own pace, but you do know it will happen eventually.
I am now solving the same problem, I have an Idea and will implement it:
1.static variable called (String currentShownActivity).
2. in every Activity (onResume() ) I fill the variable with activity name). So when I navigate between the activities the currentShownActivity variable changed and carry the current activity name.
3. on every onPause(), set flag that indcate the activity onPause() called (i.e boolean IsPauseCalled)
4.in onStop () check IsPauseCalled, and the activity name.
if the activity onPause called and the name in currentShownActivity not changed (that mean we leave the activity to "no activity") and that mean [home] key pressed.
the integration way to know the the application is not running Check onDestroy of the main activity.
I have finished the Layout exercise and wondering why they include the call to populateFields() in both onCreate and onResume.
According to Activity Lifecycle "onResume" will always be performed before the Activity is shown so why not just there?
I have real production code that populates fields and is only called in onResume and it works just fine.
I thought one reason would be that maybe onResume is called after the activity is shown, but a bit of googling digs this (mostly unrelated) thread:
http://groups.google.com/group/android-developers/browse_thread/thread/ddea4830bedf8c6c?pli=1
Quote: onResume() is thus the last thing that happens before the UI is shown
This is what Dianne Hackborn says so i guess we can trust her :)
Actually I have seen apps (in my app and also others), where fields were only populated in onCreate(), but not in onResume().
Lets call that app 'A'.
The effect was that when the user pressed the home button, went to a different app, and then returned to 'A', the screen stayed black, as 'A' was still in memory and thus the system did not bother to call onCreate(), but directly went into onResume().
So basically I'd say (and this seconds what #Torp wrote) populate the UI in onResume() and be done.
But then, this answer is slightly off-topic as it does not answer your "why" question.
You don't populate in onResume because it will be called every time the activity is shown.
You generally want to create as few objects as possible, so you create them once and for all in onCreate, and then you can always check that they are still updated in onResume.
I have two activities. One loads all rows from a database, and the other saves to the database. When I have the second save in onStop and the first repull the data in onResume, they do it out of order (the first resumes and then the second saves). I managed to fix this by putting the saving data in onPause, but why was this happening? Was this the cleanest way to do it?
Doing the save in the first actvity's onPause should be fine.
You've discovered that the foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time, the activity is in front of all other activities on screen and is interacting with the user.
When you start the second activity, onPause is called on the first and then interactive control switches to the second, with onStop on the first to be called somewhat in background.
This improves responsiveness and gets the new activity in front of the user ASAP. Consequently, you should try to keep your onPause implementation as fast and efficient as possible.
See the following Android docs for more details on the lifecycle http://developer.android.com/guide/topics/fundamentals.html, but what you have found should work fine for you.
Some official quote as an add-on:
The Activity documentation states that
onPause() is where you deal with the user leaving your activity.
Most importantly, any changes made by the user should at this point be
committed