18

Using compat lib v1 (not using v2|3 because of certain bugs); a variation of this question.

I have a fragment whose UI has various controls whose state I want to maintain on an orientation change.

The parent activity is being destroyed on orientation change (PLEASE don't tell me about manifest changes to avoid activity recreation!!!!).

The fragment calls setRetainInstance(true).

1) Now my understanding is that Views with unique IDs should retain some state on say an orientation change. Given this I would expect a non-null bundle into onCreateView|onActivityCreated but it is null.

2) In any case if I save state in onSaveInstanceState (ensuring I call super) I still get a null bundle in 'onCreateView|onActivityCreated`

3) If I don't call setRetainInstance(true) then I DO get a non-null bundle in onCreateView|onActivityCreated even if I don't have an `onSaveInstanceState' method.

The questions I have is, is this working as expected and my understanding of the life-cycle is broken? Regardless, I'm guessing that the best way forward for me would be to retain the fragment and then maintain the state of the controls myself within the fragment.

Thanks in advance. Peter.

Community
  • 1
  • 1
PJL
  • 18,735
  • 17
  • 71
  • 68
  • Did you manage to solve this? Im having the exact same issue. – blindstuff Dec 06 '11 at 22:32
  • @blindstuff Nope, still haven't worked out whether it is a bug or a feature given I'm calling `setRetainInstance(true)`. Given that I do get a non-null bundle if say the app gets destroyed on a low-memory condition then perhaps a feature. I'm basically working around by saving the state of controls in `onDestroyView` and using them to restore controls in `onCreateView` when the bundle is null. I also similarly make sure that I save off state in `onSaveInstanceState`. – PJL Dec 07 '11 at 09:30
  • Thanks, i was afraid of this, i'm trying to retain an AsyncTask during rotation so I cant take the route you've been following I think. Im going to post a question as well to try to get more attention on this subject. – blindstuff Dec 07 '11 at 14:12
  • Try to use the latest revision (currently 4) of ACL. Some of the problems with setRetainInstance were fixed. – Catalin Morosan Dec 13 '11 at 08:48
  • @kaciula Thanks, although have updated to use v4 although still an issue. – PJL Dec 13 '11 at 10:47
  • 1
    If you use setRetainInstance(true) then of course the bundle is null. The fragment is not destroyed but only detached from the current activity and attached to the new activity. Only when the fragment is destroyed do you get a bundle with the values you saved in onSaveInstanceState. Just remove setRetainInstance(true). – Catalin Morosan Dec 13 '11 at 11:03

1 Answers1

17

If you use setRetainInstance(true) then of course the bundle is null. The fragment is not destroyed but only detached from the current activity and attached to the new activity. Only when the fragment is destroyed do you get a bundle with the values you saved in onSaveInstanceState. Just remove setRetainInstance(true) and use the saved values in onCreateView() to setup your custom views.

Catalin Morosan
  • 7,897
  • 11
  • 53
  • 73
  • 2
    Then I'm suprised that I get a call to `onSaveInstanceState` on a rotation when `setRetainInstance(true)` is called and furthermore the state of controls are lost. It was my understanding that Views with unique IDs should retain some state on say an orientation change. – PJL Dec 13 '11 at 15:15
  • 5
    onCreateView() is called no matter if you use setRetainInstance or not. So the entire view will be recreated. Which controls do you actually see that they lose state? setRetainInstance(true) should be used only in very specific situations. What exactly do you want to accomplish? setRetain.. doesn't keep the state of your controls but keeps that fragment alive so you can save various information in your member variables. Then, when onCreateView is called again, you can set the state of your various views with the info from your member variables. – Catalin Morosan Dec 14 '11 at 09:09
  • 7
    Thanks, I realise that `onCreateView` is called regardless and I am managing the state of controls myself. I also appreciate that things are basically working as expected, however, I'm still suprised that `onSaveInstanceState` is called on a rotation which to me gives the false impression that `onCreateView` will then be called with a non-null bundle. – PJL Dec 14 '11 at 10:13