Working offline

All our mobile software should be working offline, and you know it.

Always connected

We develop several apps that share a similar architecture. A server, with its trendy RESTful API, holds some interesting resources. A native app fetches and beautifully paints the information pulled from the API, which can then be browsed and updated by the user… while the server is available. Every change the user makes is immediately sent to the server and our happy app just waits for the operation to complete, again rendering the updated information on screen.

Lightweight apps everywhere. Dedicated web browsers.

We are comfortable with this approach because in our offices, with high bandwidth Internet and permanent WiFi access, the worst network problem we might find is convincing our workmates to disable Full HD in Youtube. Gary, when you drive back home you’ll enjoy Full HD there. Then, same for the next day, and the world goes on.

Always connected?

The Real World™ does not work that way for our users. There are plenty of poor hotspots in hotels, parks, airports; lots of districts without a 4G or even 3G signal; huge badlands without any type of radio coverage. Life is full of open spaces where your A-GPS device will not locate any Pokemon, not even a damn Zubat.

Always connected?

So accustomed are we to the commodities of our geek life that we cheerfully ignore the constraints of factories, banks, and so many types of corporations where network access is not a right, but a rare privilege. Until we get to work in a project in there. Or need to deploy there.

Not to mention the constraints of data plans. Really, let’s not delve too deep there.

User expectations for our mobile software are that it just works, wherever they go, whenever they go. Adding a local cache is an easy solution to keep showing information while we are offline, but that is not enough to grant operation when we need to gather data on the road.

Let’s be serious: man got to the Moon in a rocket driven by a processor slower than a Nintendo Gameboy, why can’t we get stuff done in an iDroid 3000 that effortlessly runs GTA 10? Why can’t the new data and pending operations just be synced silently with the company server without buzzing our pockets to request attention when we go to the toilet?

When are we going to fix this?

Real developers do offline

True mobility requires independence from network.fly

True mobility requires independence from network.

True mobility requires independence from network.

That was not a typo, but a mantra. We need to learn this principle, embrace it, and take it to heart for all our mobile development.

Let’s make it happen, let’s handle it. Let’s use all the power in our handsets, serve it to the users and allow them to fly on their smartphones. Let’s make their mobile devices the new PC, the real PC, the Most Personal Computer ever. Let’s grab a piece of the cloud, our very personal cloud, always carried with us in our bags.

Let’s rethink our apps, reorder our workflows, rewrite our code.

And let’s start this here, in this blog.

About David A. Velasco

Arquitecto de Software experto en Android. Desarrollo el cliente Android del proyecto de software libre ownCloud desde que tengo memoria. Me digo a mí mismo que sigo siendo jugón aunque no encuentro tiempo para entrar en Steam. Nintendero nostálgico.

Leave a Comment

Responsable » Solidgear.
Finalidad » Gestionar los comentarios.
Legitimación » Tu consentimiento.
Destinatarios » Los datos que me facilitas estarán ubicados en los servidores SolidgearGroup dentro de la UE.
Derechos » Podrás ejercer tus derechos, entre otros, a acceder, rectificar, limitar y suprimir tus datos.

By completing the form you agree to the Privacy Policy

This site uses Akismet to reduce spam. Learn how your comment data is processed.