jwill · August 29, 2015 14:02
diff --git a/gistfile1.txt b/gistfile1.txt

 So if we treat Fragments as mini-Activities, each with its own independent lifecycle and UI, how does that compare to the lifecycle of a real Activity?
 As you might expect, the basic lifecycle events are the same -- and as the parent Activity moves through the cycle of starts and resumes, pauses and stops, those same lifecycle events will be triggered in the Fragment.
 So in most, cases you can simply move what you’d have put in an Activity’s lifecycle handlers into the corresponding Fragment handlers.
 With, of course, a couple of exceptions. Rather than building your UI here in onCreate, Fragments introduced a new event specifically for this [Draw]
 onCreateView is where you construct or inflate your UI, hook it up to any data sources, and return it to the parent Activity to integrate into its View hierarchy.
 There’s a corresponding onDestroyView handler [draw]. Which is called immediately before the Fragment is added to the backstack, independent of the parent activity.
 Keep in mind that that the Fragment Manager can add any Fragment Transactions -- adding, removing, or replacing Fragments -- to the backstack while a single parent Activity is active, so a Fragment can move through this cycle [gesture] multiple times indepdenent of the host Activity -- so onDestroyView is where you should clean up any resources related specifically to the UI -- such as bitmaps in memory, or cursors to data. That will help ensure your app’s memory footprint isn’t bloated by data that’s not needed when the Fragment isn’t visible.
 As soon as the Fragment is returned from the backstack, onCreateView [gesture] is called, and you can recreate the UI, and reconnect data sources, before your Fragment transitions through the rest of the lifecycle to become active again.
 Because a Fragment can only exist within an Activity, we also need callbacks to tell us when a Fragment is attached and detached from it’s parent [draw]
 onAttach is your opportunity to get a reference to the parent Activity, while onDetach is the last thing that happens -- even after your Fragment has technically been “destroyed”.
 The final piece of the puzzle is onActivityCreated [draw]. This notifies our Fragment that the parent Activity has completed its onCreate handler, and represents the point at which we can safely interact with its UI -- potentially including other Fragments. 
 Just like the Activity Lifecycle we discussed in Lesson 3, once the Fragment is no longer visible [gesture], there’s a chance it will be terminated with no further code being executed. That can happen after onStop in the case of the Activity being terminated while the Fragment is part of the Activity, or after onDestroyView if the Fragment has been placed on the backstack when the Activity is destroyed.

	So if we treat Fragments as mini-Activities, each with its own independent lifecycle and UI, how does that compare to the lifecycle of a real Activity?
	As you might expect, the basic lifecycle events are the same -- and as the parent Activity moves through the cycle of starts and resumes, pauses and stops, those same lifecycle events will be triggered in the Fragment.
	So in most, cases you can simply move what you’d have put in an Activity’s lifecycle handlers into the corresponding Fragment handlers.
	With, of course, a couple of exceptions. Rather than building your UI here in onCreate, Fragments introduced a new event specifically for this [Draw]
	onCreateView is where you construct or inflate your UI, hook it up to any data sources, and return it to the parent Activity to integrate into its View hierarchy.
	There’s a corresponding onDestroyView handler [draw]. Which is called immediately before the Fragment is added to the backstack, independent of the parent activity.
	Keep in mind that that the Fragment Manager can add any Fragment Transactions -- adding, removing, or replacing Fragments -- to the backstack while a single parent Activity is active, so a Fragment can move through this cycle [gesture] multiple times indepdenent of the host Activity -- so onDestroyView is where you should clean up any resources related specifically to the UI -- such as bitmaps in memory, or cursors to data. That will help ensure your app’s memory footprint isn’t bloated by data that’s not needed when the Fragment isn’t visible.
	As soon as the Fragment is returned from the backstack, onCreateView [gesture] is called, and you can recreate the UI, and reconnect data sources, before your Fragment transitions through the rest of the lifecycle to become active again.
	Because a Fragment can only exist within an Activity, we also need callbacks to tell us when a Fragment is attached and detached from it’s parent [draw]
	onAttach is your opportunity to get a reference to the parent Activity, while onDetach is the last thing that happens -- even after your Fragment has technically been “destroyed”.
	The final piece of the puzzle is onActivityCreated [draw]. This notifies our Fragment that the parent Activity has completed its onCreate handler, and represents the point at which we can safely interact with its UI -- potentially including other Fragments.
	Just like the Activity Lifecycle we discussed in Lesson 3, once the Fragment is no longer visible [gesture], there’s a chance it will be terminated with no further code being executed. That can happen after onStop in the case of the Activity being terminated while the Fragment is part of the Activity, or after onDestroyView if the Fragment has been placed on the backstack when the Activity is destroyed.