Behind the scenes: An overview of Appzio’s server-driven technology

In a previous article I touched on the problems with the current state of mobile development and Appzio’s solution to them. In this one I will focus more on the technical side and take a look under the hood of the Appzio platform — the technology that makes all of this possible. The goal of this article is to give you a better understanding of how the technology works and answer your questions about server-driven mobile development.

Appzio arms programmers with the ability to build fully native apps whose behavior is controlled entirely from the backend. This may sound a bit counter-intuitive at first due to the fact that we have a different perspective on separation of concerns.

The orthodox way of building applications is dividing them between the client and server side. If you allow me to simplify a little, it can be said, that the first is responsible for rendering the UI and managing application state while the latter stores and manages data.

Our platform challenges this approach with an alternative way to separate the responsibilities between the client and the server. Appzio allows both data storage and application behavior to be implemented on the backend while keeping the development process simple and straight forward. This is very familiar with developers who have worked with systems with a client-server architechture.

We will examine the communication process between the client and the server and then delve deeper into the separate technological parts of the system.

Communication

In order for the app to know what to render it needs to communicate with the server and retrieve data from it. The difference between our apps and orthodox ones is that ours need to get their layout information from the backend as well.

Communication is done via a REST API. Upon startup the mobile client will “ask” the server for all the application data, layout structure and assets it will need. The backend will respond with a JSON payload containing all that is asked from it.

The conversation between the two layers of the app, however, does not stop there. The client and the server will keep “talking” to each other whenever the user takes certain actions — opening a detail view for example.

This way the client holds as little user data as possible and leaves the complexity of creating the interface to the server. This way the backend may pass different layouts depending on the user’s authenticated status. Another situation in which this approach is beneficial is testing a new UI with a group of users.

In order to make sure Appzio applications are responsive and pleasent to use, client handles caching of data, submitting lot of the interactions in an async manner and smart pre-fetching of the data that might be needed by the client. Thus the experience is a normal responsive native application.

Layout

The thing most people have problems grasping is how can the backend define the layout of the application. The thing about Appzio is that there is NO HTML and NO Webviews.

When the client asks the server for the layout structure, the server will return a JSON response containing a list of objects and arrays that we will call components in the rest of the article. Those components represent the different elements that will be printed on the user’s screen — text, images, sliders, etc.

In order for them to be displayed correctly they must also have a set of instructions such as styles (offsets, colors and fonts) and gestures to which the component should respond — tapping or something else.

On client side these are handled by standard & custom native components.

Mobile Client

So far we explained how our apps are fully native. Our goal was to completely abstract away the mobile part of the development process and ensure a 100% code reusability between both platforms. Thus, allowing developers to write once and never worry about platform or version compatibility.

To achieve that we created two native engines — one for iOS and one for Android. They sit on the client side of the process we explained in the first two parts of the article and are responsible for displaying the data you pass to them from the server.

You needn’t worry about platform specific issues because everything is handled by the engines. For example, on iOS you will get a back arrow in the status bar when you open a detail view, while on Android the user will use the back button on the device.

These general purpose engines do not hold any application specific data. They receive instructions from the server and show only what they are passed. However, they still need to have the knowledge of what they should be rendering, hence there are certain limitations of what components you can use in your app. Having that in mind, we have covered most of the frequently and modern app elements, so you will rarely find something that is not built in.

Server Side

When you are developing with Appzio, you will spend most of your time here. As I mentioned earlier — the backend acts both as storage and layout provider for your app. Even though this may sound a bit overwhelming at first, don’t be too worried. The learning curve of our platform is significantly lower than others.

There isn’t anything too weird going on here. The server should answer particular requests, returning the data that is required from the client. That may be user profile information, different listings or images. The main difference is that instead of just returning the raw data that you fetch from the storage, you will need to wrap it with some meta information.

In a normal API you would simply send the data to the client as a JSON encoded string. In order for the Appzio client to understand what you’re sending it, however, you need to wrap the response in a component. Those are just objects or arrays that give additional information about how this data should be rendered on the screen.

For example if you’re sending images or assets you will also send instructions on the image’s resolution, width and cropping. If you need to display some list of items you would also provide information for how every item should look — offsets, colours and fonts.

Our main goal was to help developers utilize the knowledge they already have as much as possible. This is why our platform relies on the most basic data structures and design patterns. A common misconception in software development is that great systems need to be complex. As deceptively simple as our approach sounds it is also quite powerful. There is a lot of work put under the hood to allow developers to create modern UIs with the simplest syntax possible.

If you want to learn more contact us and ask away! We are here to help.