I just developed a screen saver app and I found a strange behavior in its lifecycle.
My work flow is like this:
start my RegisterService, where I call registerReceiver method to register a BroadcastReceiver, which can receive ACTION_SCREEN_OFF.
2.In the onReceive method of this BroadcastReceiver, I start an activity as the screensaver.
3.In the activity, I write Log.i() statement to track its running.
My question is:
When the screen times out, or when I press the POWER key, the screen turns off, and the system will send ACTION_SCREEN_OFF message. As I expect, my receiver starts the screen saver activity. However, I find this Activity calls onCreate(), onResume(), onPause(), onResume() sequentially according to the output in logcat.
It seems as if some a activity comes at front of my screensaver and finishes immediately, so my screensaver calls onPause() and then onResume().
Any idea? This problem handicaps me in programming, please help. Thanks!
Well based on a brief study of the PowerManagerService.java source code, when it's time to turn the screen off, the system initiates an animation (look at line 2183 for the class source) to do that. That means that your activity will pause and then will resume after the animation has ended.
I cannot be 100% sure for this, since I haven't tested it in my environment but this is the only logical explanation I found for your situation.
Hope this helps...
I can recommend you something very easy that might work for you, if you do not want the pause behavior why don't you try to Override the method onPause() and just do nothing :P don't call super.onPause() and that will terminate the behavior of it.
Other thing that might work for you, declare a static variable, add 1 on the "onResume()" method and return to "0" when "onStop()" is called. now just evaluate when the "onResume()" is called and if the variable is "0" then is the first time, anything else do nothing.
I hope this helps cause there is no much information on your question to be more specific.
Related
Is it Possible to see whats happening in onPause of an Android Activity?
I want to know if the app is
closing, going to background or screen is switched off
or
activity is changed or Sub-Activity is closed
is there a way to get this information?
You can see what it happening in the pause by looking at what is written in onPause().
I think you meant to ask, "What happens to the activity after onPause?"
To put it another way, you can't tell what is happening to the activity in onPause because the things that happen to the activity are taken care of in other methods. You'll have to look at these other methods at runtime.
Put a breakpoint in onRestart(), if this is hit, you can be sure that your activity was never destroyed.
Put a breakpoint in onDestroy(), if the activity is being destroyed, this breakpoint will be hit.
I have a stock Nexus 5 running 4.4.2 (using ART if it matters) and I've found an interesting scenario. I have this as my onDestroy():
#Override
protected void onDestroy() {
super.onDestroy();
t.setText("onDestroy");
t.show();
}
It's a GPS oriented app so I'm up and walking around. I am using the technique mentioned in this question to show a lot of debug toast messages.
Anyway, when I rotate my app, the toast appears. I understand that the activity is destroyed and recreated for the new orientation, but how can I know what's really going on? How can I tell when my app is REALLY getting destroyed and not just being rotated? Similar to this question, I want to log out when a particular activity is destroyed.
Since Honeycomb, the isChangingConfigurations() method can be queried to check whether the Activity is being recreated due to configuration changes. Alternatively, the isFinishing() method can be queried on any API level to check whether the Activity is actually being finished, or is only being destroyed temporarily by the system.
As far as I can determine, the two methods should always return mutually consistent results in practice. The only point where they might have diverged is when the system kills the process to clear memory, but there are no callbacks or interaction with the app at that point.
The documentation of the onDestroy() method mentions the use of the isFinishing() method:
Perform any final cleanup before an activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.
You can put it in a fragment with setRetainInstanceState(true) set. Place your code in the onDestroy() method of the fragment. Then, the fragment will not be destroyed on orientation changes.
First of all, you should not use onDestroy() to do anything because its not guaranteed to be called. I would put things on the onPause() method; I wouldn't even put things in onStop().
Also, Im not sure why you want to log out a user when they navigate away from the app. I would rather implement some kind of timer on the app or server to log out after x time.
Now, the answer lies in the documentation: http://developer.android.com/reference/android/app/Activity.html#ConfigurationChanges
You might want to override onConfigurationChanged so that your activity is not restarted.
I found a couple of solutions which are really just patterns to detect when the screen rotates. Alternatively, you can determine that the device was actually destroyed by checking some static data member to see if it was initialized or not.
Configuration changed solutions:
The first one involves handling all of the configuration changes in the onConfigurationChanged callback.
"Note that this will only be called if you have selected
configurations you would like to handle with the configChanges
attribute in your manifest."
The second involves listening for Display.getRotation() which returns a Surface.ROTATION_* object. Which is the new orientation of your screen relative to the natural state of the device orientation.
Again, you can use the configuration changes along with the static member.
Add ConfigChanges.UiMode flag to the ConfigurationChanges attribute for your MainActivity class, and this solves the problem.
More details: Android Launcher "OnDestroy" gets called twice
I've got an app that is complete, apart from the lifecycle that, guiltily, I left as last.
Things seem to work good in all cases, but one:
When I pause the app by pressing the power button, it correctly pauses and restarts when resuming.
When I rotate the screen it correctly resizes.
When I pause AND THEN rotate the screen, its behaviour is different and the app resets.
Now, obviously it's a problem of my internal code, but to help me in the debugging, I would like to understand what's the difference between the three lifecycles. Or better, if the THIRD example is some how different from the first two.
With debugging I saw that all of three do this (I resemble by mind, I hope to be right):
onSaveInstanceState()
onPause()
onStop()
onStart()
onResume()
Is it right? Or do I miss some lifecycle steps in the third example, above?
Thank you.
Please specify what you mean by the app resets.
When you press the power button, most likely your app stops. That's why you see onStart() being called after stopping (not: pausing) your app.
Given that, is it really the case that the third scenario you describe is a combination of the first two? In other words, how do you pause your app in the third scenario?
Update Regarding your comment: There is a difference between your Activity being stopped and your Activity being destroyed.
Rotation is a configuration change. In this scenario, your Activity is going to be destroyed and re-created. You can handle this case separately if you must (it depends) through the onRetainNonConfigurationInstance() callback and the getLastNonConfigurationInstance() method. Android will call onPause(), onStop(), onRetainNonConfigurationInstance() and onDestroy() in this order, and then continue with onCreate() etc and it will not handle any events in the meantime so that they won't get lost.
Most likely, some of your code is located in the wrong callback, such that in the third scenario, something does not get initialized/attached/... This is really hard to tell without the code and the exception (if it is an exception).
I suggest you proceed as follows.
Complete your understanding of the lifecycle and be precise (creation, start, restart, resume, pause, stop, destroy)
Complete your code to override the other lifecycle callbacks as well with log messages (don't forget to call the super class' callback) and analyze pause, stop, rotation and combinations
Identify the point of the crash
Analyze the life cycle of the objects involvedd in the crash in conjunction with the Activity lifecycle
Or you can post some code and the exception here, of course.
Update 2 I have made a test on an AVD. I have observed the following:
When the AVD is in landscape orientation, and I press the power button, my app receives a configuration change to portrait orientation (presumably because the portrait-orientation-only lock screen takes over). Pressing power again and unlocking the AVD, the app receives a configuration change again back to landscape orientation.
While not solving your issue, it goes to show that code must be carefully placed in the respective callbacks, because in the case above, while being re-created, the Activity will still not be shown.
Drop me a comment if you update your question.
Hi you can check the documentation regarding Managing the Activity life cycles in android .
When orientation changes Activity is re-created.
Add android:configChanges="keyboardHidden|orientation" to your activity in the manifest.
I have basic question regarding when to unregisterListener for sensor manager. Should it be done in onStop() or onDestroy().
Usecase :
I want to record accelorometer on click of start button and stop when user clicks stop button. the frequency of data is every minute. So I have started a timer.
But the issue is every time the orientation changes as per Android architecture, onStop() gets called. In onStop() I am cancelling the timer and unregistering the listener.
SO again if I start timer/register listener in onResume() the frequency won't remain 1 minute and also the data gets recorded without user pressing the start button.
Can someone help me resolve this issue.
Thanks.
You may want to use a Service to run the accelerometer data collecting in the background, communicating with it using basic intents is not too complicated.
Or, if you only want to 'survive' the rotation, when the activity gets destoryed and then rebuilt, try overriding in your Activity the onRetainNonConfigurationInstance() and getLastNonConfigurationInstance() methods (read more about it here)
OnDestroy() isn't guaranteed to be called. So you should do it in either onPause or onStop
But the issue is every time the orientation changes as per Android architecture
There's a way to prevent this from happening in the manifest. I'm sure someone else will post how.
According to the "Application Fundamentals" article, section "component lifecycle", onResume() is always called when a View becomes active, independent of the previous state.
In the Notepad tutorial, Exercise 3, I have found something confusing in NoteEdit.java:
There is a call to populateFields() in onCreate() as well as in onResume().
Wouldn't it be enough (or even better) to have it only in onResume() ?
In such a small example, it will not do any harm if populateFields() is performed twice, but in a bigger App, things can be different ...
Thanks and Regards,
Markus N.
From a look at Notepad3, I would say you are correct. There doesn't seem to be any reason for them to call populateFields() in both onCreate() and onResume(). onResume is sufficient.
I can see where you need it in both places, if application pauses then you would need it in onResume and if your process gets killed or user navigates back to activity then you will need it in onCreate especially if you are doing some pre-processing.
Per the documentation....for onResume() they recommend using it for lightweight calls unlike in onCreate():
"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. "
The Notepad app may want a variable declared if the method was already hit by onCreate not to redo in onResume().