Closed sdrygalski closed 8 years ago
What I found in the guts of Controller
is only newInstance
call controller.restoreInstanceState(bundle)
. When I rotate emulator I got different path: setRouter
and than immediately performOnRestoreInstanceState
- without the chance to properly load mSavedInstanceState
from previous Bundle. So when mSavedInstanceState
is always null performOnRestoreInstanceState
will never call onRestoreInstanceState
. Hope it helps. :)
It sounds like this is working properly. onRestoreInstanceState
is called when your controller has been removed from memory and needs to be restored to its previous state. In your tests this likely never happens. Do you have reason to believe the controller is being destroyed and not properly restored?
You can not "force a save" , a save is caused by android when it thinks it is required, this mostly happens when the app is going to the background (the decision process is much more complex and differs in android versions).
Can you find a scenario where the containing activity runs onSaveInstanceState
but the controller doesn't run onSaveInstanceState
? They should run together.
Edit: Ignore the last part, I am wrong. Just listen to @EricKuck
Maybe I don't understand something, but in your demo in TargetDisplayController when onRestoreInstanceState should be called? When device is rotated, on configuration change? When I rotate device onRestoreInstanceState is not called.
But onSaveInstanceState
is called on every rotation.
Basically I just want to do something like this here: https://github.com/h6ah4i/android-advancedrecyclerview/blob/122fbd6261c95cde70a5c65eeaa686a6b9de5a48/example/src/main/java/com/h6ah4i/android/example/advrecyclerview/demo_e_basic/ExpandableExampleFragment.java
When rotating device, use onSaveInstanceState
, save some important data and after rotation read them in onRestoreInstanceState
.
Because according to diagrams onSaveInstanceState
is called after onDestroyView
I use onSaveViewState
to save data to field and use it later in onSaveInstanceState
. That way I can restore data before onCreateView
- in onRestoreInstanceState
.
I'm sorry if something is not clear, it's 3:43 am here. ;)
If onRestoreInstanceState
is not called, that's because your controller still exists. There would be no reason to restore a controller that still exists and has all its data. If you look at the diagram again, you'll see there is a line connecting onDestroyView()
to onCreateView()
for cases where the app process isn't killed, which is exactly what's happening for you.
So I have few questions:
onRestoreInstanceState
be called in your demo in TargetDisplayController?onCreateView
and onViewCreated
? Do I need to wait for onRestoreViewState
?If I need to wait for onRestoreViewState
I think it's less convenient than in Fragments, when I got access to bundle in onCreateView
and onViewCreated
.
If you're used to doing view creation and view restoration in one big method, then yes, it's less convenient. This library encourages splitting up responsibilities. That's not going to change. Let the view creation method create your views and let the restore view method restore the state of your views.
I missed one crucial part in your code:
public LifecycleHandler() { setRetainInstance(true); // ... }
Now I understand your design. And certainly it's not less convenient. :)
I tested this on my personal project and also on demo project - in both cases I didn't get
onRestoreInstanceState
called, even once, no matter what I try to save inonSaveInstanceState
.