The most expensive proposal in a planning meeting is to migrate everything to the new approach. It is usually made about code that is working, by people who are right that the new approach is better, and it can consume a quarter without shipping a feature.
What the Vendor Actually Says
Android has two ways for a screen to observe data: an older one called LiveData and a newer one built on Kotlin Flow. The guidance for new code is unambiguous. Android's architecture recommendations say "Make uiState a StateFlow", and the page no longer mentions the older tool at all (Android).
That is guidance about what to write next. It says nothing about rewriting what exists. Our own article used to claim a stronger recommendation and cited a page that does not exist. We removed it.
Migrate Where It Hurts
The older tool has limits its own documentation states: "LiveData is not designed to handle asynchronous streams of data" (Android). Where a screen combines several data sources, or writes from background work and cannot afford to lose a value, those limits cost real engineering time. Those screens go first. A simple, stable screen can stay as it is for years.
The Swap That Is Not Mechanical
The risk in the migration is that it looks like a find-and-replace. It is not. Android documents the difference that bites: the old tool "automatically unregisters the consumer when the view goes to the STOPPED state, whereas collecting from a StateFlow or any other flow does not stop collecting automatically" (Android).
In plain terms, a careless conversion leaves screens doing work in the background after the customer has left them. Nothing visibly breaks. Battery and data are spent, and no test fails. That is the kind of defect a rushed, everything-at-once migration produces.
What to Ask Your Team
- Is the migration driven by a problem or by fashion? Ask for the screen that is hurting.
- Are new features written the new way? That costs nothing and should already be true.
- How do we verify a converted screen stops working when it is off screen?
- Can the data layer move first? The two tools can be bridged, so screens need not change on day one.
-Rocky
#TechnicalDebt #MigrationStrategy #MobileEngineering #EngineeringDreams #StrategiaX
Originally published on ANDROID-ARCHITECT, the Android engineering blog of Strategia-X, with the code for each step.