I wonder what would be the best to prepare for Compose. I know we have like a year / year and a half till 1.0, so it gives us devs plenty of time to prepare at our ease. I guess a good separation between data loading and UI would be nice. I am sure apps created more than 3 or 4 years ago aren’t there yet.

Any kind of unidirectional data flow architectures will be useful here; push state down the UI and let events flow up as they are generated by user action. Keep a firm separation between state vs. events.

New back button dispatcher?

Yep: https://developer.android.com/reference/androidx/activity/OnBackPressedDispatcher

Impressive I didn’t know of that new API

Thank you Adam :)

yeah about unidirectional data flow architecture, that’s the trick, the app I’m working on at work has a kind of custom Loader APIs before the loaders API existed. It does the job, but our screens are heavy and do everything

I had spoken about a related topic where the app was using a state machine. Towards the second half of the talk, I replaced my UI with compose without much effort. This kind of setup would work really well https://github.com/vinaygaba/Droidcon-SF-2019-Architecture-Agnostic-UI-Development

I work on a fairly large codebase (couple million lines of code), and over the last 3 or so years we've been gradually migrating everything to explicit state machines, written mostly declaratively (we built a little library to help with this). At this point we've migrated a little over half our codebase. It's slow going, but worth it. As a result, our UI is now actually begging to be written in something like Compose - classic Android views are awkward to use when you just want to declaratively update everything from a single source of truth. And as a bonus, our developers are also now thinking in a more "declarative" way, which means a lot of the biggest mental adjustments required to move to Compose are hopefully already done, just with different names.