I am trying to save data in my activity and than restore it.
I save data in on onSaveInstanceState() and then I try to restore the data in onRestoreInstanceState().
I setup breakpoint, the method onSaveInstanceState() get called. But onRestoreInstanceState() or onCreate() never did.
Here is my steps:
start my Activity.
press 'Home' button on the phone. onSaveInstanceState() get called.
Click the icon in the launcher and launch my Activity again.
At this time, only onRestart() get called. But not onRestoreInstanceState() or onCreate().
Does anyone know why?
Well, if onRestart() is called, the value of the instance variables would be maintained by the application stack itself and thus you do not need to restore them.
onCreate() method is only called when your Activity's onStop() is called and the process is killed.
Please refer the Activity life cycle Android Activity Life Cycle for a clear understanding.
You may want to check whether the onStop() method is called and if your process is killed. I do no think that your process gets killed by the scenario which you have described.
the onRestoreInstanceState() method is very tricky. I do not know when exactly it is called but I saw it was called once while changing from Potrait to Landscape.
From doc:
The system calls onRestoreInstanceState() only if there is a saved state to restore.
I have asked similiar question earlier on here
Here's some steps to test out onRestoreInstanceState():
Press home screen
Kill the app through adb
Launch your app again
Follow these steps (Using Android Studio):
Create New Logcat Filter, e.g. AppState
Launch the app on your emulator. You will see:
I/AppState﹕ onCreate
I/AppState﹕ onStart
I/AppState﹕ onResume
Press Ctl-F12 to rotate the emulator. You will see:
I/StateChange﹕ onPause
I/StateChange﹕ onSaveInstanceState
I/StateChange﹕ onStop
I/StateChange﹕ onDestroy
I/StateChange﹕ onCreate
I/StateChange﹕ onStart
I/StateChange﹕ onRestoreInstanceState
I/StateChange﹕ onResume
This causes the destruction and recreation of the activity by making a configuration change to the device, such as rotating from portrait to landscape.
See the link below for how to test onSaveInstanceState() and onRestoreInstanceState() on a real device or in the emulator.
This method uses the AlwaysFinish setting, which is simpler and faster than killing processes. This method also provides Activity-level control rather than process level control:
http://bricolsoftconsulting.com/how-to-test-onsaveinstancestate-and-onrestoreinstancestate-on-a-real-device/
This is my solution for real device so onRestoreInstanceState get it called.
in manifest on related activity remove this part android:configChanges="orientation"
in manifest on related activity remove this partandroid:screenOrientation="portrait"
in your activity remove this line if it's there setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);
on your device enable rotating from setting - display - auto rotate.
then run your app, rotate your device.
that's it.
Related
I am building a camera app everything works file when i put it to the background but when i explicitly press the lock button it does not work,i am not finding and difference between the callback methods being called or am i missing something please help.
Put log line inside these methods
onPause
onSaveInstanceState
onStop
onDestroy
onResume
onRestoreInstanceState
onStart
onCreate
And make sure the same methods are called in both situation.
I have Activity that gets populated with info. When I press the screen off button and come back to the Activity, the info is not there anymore.
Btw, If I use the home button the info doesn't disappear. On logs, it shows it doesn't call onDestroy;
Therefore, onDestroy discards the info. I don't want onDestroy. HOw could I make that happen.
Thanks.
OnDestroy will always be called. You should save data and than recreate Activity on onCreate. Everything is nicely explained here. Read section "Saving Persistent State". Also read about lifecycle of Activity.
Try to save activity's info on onSaveInstanceState() and restore the state on onRestoreInstanceState().
This approach also helps you also in configuration changes state.
onSaveInstanceState() is called before destroying activity and onRestoreInstanceState() is called just before recreating the activity.
Follow this for more details.
Probably duplicate of Android activity onDestroy() called on screen lock.
This behaviour usually occurs at landscape orientation activities. Add
android:configChanges="orientation|keyboardHidden|screenSize"
to your AndroidManifest.xml activity tag.
I want to use Application.ActivityLifecycleCallbacks to monitor how many activities are there in the back-stack. Can I increment/decrement counter in onCreate/onDestroy to handle this?
onDestroy is NOT guaranteed to be called every time an activity is destroyed.
If the user clicks back to destroy it, onDestroy will be called.
If the user swipes the application from the recent app menu, onDestroy will NOT be called.
If the application crashes, it's undetermined if it'll be called (from my experience, it isn't called).
Is onDestroy always called when android destroys activity to save memory?
Yes
Documentation:
The final call you receive before your 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.
I want to use Application.ActivityLifecycleCallbacks to monitor how
many activities are there in the back-stack. Can I increment/decrement
counter in onCreate/onDestroy to handle this?
Better to counter in the onStart() and onStop() methods, onCreate() doesn't guarantee visibility. For example if somehow something stopped onStart() from happening.
onDestroy() is the final method that is called on an Activity instance before it’s destroyed and completely removed from memory. In extreme situations Android may kill the application process that is hosting the Activity, which will result in OnDestroy not being invoked. Apparently most of the Activities will not implement this method because most clean up and shut down has been done in the OnPause and OnStop methods.
For more details please visit Android Developers Portal.
(https://developer.android.com/reference/android/app/Activity.html "Android Developers")
When using the onPause method in the Android SDK, that code is run whenever the Activity was re-drawn (Such as rotating the device). Is there a way to detect whether the Activity was actually paused (Such as a new window popping up) or if the Activity was actually just re-drawn?
Actually if you look at the life cycle of an activity, when the device is rotated, the activity is restarted, so after onPause(), the activity goes through the complete restart cycle (onStop() and onRestart() are also called), so in this case you can set some value depending on what functions were called, or check the device's orientation.
Also when the activity goes into background, onPause() is called, and when the activity is no longer visible to the user, onStop() is called, which are due to specific reasons, the application can check that by setting some variable. For complete understanding, study the activity life cycle (Alternate Link)
But why do you need to know what happened to the activity? By overriding appropriate functions and providing proper layout resources, you do not need to know what happened in most cases.
For orientation, you can also get the orientation using getRotation method.
I think my ideas on activity lifecycle and bundles
are a little confused,can you help me?
Let's suppose the user opens activity A from home screen,
activity A "calls" activity B which fills the screen.
On this event onSaveInstanceState() is called on activity A then onPause() and onStop().
Since there are too many apps currently running on the system,
andorid decides to kill the process hosting activity A.
When the user navigates back to activity A,onCreate() is called an we can
use the bundle ( setted during the last call of onSaveInstaceStae() ) to restore the state.
then onStart(),onRestoreInsanceState()
and onResume() are called,
am I right?
Then lets suppose the user presses back key to exit from activity A
onPause(),onStop() and onDestory() are called in sequence on activity A (the call of onDestroy() could be postponed though)
onSaveInsanceState() should not be called in this scenario.
When the user opens again activity A later on then the bundle
passed to onCreate() is null,right?
Now Suppose the user rotates screen
onSaveInsanceState() ,OnPause() ,OnStop(), OnDestroy() are called
then onCreate() with bundle setted by the last call to onSaveInsanceState(),
and then onStart(), and onRestore().
am I right?
My guess is that:
when the user creates an ativity,the bundle passed to onCreate() is always null and onRestoreState() is never called,but when the system creates it , for instance when it killed the activity because of low memory or because of a rotation event,the bundle passed is the one setted by the last call of onSaveInstanceState().
Is my guess right?
thanks and sorry for my poor english.
P.S. : I think onRestoreInstanceState() is passed the same bundle is passed onCreate() but typically state is restored using onCreate().
Interesting question - never thought about it.
Take a look at the documentation, onCreate() and onSaveInstanceState().
This answers at least your question what Bundle will be supplied to onCreate().
Unfortunately there is no exact definition on which events onSaveInstanceState() is called, but I guess it is called by default in all relevant situations (whatever they may be...), but you can find out for some situations (e.g. rotating the screen) by putting a Log.i() to LogCat.
onRestoreInstanceState() is passed the same bundle is passed onCreate() is right, and the system restart the activity by call onCreate() and also call onRestoreInstanceState(),the bundle will be null if get from onCreate() when the activity first started.
Since there are too many apps currently running on the system,
andorid decides to kill the process hosting activity A.
This is a very common situation. Furthermore - you can emulate this action using developers option.
In this case each activity, that was move into background, will be automatically destroyed.
About Bundle in OnCreate .
I can get from my memory only two cases when OnCreate will be called with non-null Bundle. First - described above. Second case - screen rotation.
When you launch app Android calles
onCreate
onStart
onResume
After that lets doing screen rotation. Android will call
onSaveInstanceState
onPause
onStop
onDestroy
onCreate
onStart
onRestoreInstanceState
onResume
The more information you can find on topic about recreating