Android UI at JET
In this post we are going to look at how we create and maintain our Android UI themes, styles and components at JET. We’ll walk through our process of generating themes that serve as a base for our styles and custom components. Then we will see how we implement these in our Android apps.
But before we delve into what AndroidUI is, we need to look at how design at JET works.
Design at JET Using PIE
At JET we have a number of teams across different platforms and applications that all need to implement UI design consistently and in accordance with the company’s brand.
To help the various teams achieve this goal our designers came up with a unified approach to design called PIE — Principles for Interfaces and Experiences.
PIE uses a system of design tokens to define values for colours, typography, shapes and spacing; PIEs design tokens are very similar to Adobe’s design tokens. Here we have global tokens which have literal names such as “orange” for a colour. We also have semantically named alias tokens, which give a higher level of abstraction such as “interactive-brand”.
Alias tokens are particularly useful when we want to implement themes that support light and dark mode. By using alias tokens as attributes in our themes we can have one colour attribute that can be used for both dark and light themes.
For PIE, all of our design tokens are declared in a simple JSON format. This JSON file contains the design tokens for colour, typography, shape etc. Finally, to make it easily accessible, we deploy this file on a CDN.
Thus we have a single source of truth and a consistent design language that can now be used across all our platforms and applications at JET. This helps us to have a consistent UI and brand design not just across our Android apps but also across different platforms such as iOS and web.
Creating Android Themes Using PIE
Now that we have our single source of truth and common design language from the design tokens defined by PIE we needed a way to convert these into themes that we can use in an Android application.
We needed an application that could parse the JSON files containing the design tokens and output the necessary themes and resource files. To do this we created a small standalone application called AndroidPIE.
As Android developers, the obvious choice was to write AndroidPIE in Kotlin. As well as Kotlin being a familiar language to work with, it also contained all the libraries we needed. To connect to the CDN url where our JSON file is stored we use a ktor client, and to parse the JSON into our data classes we use KotlinX Serialization.
Once we had parsed the design tokens from the JSON file, we now had lists of our different tokens for colours, typography and shape etc. The last thing we now had to do was to convert these lists of tokens into the Android files that we needed for our themes.
A tale of Two UI Frameworks
We started developing our solution for creating Android themes in early 2021. At this point Jetpack Compose was already a well established project with the first beta release available in Feb 2021. With this in mind, we could not only support creating XML files for view theming in our solution. We needed something that could also support outputting Kotlin class files that could be used for theming of composables.
After looking around and having a chat with our iOS colleagues we decided to give a template engine a try. One popular specification for templating is Mustache, but in our case we used a Java implementation of Handlebars which is a superset of Mustache and gave us a few more useful features.
Templating engines provide a powerful solution for taking dynamic data and transforming it into different outputs, meaning we can create different template files that take the same set of data but produce very different outputs. This seemed to be an ideal solution for what we wanted. Using a templating engine, we were able to generate different output files from one set of data with less code.
In all, for both the Android View and Compose UI systems we generated sixteen different files that previously we would have had to edit manually.
The last thing we did with the AndroidPIE application was to package it as a fat JAR so it would be easy to execute on any device when we needed to regenerate our themes.
Integration Into the Android Apps
At JET, there are a number of Android apps — from the consumer app that customers use to order takeaways, to the restaurant app that takeaways use to accept and process orders, to the delivery apps that drivers use for deliveries. Now that we have our themes and their supporting files we needed to find a way to use them in the Android apps within JET. The most obvious way is to just copy the generated theme files into each of the applications. This would create a basic level of consistency between them. They would all now have the same themes and use attributes with the same naming conventions. But the Android team thought that we could actually do better than this so we decided to create common libraries to use between the apps.
AndroidUI — View and Compose Libraries
As we have already mentioned, we are creating two types of themes, a View theme and a Compose theme, so it makes sense that we create two libraries that can be used in our Android applications — a Compose library and a View library.
To enable the creation of our reusable UI libraries we made a new Android Repository called AndroidUI. Here we have two Sample apps, one for Compose and another for Views. Additionally, we also created two library modules, a compose library module where we have our theme classes and composables and a View library module that contains the XML themes, resources, styles and custom components.
The sample apps allow our team to quickly develop and test UI components and styles in isolation of our consumer apps. By putting our themes, styles and composables in library modules, we were able to publish these to our artifactory repository as Android archives using Maven publish.
Our two libraries are based on the generated theme files. For the Android View system we then created styles and custom views based on the theme XML files. For Jetpack Compose we created our own composables that use the generated theme classes.
By having common libraries that can be shared between apps, we would now only have to copy the theme files once into our AndroidUI repo. Another big advantage was that we could also create one set of styles and custom UI components based on our generated themes. These styles and components could then be shared across the apps, giving another level of consistency and also eliminating any duplication of effort.
For our consumer apps to be able to use the libs all they needed to do was to add our artifactory repository to their gradle setup and declare the dependencies.
The Proof of the PIE is in the Eating
How has having this design system worked for us at JET? Has it been worth the effort to set this up and has it had any tangible benefits? It has certainly allowed us to centralise our approach to UI design and implementation, and has reduced development time and effort across our apps. Recently around June and July last year we were also asked to implement a redesign of our app. These changes were wide ranging with new colours, typography and shape. Our designers updated our design tokens and then for the Android team it was a matter of regenerating the theme files for both views and composables. To be honest there was a little more work we had to do on tweaking our styles, but on the whole having this system in the place made the whole redesign much more manageable and consistent.
For the Android developers at JET using PIE and the tools we have developed around it has definitely been a win. The result is that we now have two separate libs that can be used across Android applications. The libraries use a consistent design language and are generated from a single source. The design language is consistent across all platforms. We have greatly reduced the time and effort of implementing themes, styles and custom components, and we can update our designs quicker with fewer errors and variations.
Future Improvements
What we have now has been a big step forward for the Android team. But looking to the future, there is still more we can do. At the moment, the creation of the JSON file containing our design tokens is a manual process that is error-prone and laborious. With that in mind we have been looking at ways of making this process easier. Recently our design team switched to using Figma, which is a great design tool that has a rich set of features and also a set of APIs. With Figma, we have been looking at ways of creating our design tokens directly within the Figma app, then using the powerful set of APIs it provides to extract this information so that our tools such as AndroidPIE can make use of the tokens.
Another area we are looking to improve is the copying of the generated themes into the Android UI project. Again, at the moment, this is a manual process but we are looking to automate this in the near future.
Finally, you may have noticed that we are only generating our themes whereas our styles and composables are created manually. Wouldn’t it be great if we could generate our UI components directly from our designs? It’s an ambitious target and many have failed in this area, but recently Google, along with Figma, have announced a new initiative called Design to Code. This is something we are taking a closer look at. If this system could be implemented within our organisation, it would give us even more gains and further streamline our process of design to development.
Fancy working for Just EatTakeaway.com? We’re hiring! Apply today.
