Skip to Content

I develop software for a living and recently I was forced to think about the nature of mobile applications. You see, I live in the San Francisco Bay area. As most people around here, I am used to my iPhone being on-line all the time and I’m dependent on it for everything. Want to eat? Check Yelp for a nearby restaurant. Want to find an address? Maps with GPS are right here. Want to send an email? Check something on Wikipedia? Order a book from Amazon on the spot? Here you go. We do not pay attention to it, we just live it.


Last month I happened to plan a trip to Montreal. I quickly found that international data roaming charges on my plan are insane, so I bought a limited data package and decided to depend on Wi-Fi availability. I disembarked at the airport and there I started to understand that mobile life is way more complicated than what I became accustomed to.

Normally most of us use mobile applications that are always connected. The easiest way to think about the situation is to realize that we basically use our smartphones as browsers most of the time. Now, consider that you need to plan a travel itinerary. Can you do it while riding the subway? You surely can, if your application downloaded all the relevant information onto your phone. It’s not that difficult. It is not that much information after all – you phone is more powerful than that old IBM 360 mainframe. But applications have to plan for it and design for it. Writing an offline-capable application is way more complicated than writing a web site.

Now, if I am writing an “always online” application, then my mobile application is only a front-end. It plays the role of a browser. It is not much different from a “traditional” web-based solution.  If I am writing a truly mobile application, then most of my logic has to be on my device. That means, in many cases, duplicating all the logic done on the server! Usually we do not have that luxury, so application creators have to think hard to choose, to distill the “mobile” part of functionality and connect it to “immobile” part. This kind of thinking is simply new for most application developers raised in the Internet era.

So the moral of this story is:  When you start considering your mobility strategy, think hard about whether you can afford to make your business processes dependent on a web site with flaky availability. If you can, then your mobile application is just a front-end and will be relatively simple to build. If not, be prepared to put some real effort into thinking through how to mobilize your business applications.  As a developer, I’m curious, what do you expect from your mobile apps?


For more information on developing mobile applications, visit The SAP Mobility Design Center.

Brought to you by SAP Services.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply