43

Is there technically any reason why I should use onRestoreInstanceState? Could I not do all the restoration in onCreate by checking if the savedInstanceState bundle is null? What is the primary benefit of using onRestoreInstanceState over doing everything in onCreate?

Sean Hill
  • 1,297
  • 1
  • 13
  • 21
  • 1
    This is pretty well explained here: http://stackoverflow.com/a/14676555/2278598 – Andrew Brooke Apr 04 '16 at 17:14
  • 1
    Possible duplicate of [Are onCreate and onRestoreInstanceState mutually exclusive?](http://stackoverflow.com/questions/12683779/are-oncreate-and-onrestoreinstancestate-mutually-exclusive) – F43nd1r Apr 04 '16 at 17:15
  • @AndrewBrooke I don't understand the line `"So for best practice, lay out your view hierarchy in onCreate and restore the previous state in onRestoreInstanceState"`. Does this mean just assigning the Views (e.g. via `findViewById`) but then assigning the member variables in `onRestoreInstanceState`? – Sean Hill Apr 04 '16 at 17:36

3 Answers3

42

onRestoreInstanceState

This method is called after onStart() when the activity is being re-initialized from a previously saved state, given here in savedInstanceState. Most implementations will simply use onCreate(Bundle) to restore their state, but it is sometimes convenient to do it here after all of the initialization has been done or to allow subclasses to decide whether to use your default implementation.

onRestoreInstanceState guarantees you receive a non-null Bundle object also in the lifecycle of activity it's called after onStart But onCreate: you should always check if the Bundle object is null or not to determine the configuration change and as you know it's called before onStart So It's all up to you and depends on your needs.

Farshad
  • 3,074
  • 2
  • 30
  • 44
  • what if i need to use my activity state parameters in onCreate ? thats not a rare possibility. – Amir Ziarati Apr 01 '18 at 17:32
  • @AmirZiarati you need to check if bundle object is not null, then you're good to go. – Farshad Apr 02 '18 at 09:59
  • 2
    i know, what i mean is: most of the time we need the bundle data before onRestoreInstanceState. I think getting bundle data in onCreate is more of use and more readable. – Amir Ziarati Apr 04 '18 at 05:01
  • @AmirZiarati Most of the time we need to know any configuration changes happened or not, So as I posted it all depends on your needs, Both approaches work fine, the only difference is in lifecycle. – Farshad Apr 04 '18 at 05:22
0

Mostly I tend to use onCreate(Bundle) to restore activity state, but if you have some initializations after which you want to restore the state its better to use onRestoreInstanceState() which offers much flexibility to restore state by the subsclasses those are extending the current activity. Also to be noted onRestoreInstanceState() is called after onStart() whereas onCreate(bundle) is called before that.

If you have huge data you can implement ViewModel class which handles the UI controller logic. ViewModel objects are automatically retained during configuration changes so that data they hold is immediately available to the next activity or fragment instance. For example, if you need to display a list of users in your app, make sure to assign responsibility to acquire and keep the list of users to a ViewModel, instead of an activity or fragment. It also provides de-coupling and making your activity or fragment serve a single purpose rather than handling excessive responsibility of UI logic.

Ajay Deepak
  • 471
  • 5
  • 9
0

In my opinion, we can see this doc Restore activity UI state using saved instance state .

here are some points

1.Both the onCreate() and onRestoreInstanceState() callback methods receive the same Bundle that contains the instance state information.

2.Instead of restoring the state during onCreate() you may choose to implement onRestoreInstanceState(), which the system calls after the onStart() method. The system calls onRestoreInstanceState() only if there is a saved state to restore, so you do not need to check whether the Bundle is null:

Community
  • 1
  • 1
gin.tama
  • 1