Towards applications always faster!

Since we launched GoodBarber, our goal has always been to offer applications with the best user experience. Beyond the interest that they can present for the final users, our approach — which is mainly shared by the industry — is to estimate the user experience of an application by the design and the fluidity (speed) of the interface.

Our second goal is to give our users the maximum flexibility in the management of their application with the diversity of the settings, and by modifying it easily.
It's the reason why we created a system of remote control for the applications updates. As fast as possible, this tool helps you updating all the base installed (design for example) on your app without an other submission to the stores.

The combination of these various constraints created a complex equation to be solved. Because the largest the flexibility of the settings is, the most complicated it is to keep the speed and  fluidity of the interface. And conversely, the more we look for speed, the less settings we can propose.

We dedicate a big part of our work to keep on improving GoodBarber and make it the sharpest DIY software to create beautiful app (especially through the GoodBarber 2.5 Salvador update). In parallel our team works on the optimisation of the application after every release. 

Concretely, it's inconceivable to download the different elements of your app design as one goes along of its smooth running. There is two reasons for that:
1- It would slow down considerably the display of the interface (which following the example of a web page should load its graphic elements before displaying them)
2- It could create an incoherence in the display of the applications by not allowing them to work off-line.

Basically, when your application is launched, it's going to get from our servers the elements of its design and all the elements needed to work properly and by itself. With the exception of its contents, which can evolve much more often than the design.

For the experts: This is at this moment that the application is going to check with the Settings API if all cache assets are updated.

This process of update happens only if your app wasn't launched in the multi-tasking of the system to avoid to slow down its launch in normal use. Also, all the elements of your application are embed on its local cache at the time of the compilation. This allow your application, on one hand to work offline and on the other hand to try to make the app faster after its publication.

When the application ask the Settings API to update itself, it browses all assets which are sent back to it and compares them one by one with its local cache. Meaning that if there is no modification since the last update, the process will be quick. The Setting API will answer that there is no modification and the application will work normally.

But if there is modifications (like new pictures, etc.) the most important the modification is, the longest the time of the update download will be.

There are 2 cases when the update can be complicated:
- When changing all the design of  your application (it can be several megabits of data to download)
- When a reader is in a zone where the network is not working well

In this 2 cases, the application can decide to stop the update (so the launch) either if some files are corrupted or if the time of updating is too slow.

All this process happens when launching the application, when the splash screen appears. You can see the progress of download at the top of the screen, with a white progress bar.

NB: The launch of the ads comes after the update process. So be careful, you don't want to see your application launch going slowly because of that.

To optimize the loading time of new elements, our team set some tools of monitoring in the application. We thought about what we could about optimization even if we can not influence the mobile network.

We found out that it wasn't specifically the data quantity that impacts the time of download, whatever the kind of connectivity (Edge, 3G, 4G or WiFi). Obviously, the more the volume of data is important, the longer it takes. But today mobiles network offer an efficient high-speed. So it's not a big deal (knowing that the weight of a new template is only around 2, 3 megabytes, not more)

The problem is the "ping". The ping is the round trip between the server and the terminal. And this can explode the time of download. Basically, the more files your app has to download, the more requests will be sent to the server, and your phone will end up wasting time, waiting for the several requests to come back.

Following GoodBarber 2.5 Salvador publication, our team looked for a way to optimize those different points. Since October, we set up a system which allows to reduce about 60 % of the time to update the app.

We want to reduce this time even more and we keep on working on it. At the moment our system admin team works essentially on the implementation of a CDN (Content Delivery Network), which should make the apps launch time the same wherever the user is on the planet. This system is going to be used also for the content feeds.

The native development team works on the fluidity of the app interface.
You may have not discovered yet all new features that Alex made. Be patient we're going to talk about it in few days ;)