android - How to differentiate activity recreation is caused by screen rotation, or low memory condition -
according http://developer.android.com/training/basics/activity-lifecycle/recreating.html
there various ways trigger activity recreation.
- screen rotation
- low memory condition
i realize screen rotation , low memory condition yield quite different behavior.
one of obvious observations that, restore activity long pressed home, destroy , re-create application well.
for screen rotation, not yield such behavior.
may know, how can activity or fragment differentiate both cases?
@override protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); // check whether we're recreating destroyed instance if (savedinstancestate != null) { // caused screen rotation? or restoration low memory condition? // how can differentiate among "screen rotation", or "restoration low memory condition"? } else { } ... } p/s produce low memory condition, here steps done.
- press home put app in stack.
- launch memory intensive app.
- press home.
- repeat steps 2-3 5 times other apps.
- launch 1st app again.
- you realize
savedinstancestatenot null. however, @ same time, realize current runningapplicationinstance different first time launched's.
besides static members become uninitialized when restoring low memory condition, encounter weird stuffs
- launch child activity parent activity via
startactivityforresult - perform above 6 steps.
- close child activity.
- we can observe parent activity's fragment having following life cycle.
oncreate->onactivityresult->onresume
we expecting oncreate -> onresume -> onactivityresult
one of obvious observations that, restore activity long pressed home, destroy , re-create application well.
no, not.
if process terminated, when new process created (not matter how launch app), new application created part of new process. not directly have "restore activity long pressed home".
may know, how can activity or fragment differentiate both cases?
ideally, don't care. reason care if dependent upon static data members, may or may not initialized, in case way using static data members problematic.
my previous assertion, savedinstancestate non-null, incorrect, , apologize. primary scenario savedinstancestate configuration change. however, forgetting launching recent-tasks list ("restore activity long pressed home") pass in last saved instance state. launching other means, such home screen launcher, pass in null savedinstancestate.
if absolutely must distinguish between your-process-was-terminated , other scenarios, check static data member see if initialized or not.
Comments
Post a Comment