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?