Introduction of Jetpack Compose

[emilymclean]

Are there currently any plans (or objections) to introduce Jetpack Compose into this project? Compose is now the recommended UI toolkit for Android and increasingly development efforts are being shifted towards it. Using it would support more modular, reusable UI development as well as lowing the barrier of entry for developers familiar with modern Android development practices. Long term, it could be part of a wider effort to modernize the app architecture with a view toward full migration onto the framework (/other modern Jetpack libraries).

If there is interest I would be happy to make a candidate PR that sets up the framework and adds a basic widget library.

[chaoflow]

This sounds great, thank you @emilymclean I'd wait to hear back from some others as well.

[amberin]

Yes, I'd say that such a PR is more than welcome! I've been hoping for this type of contributions for some time.

When it comes to Compose vs XML, I can't judge what would be our best strategy. I assume there are certain costs of doing a full migration, and when reading up on it, it doesn't seem like a complete no-brainer. But I'm very much for introducing Compose into the code base, to get a feel for our options. I guess Compose has more of a learning curve than XML-based UI, but I'm also getting the impression that Compose is becoming the norm, and that more and more online resources are solely focused on Compose.

[emilymclean]

I'm very familiar with Jetpack Compose, I've used it professionally since it was in beta and knew a couple of people on one of the teams in Google, so I'm happy to answer any questions you have about it. I'd personally that the pros of migrating Compose outweigh the cons - I feel most of my complaints are fairly niche and related to the depth of my work with Compose.

[emilymclean]

I'll work up a PR over the next few days

[sudhirkhanger]

@emilymclean were you able to introduce the jetpack compose?

[emilymclean]

Yes, PR #869 introduced the dependencies, setup the framework, and created some basic wrappers

[sudhirkhanger]

Nice. Thanks. I am guessing we are thinking about full compose migration in future. With navigation 3 support instead of compatibility with AndroidView or via Fragments.

[emilymclean]

That would be the ideal, but would require some more high level organisation and buy-in to actually achieve. Either way I've written most of the code assuming some kind of migration will happen eventually (see Navigator.kt), and I think it would be wise for any future contributors to write similar abstractions for the same reason.

[emilymclean]

Considering the announcement at Google I/O that "Android is now Compose First; Views are now in maintenance mode.", I think it might be worth this project planning a migration from XML to Compose. It might be worth considering redesigning some parts of the app with a more modern interface in the process, but I suspect that would be controversial.

Just off the top of my head, this would probably mostly be supporting work, particularly cleaning up the app architecture by migrating away from the localbroadcastmanager library and the mega MainActivity, something that should be done anyway. A more modern way to achieve this goal would be to hoist that logic into UseCases and global responsive state.

[amberin]

100 % agreed, especially with your last paragraph. I have been hoping for some skilled Android devs to come along and help out with this, as I am not qualified myself to pull it off without huge efforts.

[emilymclean]

I happen to be quite skilled at Android! I'm still not totally familiar with the project + don't have all the time to do this exclusively by myself, but I'm happy to both contribute to planning the broader migration and to take a stab at it when I have time. I'll make a new discussion and put some thoughts there.