Fragment Usage


I’ve really enjoyed this book and working along with the sample apps. I was surprised to not find any debate within this forum about the scope of fragment usage throughout your examples. I can definitely see the advantage of managing views with fragments if there is the potential to combine views on larger display devices ( i.e. the master detail pattern). Beyond that , I think it may be a tough sell to convince my organization to adopt this pattern for every view. For example consider a login screen that may vertically stack user and password fields in portrait orientation, and horizontally in landscape. Or consider a more complex layout requiring many layout.xml files across various screen densities ( all containing relatively the same content). Are you suggesting that fragments should be used in these scenarios and if so is the implication that there would be a reduction of redundant layout xml files?



Fragments and activities solve the problem you describe equally well, so that’s not a good motivating example. If you don’t have a concrete usage in mind, it may be a hard sell to folks who would rather have a solid justification before changing things.

I’d love to hear how other folks feel about it, too. I personally saw that we had three choices for what we could recommend:

1- Use activities for everything
2- Use activities for some things, fragments for others
3- Use fragments for everything

Option #1 we could rule out immediately. We’re perfectly happy to omit things if we don’t think they’re useful for your average developer. Fragments are useful, though, so we couldn’t throw them out.

So we’re left with options #2 and #3. Which one is better?

Let’s say I’ve got a reasonably sized codebase. Do I want it to look like #2, or #3? #2 has fewer classes, a bit less code. #3 has more classes, more code.

#3 is much more flexible, though. Without any additional work, I can do things like retain instances or switch a screen to a dialog with much less refactoring than I’d be doing in #2. And while other folks may not value this as much as I do, I never, ever, ever have to make a decision in #3 - I just go ahead and write a fragment. Other than writing a little more code, there are few drawbacks to doing so.

Apart from introductory sections, we chose #3. Not coincidentally, this is what we do in our own practice, too. It trades some minor pain up front to get a more flexible and uniform codebase.


I was wondering about the usage of the fragments in this book as some fragment usage seemed like overkill in terms of all the code behind it. I admit I got lost in the book after all the switching from activities to fragments, etc. It was too much going on at once for me and although I finished chapter 12, I don’t feel any confidence using fragments and wiring them up, even as using the book as a reference to guide me (unlike the geoquiz project – read once, no reference needed as the pace seemed slower & managable to understand).

#1-2 would be my options I would choose for now until I wrap my head around fragments and feel comfortable using them completely for #3 situation. I kind of don’t recognize the purpose yet of #3 nor am I convinced to do all this for a very simple app.


You are definitely not alone in finding fragments to be a challenge - we get questions about them all the time. This is probably because, rather than solving one problem in a straightforward manner, fragments solve many smaller problems with using activities in an indirect way. We work with fragments the way we describe in our own practice. I would not feel comfortable recommending anything else.

I encourage you to stick with it. If something is still confusing, ask a question on the appropriate forum here and I’ll do my best to clarify.


Yeah, I noticed some other beginner Android resources don’t even mention fragments or work with them. I’m guessing cause it can get complicated but who likes the easy way out? :smiley: I’m going to slowly comb over those chapters again.


Thanks for the responses. This has been very helpful.
Can you elaborate on the “retainInstance” benefit? I did notice a lot less recovery of state data when using Fragments vs solely Activities.


We do less stashing of state for rotation in CriminalIntent, but that has more to do with the architecture of stashing the data in a central place than it does with fragments.

For info on retainInstance, check out Chapter 14.


I got over the fragment hump sometime late last week. Very cool feature. I look forward to using it more in my own side projects.