0

I have been trying to figure out why my app's Master Activity which also has a Master Fragment cannot seem to restore any state nor can its activity.

I have looked at example code from the Big Nerd Ranch book, The Busy Coder's Guide to Android Development, tons of the android docs, google searches, etc. I even tried just using the default Master Detail Flow in Android studio to ensure what I am seeing is real.

I have tried a static and dynamic fragment for the main fragment, I have played with variations on adding to the back stack, etc.

Using the Android Studio Master Detail flow template, when I click on a list element to start the detail activity, I can see that:

D/ItemListActivity: onSaveInstanceState:

is called. However, when you go back from the detail view to the master list, ItemListActivity is constructed and onCreate is called, but savedInstanceState is null. onRestoreInstanceState is never called.

D/ItemListActivity: ItemListActivity()
D/ItemListActivity: onCreate:  (savedInstanceState == null) = true

I see basically the same with my own app:

When I touch a list element:

D/MainActivity: onSaveInstanceState
D/MainFragment: onSaveInstanceState

when I then touch Back to go back to the Main Activity list view, see:

D/MainActivity: onDestroy: 
D/MainActivity: MainActivity() 
D/MainActivity: onCreate:  (savedInstanceState == null) = true
D/MainFragment: MainFragment()
D/MainFragment: onCreate: savedInstanceState = null
D/MainFragment: onCreateView: savedInstanceState = null
D/MainActivity: onResume:

Surely the answer is not to store my main activity/fragment state in a singleton injected by Dagger.

Mark
  • 1,124
  • 1
  • 14
  • 21
  • Ok, this is interesting. I found this: http://stackoverflow.com/questions/15362525/when-is-onrestoreinstancestate-called which made me realize that quite possibly the behavior is as I would expect if I use my phone's back button. Sure enough, if I use my phone's back button, things work as expected. However, if I use the back arrow in the action bar, then things do not work as expected and behave as I originally wrote. Still, why is this? – Mark Dec 03 '16 at 20:46
  • Setting the Master Activity android:launchMode="singleTop" makes the action bar up button behave exactly as the phone's back button and the master state is not lost. – Mark Dec 03 '16 at 21:05
  • And, I just found that mentioned here too: http://stackoverflow.com/questions/13293772/how-to-navigate-up-to-the-same-parent-state/17342137#17342137 – Mark Dec 03 '16 at 22:25
  • This seems like it should be standard behavior for any master detail situation unless I'm not thinking of something. I'm not saying that it should be hard coded and the default, but I would have suspected this to be set and mentioned in any book or article that covers master detail activities. I would also expect the master detail flow template in Android Studio to correctly set this in the manifest or in the up menu action in the detail activity. – Mark Dec 03 '16 at 22:28
  • For example, in the detail activity: > navigateUpTo((new Intent(this, ItemListActivity.class)).setFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP|Intent.FLAG_ACTIVITY_CLEAR_TOP)); – Mark Dec 03 '16 at 22:28
  • Also, I used the Head First Android book during my research into this (forgot to mention it above) and it doesn't seem to cover this either. In fact, the only book that even mentions SingleTop of the 3 is the Busy Coder's book, but it doesn't show this as an example of when you want/need it. Because of this, I'm wondering if there is a catch to using single top to ensure master activity state preservation. – Mark Dec 03 '16 at 22:33

0 Answers0