Smart vs Dumb Fragments?

Android Programming (3rd Edition) 17. Two-Pane Master-Detail Interfaces
1

I have a question about “smart” vs “dumb” fragments … Let’s use the CrimeFragment as an example.

In the book, the CrimeFragment is “smart” in that it knows about the CrimeLab, can lookup a Crime to show from the CrimeLab, and can save updates to that Crime to the CrimeLab. I’ve read some other articles that advise making your fragments “dumb”. That is, most of the time they should only really be concerned with UI interaction, and all other concerns should be delegated back to the hosting activity, or even another business logic layer. In the case of CrimeFragment, it would mean that the Fragment is just provided with a crime to show, and it shows it. And when changes are made, the updated crime is sent back (via the Callbacks interface) to the hosting activity, and the hosting activity is responsible for doing something with it (saving it back to CrimeLab). In this manner CrimeFragment is “dumb”, it doesn’t know anything about the CrimeLab or how to fetch or save a Crime. All it knows how to do is take a crime, handle the UI for it, and pass it back to the activity from which it came.

I can see advantages and disadvantages to both approaches. For example, with the book’s “smart” implementation, if I want to use the CrimeFragment somewhere else, I have to take the CrimeLab with me, whereas with a “dumb” approach, the CrimeFragment stands on its own, and I don’t have any dependencies or other classes that I’m coupled to. But I suspect there’s some “gotchas” with the “dumb” approach that I’m not thinking about… Passing a Crime back and forth instead of just it’s ID may present challenges? Or perhaps it creates issues when it comes to the back stack or configuration changes and the fragment getting destroyed/recreated.

I’m curious as to the authors thoughts on this concept of “Smart” vs “Dumb” fragments?

2

This is a timely question. Google has just started to have their own recommendations on this topic (or something similar at least).

At IO, in one of the navigation talks, Google is now suggesting that you create apps with one or very few Activities that host/transition between multiple fragments. As it relates to your question, Google is suggesting “dumb” activities and “smart” fragments.

There are some cases where I personally think that something should be owned at an Activity level, but most of the time, I think fragments should own what they need to do their task. They are meant to be self-contained controllers.

3

I’m still an Android newby (6 months) and this activity/fragment architecture has certainly provided ample opportunity for pondering. I have noticed when implementing Master/Detail implementations for tablets and phones that my Activity becomes much more controller like relative to the fragments, or in this context smarter activity and “dumber” fragments.

Watching the Google IO presentations, I sense the guidance is much like a single page web application now, switching fragments in and out. Significant contrast with starting a new activity for each app screen.