Conf42 Mobile 2022 - Online

How to update apps and perform rollouts without going through stores from a single code?

Video size:

Abstract

When we talk about mobile development processes, we inevitably come across the slow process of deploying in stores and the apprehension of performing application rollout. This apprehension when rolling out the application to the entire base comes from the fear of making mistakes, the difficulty in capturing user feedback and the delay in delivering the updated version of the application to the end user. However, there are technologies that help us to reduce these bottlenecks and one of them is the Server-Driven UI, a concept that uses cross-platform development as an alternative to automate deploys and update apps without going through the store.

Server-Driven UI

SDUI is an emerging technique used by companies like Airbnb, Spotify and Lyft that leverage the server to build the user interfaces of their mobile apps. This opens up new possibilities and addresses some fundamental challenges with native mobile app development.

In a traditional native mobile app, the UI layout and presentation is created by a developer and is included in the app design. The app package is uploaded to the App Sttore/ Play Store, where it is reviewed by Apple or Google and then made available for users to download.

User interfaces in these applications become dynamic by separating the UI from the data it displays. Although the UI is part of the application binary, the data is typically fetched from a server and embedded in the UI, so the user interface is built into the application, making it inflexible and difficult to update. In an SDUI implementation, the responsibility for describing screens is removed from the application, so when the application makes a request to the server, it returns not only the data but also the application’s UI.

Summary

  • Lucas Onseca is a developer advocate at Zoop Innovation. He talks about how to predate apps and perform rollouts without going through stores from a single code. Uses the concept of server driven UI to bring all of the dynamism found in the back end to the front end.
  • All of those companies are native companies. So I had the same power of the native to use on my back end. So all of the power that I had in my mobile I can use on the back end to make the application more powerful. If you want to make contact you can get this QR code to connect.

Transcript

This transcript was autogenerated. To make changes, submit a PR.
Hi everyone, today I'm going to talk about how to predate apps and perform rollouts without going through stores from a single code. So let's introduce myself, my name is Lucas Onseca. I am a developer advocate at Zoop Innovation. I'm from Brazil and it's a pleasure to be here today. So to start I will use as an example of lower shop that wants to use electronic device as a main communication channel with the customers. So they had some valid propositions that they want to offer to the customers and they want to make the customers comfortable with the exact same experience regardless of the platform. The client, that's to start a flux in the mobile app and if he switches to the desktop he can continue where he let off that each customer had a unique and exclusive experience dependent of the business role. These application should change the layout or the behavior and whenever these are updates, they are immediately received by the customers. So all of those value propositions are based on hypothesis testing. So what is hypothesis testing? We start with hypothesis. Hypothesis is always a statement. It is something you assume to be true but needs to be verified. So you had to use metrics that is a unit of measure to verify that the test was successful and the hypothesis was validated. And you should uses the criteria, that is the value you expect to achieve in the metrics to validate your hypothesis. And after that become a these or not these is a hypothesis that given the matrix meets the criteria. So these. We had some examples of hypothesis test that can be applied to the floor shop. So SMS is an effective communication channel for people over 35 years old. 20% of discount is enough to customers to migrate from physical solution to a fully digital one. It's a value proposition. A, B or C best communicates the benefits of my solution to my target audience and if I increase the value of the products by 1.5 my customers will perceive more value and consequently convert more. All of those are just statements or just hypothesis. Something that we can assume but we don't know if it's true. So if we want to make hypothesis tests in your service deploying on my structure, I can perform several deploys per day while on mobile as I depend of the stores to below these versions and rollout of the application. So make hypothesis tests are more expensive and complex to program how we make hypothesis tests in the mobile today. So we can use feature flags to control the release of the functionalities in our app, but we still don't have full control over these reviewed and releases. Prospects if we want to test for example whether SMS is an effective communication channel. We can create several tests through the back end and make ten uploads per day in the back end. But when we try to test hypothesis like switch value proposition a, B or c best communicates the benefits of my solution to my target audience that involves challenges to the front end we have a much more complex process to follow. So using the concept of server driven UI, that concept come to bring all of the dynamism found in the back end to these front end. So all of creating tests and hypothesis in the back end is pasted to the from end without needing to challenges these stores. So bring total control to those who use it. Then using single version of these application we can have two versions or three versions, ten versions in production of the same screen but with different uis. We can use different screens by regions or by country uses by business marketing for example to accommodate couture or market challenges in your screens in your fluxes. Or we can create unique experience per user. So switch user will say switch flux so who uses this concept? These we had some examples of players that use this like native server driven UI. So there are others players that use web applications to apply server driven UI. But here I had some examples of players that use native server driven web. So Swiggy, Urban, Bafood, Flipkart, Prime, Phonic, Spotify and ET and our floor shop wants to use this. So what we need to use server driven floor shop wants to know what we need to use this concept. To use this concept we need design system. So design system is all of UI companies in your application. They are described like components. So we measure custom companies buttons, labels, colors, text, inputs, titles, fonts, text, icons, colors all of our UI is implemented like a component and we can use this to create layouts and we need to make a JSON contract. So if we will send to the backend all of the UI logic, we had to make the front end and the back end communicate about it and we had to make a JSON contract to show switch component will be showed in the screen. So when to use server driven y to use server driven UI I want to apply dynamics flows that contain many business uses. When you want to apply a b tests, when you had hickory screen layout challenges, different layout settings for each business rule and when you need immediately content to be date without through these stars you should use server driven UI. They will help you to make your application more dynamic and effective and when not to use server driven one. So when your applications don't have a major design system recurring change to the design system. So it's not my flux that's changed often. So my design system challenges often. So you can't use server driven UI because this will not help you to implement this concept. Static screens are fluxes that don't change often. So you don't change your application. You don't need to change your application so you don't have to use server driven UI source code don't have layers that separate business role from uis. So code had to be a good architecture, a good separated layers. So if you don't have this you should make this first to use server driven UI and your service layer don't support scaling or a b tests. So the mobile should have separated business roles from uis and your service had to support scaling. So how can I do how my floor shop can do server driven UI so they can do it manually setting the contract between the front end and the back end or these can use frameworks to facilitate the application of this concept. So here I had some examples. Flipkart had process Facebook Lido Urban Bilona and I will show you Bigo. Bigo is an open source framework that help you to implement this concept. So here is the font of the information. So you want to see about process Lona Gator Lido you can access from this care code here. So what about Beagle? For this example I will use open source project called Beagle which facilitates the applications of this concept. So using Beagle as a dependence on both the front end and the back end you can use these cell on the server to serialize these screens to DSOn format and on the front end deserialize to Ui native companies. So as you can see Bigo uses the Facebook yoga library as an in giant switch implemented the concept of flexbox on mobile. So to organize the elements on the screen to managing to create complex screen we use the Flexbox concept from yoga library. So let's code. If you want to access the code that I will show you can use this QR code and I will show you the example. So here I had the backend. So if you access the GitHub code you should use the intellij or what you want to uploaded the backend and you had to open the back end. Sample these bigo sample back end. Here I had x sample application so this is my back end. Here I had a controller, I am using spring. So here I had zup innovation processor from spring to read the endpoint and here is backend. So we call this of BFf backend for from end and the difference between normal backend or normal BFf is the power of describing it. Describe your uis using the cell kotlin these cell so this backend is in Kotlin and here we describe our screen. So these I'm running on localhost so my application is consuming this screen from JSON and here I had a navigation bar, I had a container, I had a text input button to log in with biometry and I had a button. So if I want to change something these I can just updated my back end and make an upload here and my front end will get these updates immediately. So if I change the text to english so I will change here to log in cpf or cpf or so if I upload this stop and run I will change all of those texts so it let wait restart my application. The text was updated so in the next time that the user access these z screen they will receive immediately my content updated so I can make challenges in the UI. I can add some text input here so if I want to put the password here so password and here password and here I had to fix so I will use global form. So we had two text inputs and two texts and if I upload this I upload this change on my back end so let's wait for that. Let me try into this text. So I open the siri again sorry it close it feature is awesome. Um close these deck don't tell to uses siri nice ohm bicep feature awesome okay I will open the x code and run this again. Let's run this again okay and now I had two text inputs so I can change the logic on my back end using beagle. So here I had condition component so I can create conditions on my back end. Here I'm using just a simple condition if my macro danger is one two these 456789 I will pass to the next screen but I could use another service or call another serves to make sure that the user is in my base so I can use this valley to call another serves. But here is a simple condition validation if I don't attention and if invalid cpf. So if I just use one, two, three and click here they will show you mia alert let me updated this so these now we had full english screen so let's replace the application. I'm replacing the application because my emulator is not working well, but I just had to predate on my App Store's application so I can just use my back end to change my front end logic, my front end Ui. All of those companies are native companies. So I had the same power of the native to use on my back end. So if I use a different key credential I will get this alert. But if I use the right credential I will see the next page. So I can create complex fluxes, I can create logic, I can call another services. So here I had an example of send request so these I call another application, another serves. So all of the power that I had in my mobile I can use on my back end to make the application more powerful, I can make these applications more customizable. So this is the power of use server driven UI concept using kotlin and the back end. But if you don't want to use bigo you can do it manually. So you should get a JSON contract and your front end head to no switch component is colored on my JSOn. So that is it to show you very happy to be here with you and I hope that you learned something with me and if you want make contact you can get this QR code to connect. So let me here we had all of my social medias if you want to make contact you want to make patches and I am on the discord server so be free to call me. Thank you so much and see you.
...

Lucas Cesar Nogueira Fonseca

Developer Advocate & iOS Specialist @ Zup Innovation

Lucas Cesar Nogueira Fonseca's LinkedIn account Lucas Cesar Nogueira Fonseca's twitter account



Awesome tech events for

Priority access to all content

Video hallway track

Community chat

Exclusive promotions and giveaways