For me, there are two types of mobile applications: stand-alone and non-stand-alone. A stand-alone mobile application is an application that doesn’t require external services to run (which is very rare, by the way). Non-stand-alone applications need to access external services, and for that they use application programming interfaces (APIs) defined by those external services.
There are at least two ways to build a mobile application that needs to access external services to collect information. Either the mobile application will directly call all external services or you have an application server that will provide a specific Representational State Transfer (REST) API for your application and the application server will call the different services to build the REST API response.
I have developed some mobile applications both with and without an application server environment, and the main challenge I faced while developing mobile applications without an application server is performance while using external services.
Without an application server
Without an application server, your mobile application will directly connect to the external service through the APIs. The problem is that the API might not be fine-grained enough for your application needs. For example, if you want to list tweets with certain characteristics that can’t be requested by the API, you will call the Twitter Search API to retrieve all tweets, import them into your mobile device and then filter to show only those you want. The performance is impacted because your application will request much more information than it really needs (all tweets versus a subset of tweets) and the application will do this over a mobile Internet connection, which can be less efficient than a wired Internet connection.
With an application server
Using an application server environment, you can create a lightweight API to request only the tweet range you need. The application server will receive this call, make the call to the external service, filter it and return only what your application requested. This will reduce the amount of data transiting over mobile Internet and thus increase the performance of your application.
Another use case is an application that needs to alert the user when a resource reaches a given threshold (like CPU usage). Without an application server, the mobile device would need to constantly request the state of the resource on a given periodicity. If the resource reaches a certain threshold, the mobile device could notify the user. The problem is what happens if the application located in the mobile device crashes—no more alert!—without speaking about the amount of data crossing the mobile Internet connection to periodically request the resource status.
With an application server, you could have a service running that periodically requests the resource status and use the “push notification” mechanism to alert the user. Using an application server will really minimize the amount of data going over the mobile Internet connection and speed up the performance of the mobile device.
As servers, you can use Zend PHP if you are a PHP fan, but if you want to also create an application that supports different types of devices (Android, iOS), you could select IBM Worklight. Both exist on IBM SmartCloud Application Services as patterns that you can deploy on the cloud.
I understand that in some cases, using an application server is not acceptable for economical reasons and thus sometimes the developer has no choice, but here I just wanted to stress some benefits of using such an architecture.
What are your experiences with using an application server for a mobile application? Comment below or follow me on Twitter @ITDoVe. You can watch the video I made on IBM Worklight here, and check out my personal blog here.