User Tools

Site Tools


android_learning:headfirst_android_development_notes:chapter_8

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
android_learning:headfirst_android_development_notes:chapter_8 [2016/02/21 04:20] – [p. 356-358] mithatandroid_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 ====== ====== Chapter 8 ======
  
Line 171: Line 167:
 //rant: on// //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. The key points are:+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.   * 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.   * ''getFragmentManager()'' returns an Activity's fragment manager. It can be used to create transactions for a FrameLayout that's in an Activity's layout.
Line 179: Line 176:
 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. 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 this is that the AOSP developers didn't fully think through things when they introduced 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 ...+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// //rant: off//
android_learning/headfirst_android_development_notes/chapter_8.1456028432.txt.gz · Last modified: 2016/02/21 04:20 by mithat

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki