I have an app sort of like a browser, so I don't control the javascript that runs inside the pages, some of it might be looping like crazy and wasting battery. Also video or audio might be playing. I want all that to pause when the user leaves my app for another app. To do this I call webView.onPause() and webView.pauseTimers(). I tried only doing onPause but depending on what pages I had loaded my battery would still run down. As you might know, pauseTimers applies to all webviews so that means any ads I might have stop loading.
So for this reason I want to call pauseTimers only when my activity is being paused because the user is leaving the app, but not when the user is leaving my activity to go to another activity in my same app, because it might have ads.
So can I know when my activity is being paused because the user is leaving the app?
Thanks.
You should override Activity.onUserLeaveHint()
Called as part of the activity lifecycle when an activity is about to go into the background as the result of user choice. For example, when the user presses the Home key, onUserLeaveHint() will be called, but when an incoming phone call causes the in-call Activity to be automatically brought to the foreground, onUserLeaveHint() will not be called on the activity being interrupted. In cases when it is invoked, this method is called right before the activity's onPause() callback.
http://developer.android.com/reference/android/app/Activity.html#onUserLeaveHint()
Have you tried re-implementing the onPause() method? You can analyze the stacktrace in order to get some clues.
Also, this link might help you:
http://developer.android.com/training/basics/activity-lifecycle/pausing.html
Override the onPause method in your actvity.
#Override
protected void onPause() {
super.onPause();
//Do whatever you want to do
}
Related
During my testing, I have not found a situation where onStart() runs without onResume().
If someone could shed light on this topic as this is the closest question I've found, but none of the answers address the start/resume part just the stop/pause part.
If there is no relevant situation, is it ok to omit onStart() or onResume() and not use both as that seems redundant?
There's documentation on it.
The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onStop(). During this time the user can see the activity on-screen, though it may not be in the foreground and interacting with the user. Between these two methods you can maintain resources that are needed to show the activity to the user. For example, you can register a BroadcastReceiver in onStart() to monitor for changes that impact your UI, and unregister it in onStop() when the user no longer sees what you are displaying. The onStart() and onStop() methods can be called multiple times, as the activity becomes visible and hidden to the user.
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 and interacting with the user. An activity can frequently go between the resumed and paused states -- for example when the device goes to sleep, when an activity result is delivered, when a new intent is delivered -- so the code in these methods should be fairly lightweight.
As I understand it, onStart() and onStop() represent visibility, while onResume() and onPause() represent priority.
For example, if you open your app, both onStart() and onResume() will be called. With your app still open, say you then get a Facebook Message and open the chat. onPause() will be called, but onStop() won't. Your app is no longer in the foreground, but it's still visible.
EDIT:
I know I linked the Activity documentation, but according to the Fragment documentation:
onStart() makes the fragment visible to the user (based on its containing activity being started).
onResume() makes the fragment begin interacting with the user (based on its containing activity being resumed).
onPause() fragment is no longer interacting with the user either because its activity is being paused or a fragment operation is modifying it in the activity.
onStop() fragment is no longer visible to the user either because its activity is being stopped or a fragment operation is modifying it in the activity.
The same principle applies. In most cases, it's just a direct call from the Activity.
Two examples off the top of my head:
1.) System dialog opens over your app (for example, via Intent.createChooser) but cancelling the dialog
2.) Multi-window mode, tapping on the other application then tapping on yours (you will receive onPause/onResume but not onStop/onStart)
In my experience, the only time you actually need onPause() is if you are writing your own camera.
If you're trying to show a DialogFragment after onPause, you generally need to wait until onResumeFragments/onPostResume.
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 try to make Notification which must work only when Application UI isn't visible.
I tried to store preference which was written in onStart() and onStop() of my Activity. But sometimes, it's not working because another application became visible without MyActivity.onStop() being called.
What other method I can use for a Service to determine, if MyApplication is visible now? Or, maybe MyActivity?
If you already have code to keep track of the state of your app's UI, you can probably get it to work simply by putting the code in onPause() and onResume(), instead of onStart() and onStop().
It is possible for the UI not to be visible, or partially hidden, even before onStop() gets called ... as you found out.
Take a look at the Android Activity lifecycle diagram here:
http://developer.android.com/images/activity_lifecycle.png
and note the description:
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 and interacting with
the user. An activity can frequently go between the resumed and paused
states -- for example when the device goes to sleep, when an activity
result is delivered, when a new intent is delivered -- so the code in
these methods should be fairly lightweight.
Read more about this in another question here.
In my android application I have noticed that on press of back key, after onPause() automatically, onDestroy() is getting called.
How do I prevent the application from calling onDestroy() after onPause()?
I dont want to destroy the instances after back key press.
On press of Back key, my webview object is getting destroyed. So, I am not able to access the webview again,once I press back key.
I have got two URLs. Imagine them as URL1 and URL2.
When I launch URL1 in the webview and press back key the flow is onKeyDown() -> onPause()
When I launch URL2 in the webview and press back key the flow is onKeyDown() -> onPause() -> onDestroy()
Why is there a difference in the behaviour? Has it got anything to do with cookies?
For URL1 -- cookies.isSecure=true;
For URL2 -- cookies.isSecure=false;
Check the declaration of your activity in Manifest. Declare it in such a manner that it can store the data when minimized.
Activity should have the capability to restore the content.
That's how the Activity lifecycle is designed in Android and you should not interfere with it. You app can be destroyed by runtime at any point of time regardless of you want it or not :) So a better approach would be to accommodate the lifecycle in your application's logic.
you can override finish() to avoid this:
#Override
public void finish() {
//super.finish(); // do not call super
moveTaskToBack(true); // move back
}
you can override onBackPressed() in your activity, but that should be the last resort,
get a hang of these links before you start
activity lifecycle
developer blog
Normal android application behaviour states that the Home button hides the app to the background (you'll be shown the home screen), and Back button finishes the application (goes through onPause, onStop, onDestroy, in that order).
If you want to retain instances/states of your application when back button is pressed, I suggest you do the saving in onPause - save the states in SharedPreferences or in a place in your sqlite db. But mind that the saving process should be as quick as possible, because your application will wait until onPause executes completely before exiting.
Then load your instances/states in onResume.
You can know that onDestroy() will be called after onPause() using isFinishing() so you can avoid some code.
The answer here specifies that we have to configure the manifest in such a way that it should not get destroyed, but it does not answer how to configure. I arrived at this post when I had a similar problem for, the solution is pretty simple. Just mention
android:persistent="true"
Reference : - https://developer.android.com/guide/topics/manifest/application-element.html
This should prevent your activity getting destroyed when you click back button
I explained in detail with a use case in another post,
Prevent activity from being destroyed as long as possible
I hope this helps others who arrive at this place for the same problem
I have an application which I would like to be fully disabled/closed when it is paused (IE. When the user presses the Home, End (call) and Back button I would like the application to be closed, instead of being saved in the history stack).
How do I do this....?
Thanks.
Implement onPause() in your activity and call finish() on your activity. Bear in mind, though, that this will occur on every pause, including dialogs, incoming calls, users activating a Notification. You might want to consider doing finish() in onStop(), which would at least solve the dialog problem.
Also, bear in mind that users will may get confused when using your app, thinking it has crashed since it is gone when they try to get back to it.
you can easily do that by setting true the "noHistory" attribute in to your activity element, in the manifest
http://developer.android.com/guide/topics/manifest/activity-element.html#nohist
You know how you have an OnCreate() method in your activity which performs actions when you start. You need to add something like:
#Override
protected void onPause(){
finish();
super.onPause();
}
in your activity to add actions before it starts
in this case the
finish();
command is what you want to execute before your activity pauses.