jwill · August 29, 2015 14:02
diff --git a/gistfile1.txt b/gistfile1.txt
 [Shot A] As app developers, it’s our job to maintain the illusion that once started, every app is waiting patiently in the background, looking for it’s chance to be the star when called on.
 So whenever the user switches back to your app -- whether or not the system has killed it in the interim -- they should be presented with the same UI they had when they left. 
 To help, Android has another pair of handlers specifically for persisting state in these circumstances. 
 [Shot C] [Draw] onSaveInstanceState is called immediately before onPause -- so as soon as your app is no longer active -- And onRestoreInstanceState is called immediately after onCreate if the app is being started after having been terminated by the system.
 [Shot A] That means you can read the bundle of state information saved the last time your app was moved from the foreground here [point], the next time the user switches to your app -- even if it was killed by the system in the meantime. Using that bundle, you can return your UI to the same state it was the last time the user saw it, creating a seamless transition that hides the resource management happening under the covers.
 You’ll learn more about this, and get back to coding with Dan, next.
	[Shot A] As app developers, it’s our job to maintain the illusion that once started, every app is waiting patiently in the background, looking for it’s chance to be the star when called on.
	So whenever the user switches back to your app -- whether or not the system has killed it in the interim -- they should be presented with the same UI they had when they left.
	To help, Android has another pair of handlers specifically for persisting state in these circumstances.
	[Shot C] [Draw] onSaveInstanceState is called immediately before onPause -- so as soon as your app is no longer active -- And onRestoreInstanceState is called immediately after onCreate if the app is being started after having been terminated by the system.
	[Shot A] That means you can read the bundle of state information saved the last time your app was moved from the foreground here [point], the next time the user switches to your app -- even if it was killed by the system in the meantime. Using that bundle, you can return your UI to the same state it was the last time the user saw it, creating a seamless transition that hides the resource management happening under the covers.
	You’ll learn more about this, and get back to coding with Dan, next.