Our Android Application Meets Jetpack Compose
As with every new technology, it’s always a good idea to introduce it pragmatically into a codebase that’s live in production and has millions of users; trying to ensure unnecessary problems aren’t introduced and understanding the benefits that come with this new tool. For us on the Android team at Vestiaire Collective, Jetpack Compose was one of these tools. So even though there was a lot of buzz around it and it was being actively pushed by many, here’s how we went about it.
For a long time in Native Android development, User Interfaces (UI) were built using Extensible Markup Language (XML). Views and ViewGroups are represented using XML tags, and the UI is fully developed as a tree of these tags in XML documents and inflated into Activities or Fragments, actively updating each view’s state wherever and whenever necessary.
But in 2021, Jetpack Compose was released; a brand new declarative methodology for building User Interfaces in Android. Compose has been actively gaining buzz in the Android community, making its way into more and more applications on the Google Play Store. Some advantages it provides over XML are:
- Less code to achieve the same UI; leading to fewer bugs and faster development time.
- More intuitive to write as Compose utilises a declarative API.
- Compose is interoperable with XML. Meaning you can have both of them together in the same screen and codebase, enabling a progressive migration for Compose into projects.
- It’s also powerful in terms of what can be achieved. Creating complex animations has never been easier.
Learning Compose as a team using the official Codelabs
With Compose comes a significant shift in thinking about code, methodology and architecture, amongst other things. The official Android documentation has some codelabs that provide a great path for getting on-boarded into Jetpack Compose, from the basic concepts, such as creating a text or a button in Compose and arranging composables in groups to the more complex ones like state management, Side Effects, and UI Testing. In the Android team, we began our Compose journey by going through these codelabs together as a team. These group sessions, while taking a time slot of an hour a week, brought really good results; keeping learning motivation high and relying on one another’s understanding for the confusing part of the new concepts. Altogether, these codelabs gave us a foundation to build on; a solid understanding of the ideas Compose brought forward.
For these sessions, we used the Mob Programming Format, which consisted of three major kinds of roles rotated weekly among the team members. First we have the “driver’’, one team member assigned to be the active developer in that session. They will be the one that actively codes, sharing their screen for everyone to follow. Then we have the ‘navigator’, a second team member that guides and directs the driver, looking for resources on what to do and organising what step of the code needs to be addressed next. And lastly, we have the “facilitators”, which are the other team members, following the resources and validating what’s being done by the driver and the navigator. It’s almost as if we are in a car, going on a journey.
Afterwards, taking advantage of the momentum from the codelabs, we decided to migrate one of our existing screens on the Android application to Jetpack Compose, using the same format. The ideal screen would be one that has low risk on the business side and could do with a polish user experience-wise. These criterias landed us on the user profile screen. Revamping this screen enabled us to think about Compose out of the guides of the codelabs, but actually using it to create a user interface directly related to our project. Of course we did face a number of challenges but nothing too difficult to figure out as a team. Eventually, with these sessions, we gained some valuable experience and confidence to create UI with Jetpack Compose.
Powering our Design System with Jetpack Compose
Jetpack Compose itself can be seen as a ‘design system’. What do I mean by that? Compose, as we interact with it as developers, is basically components (called composables). These components can be grouped together to make a desired UI and can be themed with a base theme providing colours and fonts. The Product Design Team at Vestiaire Collective has been working on unifying screens on the app and with Jetpack Compose came an opportunity to introduce a design system for Vestiaire Collective’s mobile applications. A design system ensures uniformity, as it provides everything from basic tokens such as colours, shapes, and fonts to patterns likeList of Product Blocks and Error Screens. As such, our design system, named Accent, was introduced. Accent provides all components that can be used on the Android application going forward, providing the tokens and also providing the actual components and patterns built from these tokens. The design system provides consistency and is uniform across all Vestiaire Collective platforms: Android app, iOS app and Web app. To learn more about our Accent design system, here’s a talk from Rami Trabelsi describing it and showing how it was developed and introduced into the Android application.
How is it related here? Well on the Android app, Accent was created and driven using Jetpack Compose. All atoms, colours, dimensions, and typography were created in the base theme used on all new screens called AccentTheme, providing uniformity and maintainability with minimal lines of code on the feature itself. This also means any change made in Accent takes effect across the entire app instantly. Powerful, isn’t it?
Investigation into Compose performance
As with every new technology, especially one as big as this that would make some changes to the very way we think about code, we wanted to make sure to have as much information as we could before introducing it to the application. Keeping this in mind, the Core Mobile team did a lot of investigation around a lot of topics in Jetpack Compose. Introducing guidelines for a lot of Compose concepts, such as recomposition count, performance, managing state effectively, navigation among composables, and of course, relying on and contributing to the design system.
To also ensure adding Compose didn’t introduce sudden spikes to metrics such as project build time and application size, we added Compose dependencies to the Android codebase and revamped a screen only used internally to get a measure of these metrics: our feature flag manager screen.
And some features…
After all the preliminary work that has been done, of course we have to introduce Jetpack Compose to the codebase at some point. Finally in the first quarter of 2023, the Hero Product Detail Page was introduced and Compose and the Accent design system were deemed sufficiently ready to work on this feature with. Therefore, we went with it. On a personal note, this was some of the most fun I’ve had working on a new feature.
And yes, there have been more and more features using the Accent design system and Jetpack Compose through the entire year. To name just a few, we have the Pick Up Location and Product Slider components on the Homepage, and the Notification Centre.
Some pitfalls we encountered
While the good has undoubtedly outweighed the bad, we have also encountered some issues with Compose in our relatively short stint. Compose is still quite immature as it has been out for just about two years, and that means there are quite a number of functionalities that are not yet developed. For some context, its counterpart, XML, is over a decade old and you can imagine the stability that comes with that.
Some of the issues we have encountered are:
- Implementing Pull to Refresh on the new Notification Centre Revamp as Compose Material 3 artifact does not have that functionality yet.
- Achieving a sticky scrolling behaviour on the profile screen’s tabs while using Compose interoperability with XML.
- Some lag while testing using development builds. (This does not happen on our release builds.)
- Consistent issues with composables previews used while screens are under development.
However, we’ve been able to find our way around these pitfalls and overall, it has been a good experience so far and it should get even better in the future with Compose and Accent design system getting more mature.
Conclusion
From my experience so far, I would say it has been a resounding success for us to take the step to introduce Jetpack Compose to our codebase. And due to more features using Jetpack Compose, the Accent design system has also gotten more and more mature, leading to faster development time as new features can take advantage of components already developed in Accent. Currently our most used component is AccentText with exactly 150 usages, proving scalable so far, with the added advantage of only needing to change a configuration in exactly one place if ever needed. Progressively introducing Compose has also proven to be a very smart decision as we have been able to swiftly mitigate any problems we faced in production keeping the precious stability of our application.
Thanks for reading.
