Android — A consideration about Transitioning from Views to Compose
In the last few months, my team and I have been thinking about the best way to adopt Compose. After checking a ton of articles and videos suggesting ways to make this transition, a couple of things helped us create a path for this.
Something my entire team shares is our desire to use or at least test all the new components the Android team releases as it is released. That is why we create our pet projects to use them and test them in a controlled environment.
We take our time adopting something new because it is irresponsible to introduce something new only because of FOMO. We know that our users do not care what or how many tools, old or new, we use. They only want a good experience when they are using our apps.
Jetpack Compose
As many of you know, Jetpack Compose is the newest way to create our UIs on Android. Using Kotlin as the language and the current version of Android Studio (Arctic Fox), we can create UIs declaring all the components required.
Even though we can create components on demand, Compose encourages the creation of reusable components, and this could be a problem if your application does not follow a design system.
Design system
A design system is a group of allowed elements that different teams can use to design and implement new features. This set of elements helps us to standardize the look and feel of every screen, making it easier for the users to identify common behaviors when they use our app. Furthermore, they reduce the complexity that designing a new screen requires.
Counting with a design system provides you with several common components you can create and use across all the features of your app. But how can we create a design system? Here is where a methodology called Atomic Design enters the field.
Atomic Design
Atomic Design is a methodology for creating design systems. It drives composing screens by building with smaller reusable components toward building ever more complex constructions. This methodology was created for Web development, but we can use the same principles in developing mobile applications.
Under this metaphor:
- Atoms could be the view elements that Android provides us. These elements could be views or composable functions.
- Molecules are a combination of different atoms. Under our Android Perspective, a molecule could be a component composed of different types of views (eg. an ImageView + a title TextView + a brief description with other TextView) or a bit complex Composable function that receives the content. A molecule should be reusable.
- Organisms should be reusable sections composed of different molecules, atoms, or even other organisms. These sections could be populated by different data in different places in the application.
- Templates, from the View perspective, should be a group of containers to distribute and organize elements into a screen. From the Compose perspective, Composable functions as Scaffold or any complex Composable function that receives other Composable functions and brings distribution of elements to the screen.
- Pages should be our screens.
What does it look like?
I’m sure an image is better than words, so look at this image below
As you can see, these images show you some screens, their components, and elements that are part of them.
These pages called design kits usually are developed using tools like Figma, Sketch, or Adobe XD.
Having a clear idea in our mind
With our design system defined, we can start following the recommendations of other developers.
Start migrating a low-risk screen using any of the different ways to combine Views and Compose. You can even build new screens from zero. Having a design system allows you to create a palette of reusable components on a single module to build or migrate any screen you want in your project.
Obviously, you always can create components directly without a design system, but after seeing its benefits, I will recommend this way to work because it reduces some cognitive charge provoked when you have to build from scratch those components that a screen requires.
