Jetpack Compose is Android’s modern toolkit for building native UI. It simplifies and accelerates UI development on Android. It uses Composer declarative approach, different from view-based approach. It was presented by Google last February 24th 2021 and requires Android Studio Arctic Fox, still in beta. The toolkit has also still some bugs.

This new toolkit adds multiple advantages to the development. Among all I would highlight the fact that @Composables can be easily reutilized in other parts of the project. Even it is true that this could be done with previous xml layouts and fragments, the new approach ensures and helps for reusability. Files also have a view that you can use to track your progress without having to launch an emulator or install your App. Imagine a designer working on a @Composable without having to know all the ins and outs of Android development.

Another of the main points is that you have "databinding" and "viewbinding" built in by default. No need to track your classes in xml files and generating databindings from xml layouts in Pascal case. You also can get rid off (to a certain extent) of LiveData and observables in your MVVM architecture. @Composables are in a way (beta comment...) UI components that observe changes in the data they hold. In this sense they get updated when the data changes and it is the toolkit that takes most care of it.

When it comes to backbard compatibility there is a UI component that makes your day. Placing a composable UI element iny you old xml layout will let you render composables in a part of your classical-traditional UI. This will help you migrate old UI parts or mix new developments in old projects. Your strategy to cope we legacy versions is your thing. But the tools let you do everything you might need.

I created a modular architecture App that will allow me grow it in the future, using Dager Hilt as a Dependency Injection framework for better testability and code quality. The App uses a Room Database, DAO and Repository, LiveData to update the UI, Activities,fragments and related viewModels. Mirrowing possible customer use cases, I created an App using the old style xml based layouts with views and databinding and mixing @Composables. This know how ensures that I am able both to start a new App from scratch and also mantain an old one.

One of the things that I liked of my project structure is how I organised composables. At this stage and with the requirements of this App, I organised them next to the Fragment where they will be used, kind of "widgets" (called composables) organised in a widget folder. I considered a more general approach, but finally for readability and maintenance purposes I chose this one. The fact that they can be reused I see it more in leveraging from them (and evenually copying parts or all of them somewhere else) than having a "library of composables". Now I have a folder for DI related matters, for Fragments, for ViewModels, for UI toolkit code, data models and @Composables.

The App consists of two screens, one to select the puppy you want to adopt and another to view its details.