Intro to Blueprint for Android
What seems like forever ago, a colleague and I were sitting down to rebuild an Android app from scratch. The app was a phone-focused account management app, and every screen was a vertical scrolling list of cards, items, headers and images… The perfect candidate for a RecyclerView. But we noticed that a lot of the items in the lists were being reused on different screens, and were powered by the same data, but, being inside different adapters for the different lists, were implemented slightly differently each time. To solve that problem, my colleague suggested a few third party libraries for building this type of application.
But the problem with libraries like Epoxy and Groupie is, they mostly lean on the MVVM pattern, which I personally am not super fond of. I find the frameworks of those libraries a little confusing to implement, and the resulting code a little hard to read. My personal preference, pattern-wise, is MVP, which I like because it draws pretty clear divisions in the responsibilities of the different parts of the system, and promotes compact, testable, readable, maintainable code.
So I set out to build the first version of what later became Blueprint — our very own framework for building list-based Android apps out of atomic, reusable components. Months later, Blueprint has become a full-fledged powerhouse of rapid Android software development. By employing some tricky annotation processing, we were able to get Blueprint to write a lot of the RecyclerView boilerplate, allowing the components that clients need to actually code to be composed of almost nothing but the actual business logic that they want their apps to express. In the coming weeks, I’ll take you through Blueprint’s concepts of Screens and Components, and try to show you just how easy it is to create strictly architected software without even knowing it.
Stay tuned, and in the meantime, go check out Blueprint, and see what you think.