When a user runs a mobile app and then selects another app to run, the first app is moved to the background, orbackgrounded. The operating system (both iOS and Android) might kill the backgrounded app to release memory and improve performance for the app running in the foreground.

When the user selects the app again, bringing it back to the foreground, the OS relaunches it. But, unless you've set up a way to save the state of the app before it was killed, you've lost the state and the app starts from scratch. The user has lost the continuity they expect, which is clearly not ideal. (Imagine filling out a lengthy form and being interrupted by a phone callbefore clickingSubmit.)

So, how can you restore the state of the app so that it looks like it did before it was sent to the background?

Flutter has a solution for this with theRestorationManager (and related classes) in theservices library. With theRestorationManager, the Flutter framework provides the state data to the engineas the state changes, so that the app is ready when the OS signals that it's about to kill the app, giving the app only moments to prepare.

You can enable state restoration with just a few tasks:

1. Define arestorationScopeId for classes likeCupertinoApp,MaterialApp, orWidgetsApp.

2. Define arestorationId for widgets that support it, such asTextField andScrollView. This automatically enables built-in state restoration for those widgets.

3. For custom widgets, you must decide what state you want to restore and hold that state in aRestorableProperty. (The Flutter API provides various subclasses for different data types.) Define thoseRestorableProperty widgets in aState class that uses theRestorationMixin. Register those widgets with the mixin in arestoreState method.

4. If you use any Navigator API (likepush,pushNamed, and so on) migrate to the API that has "restorable" in the name (restorablePush,restorablePushNamed, and so on) to restore the navigation stack.

Other considerations:

• Providing arestorationScopeId toMaterialApp,CupertinoApp, orWidgetsApp automatically enables state restoration by injecting aRootRestorationScope. If you need to restore stateabove the app class, inject aRootRestorationScope manually.

• The difference between arestorationId and arestorationScopeId: Widgets that take arestorationScopeId create a newrestorationScope (a newRestorationBucket) into which all children store their state. ArestorationId means the widget (and its children) store the data in the surrounding bucket.

If you want your app to return to a particular route that the user was most recently viewing (the shopping cart, for example), then you must implement restoration state for navigation, as well.

If you use the Navigator API directly, migrate the standard methods to restorable methods (that have "restorable" in the name). For example, replacepush withrestorablePush.

To test state restoration, set up your mobile device so that it doesn't save state once an app is backgrounded. To learn how to do this for both iOS and Android, check outTesting state restoration on theRestorationManager page.

For further information on state restoration, check out the following resources.

• To learn more about short term and long term state, check outDifferentiate between ephemeral state and app state.

• You might want to check out packages on pub.dev that perform state restoration, such asstatePersistence.

• For more information on navigation and thego_router package, check outNavigation and routing and theState restoration topic on pub.dev.