Dynamic screens using server-driven UI in Android
Understanding the concept of server-driven UI for native mobile development
Developing native apps for mobile is still a first choice for the businesses who are working at scale and want to reach masses with performance efficient products. We will not go into a debate on which platform outperforms another, that’s a whole different discussion.
According to me, most of the mobile developers must have given a thought on how companies like Flipkart, Swiggy, Amazon, Airbnb, etc change/update their main app screens on the fly and provide users with a more customized experience. Most people agree on the fact that it’s a WebView, but it’s not (except Amazon) these all are natively implemented and dynamically controlled.
So, by closely comparing these two screens of Flipkart and Amazon we can see they both have similar components in the place like Carousel, Images, Cards with Image and Text which are basic components.
What is server-driven UI?
It is terminology through which the server is responsible for showing and controlling the components(views) on the frontend (in our case mobile app). It is also called as backend-driven UI.
The server defines which components are part of a screen and their order; these are described in the API. The apps render their native implementation of all the components. This allows the apps to deliver a high-quality user experience with all features native to their platform.
What are the benefits of using this approach?
- Run A/B experiments to test out different theories for improving the product.
- Easily iterating the screen and its views without any app update.
- Shipping new features faster, building new screens with defined components.
How does it work?
This approach involves these elements:
UI JSON (from Backend APIs), will have a proper definition of all the view types, data to be filled, their positions and actions to be performed. I know this all seems vague as of now, but we will learn more by looking at the sample JSON.
#1: Defined View Types: In this approach, the server response contains the pre-defined view types, which has all the actionable items like in the sample below, we have view type as image card, its title, action to be performed like opening the profile page for Cristiano Ronaldo with a specific id provided.
#2: Defined View’s: In this approach, the server response contains all its views, its hierarchy, positions, width, height, padding, color, text, etc. It defines all the needed properties to layout the view.
So, what's the difference between the two styles: In Defined View Types style, a particular view is already present in the app and you can only change the certain properties of the elements depending upon your usecase. In contrast, Defined View’s style is exhaustive enough to apply width, height, paddings, margins and all the properties through server.
Parsers/Converters: They convert/map the UI JSON into models, which can then be used to layout the views on the screen according to JSON. There are a lot of converters in android to perform this Gson, Moshi, Kotlin Serialization, etc.
Layouting: Now, the last step is to display the views onto the screen. So, the first thought which comes up in mind to implement this is everyone’s obvious choice: RecyclerView. That’s true RecyclerView can help us build this behavior, but will it be a viable option down the line or at scale, managing different view types, scroll performance, view creations, memory utilization.
Yes, you can use RecyclerView for the implementation, but there are other lots of amazing View Architectures available in the android open-source community which can help build these views natively and efficiently keeping in mind all optimizations happening underneath in the library.
P.S: All of them have the same end goal, but how they are work is different.
There are a lot of tutorials out there for Epoxy and Litho as they are the ones most widely used.
Wait… How can I forget? Yes, it’s the upcoming latest UI toolkit from Google itself for building modern UI.
Jetpack Compose 🤩, the toolkit is right now in early-stage development and there is a lot of aggressive development going on. But you can try the jetpack compose now though it’s prone to breaking changes.
Case Study:
Swiggy
Swiggy heavily uses server-driven UI to control views to be displayed on the screen and their respective positions. Also, considering the location-based dynamic components available for certain locations only (see image below).
Swiggy uses Litho (available for Android) a library from Facebook to implement its complex views at runtime by providing fine-grained recycling of the views, Flatter view hierarchies and asynchronous layout calculations which improve scroll performance.
Litho’s alternative on iOS Platform ComponentKit from Facebook.
Litho uses a declarative API to define UI components. You simply describe the layout for your UI based on a set of immutable inputs and the framework takes care of the rest. With code generation, Litho can perform optimizations for your UI under the hood, while keeping your code simple and easy to maintain.
The below article will explain to you properly how and why Swiggy opted for Litho rather than going with Android’s RecyclerView.
Flipkart
Flipkart has its design and layout engine in place to dynamically control the screen a user will see. This helps Flipkart to update the app home screen during the festive season to derive more product sales.
Flipkart Engineering has developed its system named Proteus to implement this approach.
Proteus is meant to be a drop-in replacement for Android’s
LayoutInflater; but unlike the compiled XML layouts bundled in the APK, Proteus inflates layouts at runtime. With Proteus, you can control your Apps layout from the backend (no WebViews).
Proteus takes consideration of defined API JSON and then converts the components depending upon the type of view into native components which can be added at runtime.
Airbnb
Airbnb has developed its library Epoxy to efficiently implement the server-driven UI on Android. They developed this view architecture first for their app and then rolled out this as a library.
Read more about their implementation here:
Epoxy’s alternative on iOS Platform MagzineLayout from Airbnb 🙌🏻
Huge Thanks to AirbnbEng for its contributions in the developer community by giving us awesome libraries like Lottie, Epoxy, etc and frameworks like MvRx.
The main objective of this article was to give you a brief about the server-driven UI.
More resources:
The article below explains implementing server-driven UI using Jetpack Compose.
Thanks for reading, if you have any questions or comments — feel free to reach out on Twitter @vipul_asri.
