Great news for Android developing and Android developers, architecture components are here, and this a really BIG one.
Developing Android apps always have had several design caveats, the design of activities with very complex lifecycles that can even turn crazy complex when you mess with several fragments (take for example an app with just 1 fragment visible in vertical position and 2 fragments in portrait mode) made it very difficult to develop, test, debug and maintain complex applications. Every developer had their own tricks to deal with this, in particular I can recall how Romain Guy (before working with google) told that they avoided using fragments in his company due to the lifecycle complexity.
This is not only an issue to manage the correct initialization and proper free up of the resources in the correct order but also to maintain the needed data for the activities and fragments, that can’t be stored in the activity due to configuration changes and have to live in another cache (and again every developer have to figure out how to do this the better possible way for a given app).
Another caveat was the database framework. Android provide a quite simple and effective (for the most apps) system to access and maintain local databases, but the price you had to pay was a lot (and you and me know it is a LOT) of boilerplate, runtime bugs and difficulty to test and maintain. However there are quite a bit of different ORM options designed or adapted for android, but the most part while solving a lot of complexity issues for large apps, were not suitable for small apps, also, not being an standard or “most used” ORM deals to a big variety of options wich can be bad in certain work environments.
The last thing that was remarkably hard was to update every GUI component whenever the data changed (as if weren’t hard enought to work with recycler views). Normally the data is always loaded in background to a local database or similar app-level cache, and normally you want the GUI to be updated with the data when its ready, not when all the data is ready but while is being ready, e.g. if you are downloading a huge list of recipes in an app like FamilyRecipe, you want to update the recipe list every time you download one of them, that way the user can see the ready ones asap. The coding to solve that kind of issues can be not that easy to deal with and as usual, a lot of boilerplate was involved.
Google had realized this were probably the main issues in every app and wanted to give us a wonderful solution, this is what the Architectural Components is, a MAYOR change in the way every Android app is going to be developed, and off course its a change for the better. The bad news are that you can’t easily refactor your apps to use every one of these new features, the architecture is so different that it just can’t be done in an easy way, but maybe you can refactor just some parts or leverage one or hopefully two of the new features in your beloved apps next version.
To sum up, Google have been trying for years to avoid “bad apps” in the store, changes in the framework, in the S.O. versions have always been oriented to avoid the apps to do nasty stuff, like asking too many permissions, blocking the UI thread, doing too much stuff while in background, abusing the system resource etc…, every change in the framework and S.O. had been encouraging developers to do the right thing the right way and this Architectural components launch is no different, it encourages good coding practices making more maintainable and testable apps (like Room), avoiding the typical errors when configuration changes happens (LifeCycles), help optimizing the app telling us to use a kind of app cache (ViewModel), making more responsive and interactive user experience (LiveData).
I’m not going to show you any code, since you know there is already a better place than anywhere else to check all the stuff, the google docs: Android Architecture Components