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.