Mobile, mobile and mobile!

The Mobile software development market has grown in multiple folds in the past few years and as a matter of fact, today there are more mobile devices than people on this planet. Many of us own multiple mobile devices. With the demand of mobile device usages, the Mobile app economy is exploding and so do the needs of mobile app development resources. A report shows the mobile app market is expected to reach $17 Billion in year 2013.

While the demand for mobile developers is growing rapidly, many application developers are migrating to mobile app development. Many of these developers may have several years of experience coding C++ or Java or raw C code and some have built user interfaces using VC++, Windows Forms, Silverlight, WPF and HTML 5. These senior developers may have built many of these large and complex software applications but some of them just don't understand mobile. They just don't get it. Old habits die hard. They still build system they are accustomed to building back in the days. But things are different today. Software development has taken a 180 degree turn in the last few years. These non-mobile developers must adapt to the new change and the new way of writing applications.

Alright, let's start with an interesting question.

What happens when a carpenter designs a car?

What you get is as shown in Image 1.

Image1.jpg

Image 1

What happens when a car engineer designs a car?

What you get is as shown in Image 2.

Image2.jpg

Image 2

So what is wrong with design #1?

Well, nothing major really.

It just looks old. It's slow. It uses too much gas and it's just not comfortable.

That's all.

So what did we learn?

A carpenter should not design a car.

I am not saying being a carpenter is a bad thing but please, please don't design a car. At least don't design a car for the new generation.

What is an API?

An API is a bridge between two software programs to communicate with each other. It is usually a software program that exposes some functionality so one program can use it to connect to the other. The program that exposes the functionality may also be called a service and the program that consumes an API is called a consumer. In some cases, an API may be consumed by many consumers simultaneously.

So why do we need an API?

Let's say, you have a large database of some vital information that some companies or developers may be interested in and you want to expose this data. One option is that you can provide a copy of your data to each developer who is interested in it. But what happens if you change some records in your database? How do all the existing developers get the updated data? Or what if you don't want to share data with anybody and tell your trade secret. What if you want to expose data partially depending on who is asking for it?

Second option is to build an API and expose data with authorization and authentication. The authentication will ensure the right consumers are getting access to the data and authorization will ensure the right data is being delivered to right consumers.

Image3.jpg
Figure 3

Let's take a quick look at Figure 3 that shows an API exposing data from multiple data sources, applies business rules, settings and filters on the data and exposes it to the Web where customers can access it from their mobile devices and computers.

API for Mobile Apps

Obviously, some APIs are designed to be consumed by large systems and networks. But some APIs may be called from mobile devices. As an API developer, we should be cautious when building an API for mobile consumers.

In the case of building a Mobile API, "One size doesn't fit all".

For mobile API, one size doesn't fit all.

Let's ask ourselves a question. Why are mobile phones so popular? I bet your answer will match one of these: Availability, Mobility, Accessibility, and Simplicity. Yes, checking emails is much faster on a mobile device than on a computer. And it is also true, many low-income families use their mobile devices as their primary internet access device.

Factors to Consider when Building a Mobile API

When we build an API for mobile apps, we need to carefully consider the following four factors:

  • Internet Speed
  • Cost of Data Download
  • Local data storage
  • Processing Cost

Internet Speed

Image4.jpg
You need to watch out for speed.

In addition to making phone calls (that's not much), I use my iPhone to browse the internet, access my emails, play games and check my social accounts (Facebook, Twitter and LinkedIn). When I am home, I seldom use my phone. Most of the time, I find myself using apps at my son's games, bored while traveling, waiting for a meeting and so on. You may have noticed that in most of these places, the internet connection is usually bad. The point I am making is, you can't assume that when your API is being consumed, you will have a good fast-speed internet. Most of the time, you won't.

Cost of Data Download

Many people don't have unlimited data downloads, especially low-income families and students. You do not want to download too much data to their local mobile phone.

One of the biggest challenges with a mobile application is, you never know when you may drop the internet connection and when the internet speed will be high and low. So, when designing an app, you must be careful with the data download and upload size.

Local Data Storage

Local data storage is another issue. App space on a mobile device is not unlimited. Most of the space on a mobile device is allocated to music and movies and if you're app is not their daily used app then the user will not like if you use up a lot of their spaces.

Processing Cost

Data processing cost can be a major issue with a mobile app. You're comparing a PC processor Intel's Core i7 3960X with Apple's A5 APL0498. Core i7 is a super car engine loaded with Hyper-Threading technology, 12 processing threads and base clock 3.3GHz that is several times more than any mobile phone processor such as A5.

Image5.jpg
You cannot feed the same input grass to a Chara Machine as to a Thrasher. Too much grass input will choke a Chara machine.

In other words, the processors on mobile phones are light-weight compared to a Laptop, Desktop or a Web server. You definitely do not want to do very much processing on a mobile device. Your app should merely be a medium to display nice screens for already processed light-data steam coming from the API. If you download raw data then store and process it on the local mobile device then you just lost it. Not only is the user waiting for the app to load and display data but you're also affecting the performance of other applications running on the device. Let's not forget, a mobile device is already running many apps, including your phone, SMS, emails and others.

I have seen many developers design an API that returns bulk data and expect apps to process it. Well, an app can do it but this is not the right way to do it. If your API knows what data to return then it should process it on the server before returning it to the mobile.