Square has come out against fragments, and if this r/AndroidDev thread is any indication, plenty of developers are ready to jump ship. Let’s take a step back from the hype and think through their proposed solution.
Solving a pain (e.g. fragments are hard) generally leads to new and different pains. For starters, not only did Square start from scratch and create their own path, but many developers may also throw away current implementations. That’s thousands of developer hours invested and there is no guarantee that the new approach will make code more maintainable, have less headaches than Fragments, or that the apps using the framework will perform any better. I’m all for shiny new things, but they are proposing we throw away years of tribal knowledge and start writing Android apps in a different way.
Their view-based approach comes with a learning curve of its own. You’ll need to learn how to make custom views (if you’re new to them). Once you’ve mastered that, you’ll need to use flow or your own system to manage the backstack (which you get for free with fragments). You’ll probably need mortar and dagger to round out the new approach. You’ll also need to do some fiddling on the testing side of the house. From what I’ve seen, there’s plenty of configuration and boilerplate to make their approach work in practice. On the other hand, if you use support/framework fragments, you won’t have to link together several libraries to get the same functionality.
One of the main benefits of Fragments is that they help you break up your architecture in a way that can scale to the multitude of device form factors. If you throw out fragments, you need to have a darn good solution to replace what they offer. A stackoverflow question that asks how the framework would be used to support multi-pane layouts, got the answer from Square that “we’re still working on a canonical answer for this” back in August. Their approach is still evolving and the documentation is pretty sparse.
Bringing in new libraries introduces technical risk including potential security risks, bugs in the library, and bugs when combined with other libraries. Libraries bloat your APK sizes, up your DEX counts, and often come packaged with other libraries. And just because you don’t need all the Square libraries up front, doesn’t mean you won’t need to add them as your app grows.
Square’s libraries are under active development, while Fragments have been developed over the course of years. Bugs have been found and resolved. Limitations have been addressed (e.g. child fragments). Google has the ability to fix and extend the Fragment framework by updating the support library (thanks for the tip Juhani!).
Finally, who is using this approach in production? The blog comments indicate that not all of Square’s projects have migrated to this methodology. What issues has the community experienced? If you’ve tried this approach, I’d love to hear about it.
Related Posts
Ditto.
I wrote dagger 1 app. then tried to use flow and mortar. I have used lots of libraries usually can get them to work. Flow and Mortar I could somewhat understand but there are lots of problems and bugs. More than base android with fragments.
It was like going to the dentist trying to get Proguard to work.
Then figuring out obscure error messages when you forget to Inject something properly. Also If you try to create Singleton and in one class forget to add an attribute you all of a sudden lose the class from being a singleton. I tried daggger 2. The tried integrating flow. It was not working when i tried and hugely time consuming.
Just create a singleton and inject it into the constructor. Use fragments like google says to and i think you will be much better off.
I made the mistake and could not turn back without a huge effort.
I attempted flow and mortar several times and could not manage it.
Square devs I know are way better than me i just cannot follow what they do and if there is no docs and you can’t follow it then stick with Fragments and std google sdk api.