Differences

This shows you the differences between two versions of the page.

--- android_learning:headfirst_android_development_notes:chapter_8 [2016/02/21 01:19] – [pp. 328-329] mithat
+++ android_learning:headfirst_android_development_notes:chapter_8 [2016/02/21 04:24] (current) – [On Android fragment managers] mithat
@@ Line 1: / Line 1: @@
-<WRAP center round info 60%>
-Under development.
-</WRAP>
 ====== Chapter 8 ======
@@ Line 10: / Line 6: @@
 The summary of converting Activities to Fragments is:
-  * Change the class name and parent class.
+  * Change the class name to ''{whatever}Fragment'' and change the parent class to ''Fragment''.
-  * Make all lifecycle methods public
+  * Make all lifecycle methods public.
-  * Define an onCreateView method in which you inflate the layout.
+  * Define an ''onCreateView'' method in which you inflate the layout.
   * Remove any cruft from the lifecycle methods.
   * Be very careful about when/where/how Views are accessed (esp. anything that relies on the parent's layout) and refactor the code as needed.
@@ Line 167: / Line 163: @@
 </file>
+===== On Android fragment managers =====
+//rant: on//
+Given my current understanding of Android, I think the way it deals with nested fragments is pretty awful. The concepts are ok-ish, but the implementation is confusing.
+Some key points are:
+  * There are two different fragment manager retrieval functions---one for Activities and another for Fragments.
+  * ''getFragmentManager()'' returns an Activity's fragment manager. It can be used to create transactions for a FrameLayout that's in an Activity's layout.
+  * ''getChildFragmentManager()'' returns a Fragment's fragment manager. It can be used to create transactions for a FrameLayout that's in a Fragment's layout, or, if you prefer to think of it another way, transactions that become nested inside of other transactions.
+It's awkward to need two different function names for these two very similar cases, but fine. What I think is really awful is the naming of the functions: ''getFragmentManager()'' implies a general-purpose function and ''getChildFragmentManager'' implies a manager of a child in the present context, but neither of these is case.
+I suspect the reason for requiring two different functions is that the AOSP developers didn't fully think through things when they first developed Fragments, and when they figured out a better architecture, they probably didn't want to break the API (which would have required people to rewrite the code in their apps). But still ...
+//rant: off//
+===== p. 342 Code block =====
+<code java>
+FragmentTransaction ft = getChildFragmentManager().beginTransaction();
+StopwatchFragment stopwatchFragment = new StopwatchFragment();
+ft.replace(R.id.stopwatch_container, stopwatchFragment);
+ft.addToBackStack(null);
+ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);
+ft.commit();
+</code>
+===== p. 350: Code block =====
+<code java>
+switch (v.getId()) {
+	case R.id.start_button:
+		onClickStart(v);
+		break;
+	case R.id.stop_button:
+		onClickStop(v);
+		break;
+	case R.id.reset_button:
+		onClickReset(v);
+		break;
+}
+</code>
+===== p. 351: Code block =====
+<code java>
+Button startButton = (Button)layout.findViewById(R.id.start_button);
+startButton.setOnClickListener(this);
+Button stopButton = (Button)layout.findViewById(R.id.stop_button);
+stopButton.setOnClickListener(this);
+Button resetButton = (Button)layout.findViewById(R.id.reset_button);
+resetButton.setOnClickListener(this);
+</code>
+===== p. 356-358 =====
+The takeaway from this section is that the host Activity's ''setContentView()'' method automagically tries to restore Fragments to their last known state. This can have unintended consequences when an ''onCreateView()'' method creates new Fragments that are added to the UI. In this case, you will need to use some logic that only creates and adds a new Fragment if one doesn't already exist.