[MUSIC PLAYING]
[APPLAUSE]
CHRIS ARRIOLA: Have you already learned
the benefits of Jetpack Compose but aren't
sure where to get started with converting
your View-based app to Compose?
I'm Chris Arriola, Developer Relations Engineer
on the Android team.
And in this talk, I'll answer that question
by showing you how you can migrate.
So you have an existing View-based app,
and you want to convert it to Compose.
But of course, you don't want to stop building new features just
to make this migration.
The good news is Compose was designed
with View interoperability right from the start.
So you can make this migration, while still
adding new features to your app.
Here's an overview of the strategy that you can take.
First, start your adoption of Compose
by building new features in Compose.
This way, the features you build take advantage
of the benefits of Compose.
While building features in Compose,
you want to identify which components
can be reused in other parts of the app,
and then start building a library of common UI elements.
And lastly, continue your migration
by replacing existing screens to Compose one screen at a time.
These steps don't necessarily have to happen in sequence.
Depending on your team's size and your app size,
these can all happen in parallel.
So let's dive into the first step,
which is to adopt Compose in new features
you introduce in your app.
This approach to migrating allows
you to modernize your app, while still
addressing business needs by being able to add new features.
If your feature takes up an entire screen,
you would still be working under the constraints of your app's
architecture.
So if you're using fragments, you
would create a new fragment with its contents in Compose.
And if the entire screen is in Compose,
you would return a Compose view in the fragments onCreateView
lifecycle method.
And then you would provide the fragments composable
in the set content method of the Compose view.
If the new feature you're adding is
part of an existing screen on the other hand,
you would add a Compose view to the view hierarchy,
just like any other view.
And if you have multiple Compose views in the hierarchy,
you want to make sure that you have unique IDs
so state is preserved across configuration changes.
So as you're building new features,
you'll probably realize you're using a lot of components.
So to encourage reusability, consider
creating a module of common UI components in your app.
This would be a great opportunity
to work with a designer in your team to help identify
what those components are.
Think buttons, app bars, chips, and so on.
This technique is especially useful
if you're building a custom design system for your app.
Try to also find complex UI components that can be reused,
like dialogs, cards, and so on.
The features you build can then depend on this component
library, which allows you to style and change the look
and feel of your app's components all in one place.
The last stage in your migration is
to incrementally migrate existing features
one screen at a time.
Know that it's also best practice to rely on UI testing
while migrating existing screens, to ensure you're
not introducing regressions during migration.
So how do you go about migrating existing screens?
A good place to start is to try to find simple screens.
These are low-hanging fruit, as migrating
these screens can be done in a few lines of code in Compose.
The next place to look for are mixed screens,
so screens that contain a bit of Compose code already.
For these screens, you can take the bottom up
approach of migration by piece by piece
migrating UI elements until the entire UI tree is in Compose.
Keep repeating this process until all your screens
are in Compose.
Assuming you're using navigation component
and all your screens are in Compose,
what should you do about fragments?
Once all your fragments' contents are in Compose,
there's really little benefit that fragments give you
at that point.
So at that point, once all the contents are in Compose,
you can remove fragments entirely and replace them
with a corresponding screen level composable.
You can then use Navigation Compose to navigate and pass
data between these screen-level composables.
If you're ready to get started with migrating to Compose,
make sure to check out our documentation, Adopting Compose
in your app, to learn more about implementation details.
And if you want to learn more about case studies
on different strategies that work for other teams,
check out our Adopt Compose for your team's page at this link.
Now, you should know where to start.
Thank you.
[APPLAUSE]
[MUSIC PLAYING]