While Developing Apps, following a Reactive Architecture (for example MVI, Mobius, Redux, and even MVVM) & Single Source of Truth can get you some big wins including but not limited to, Loose Coupling & Separation of Concerns, Code Testability, and easy debugging, unidirectional data, etc. However, unlike Web, where Reactive Architectures are the norm, in
Android, however, Reactive Architecture wasn’t natural till the UI layer, until Compose that is.
Using Compose would require a radical shift in our thought process about app architectures and the way we manage UI. Not only we’ll have to let go of the habit of calling `findViewById`, but we’ll also need to become accustomed to have our UI completely controlled by states, instead of having multiple flags here and there in the Activity.
Not only that, but the way we manage screens will also be affected, we’ll now have to consider having a Single Activity/Fragment while basing the navigation/Screens completely on Compose functions.
Now, if you’re developing an App from scratch, addressing the above concerns is comparatively easier than when you need to adopt/migrate to Compose in an existing app.
In this session, we’ll talk about what could be the best strategies for adopting/migrating to Compose in different kinds/sizes of apps. We'll talk about challenges you might face while migrating some existing screens to Compose.
Are you thinking is it the best time to invest in Compose? We’ll also talk about that.

In this session, we'll talk about the best strategies to migrate/adopt Compose in your existing app. We'll talk about the challenges you might face doing so.