Mobile App Reference Architecture for the Apprenda Platform

By Atos Apprenda Support

Fact: consumers of applications want to access functionality on their mobile device(s). This always holds true for both consumer apps (the Apple and Windows App Stores, and Google Play), as well as enterprise users within some of the world’s largest companies. And sometimes, its a combination of both – for example, the Geico app that lets users submit claims from the scene of an accident.

Whether you’re building the next App Store star, or augmenting your company’s accounting package by adding a mobile app to it, there are a few tenets to keep in mind.

First I’ll review these tenets, then I’ll walk through implementing a mobile solution using the .NET stack for Apprenda.

Mobile development has some unique concerns that developers needs to keep in mind. These concerns put some interesting constraints on developers when compared to development for tethered devices. Consider:

  1. Bandwidth – mobile app users have to keep in mind their usage of bandwidth. Whether they are paying for it, or their company is, bandwidth is not (in most cases) free. Developers need to build apps with the assumption that the device will be utilizing cellular data networks, even if WiFi is an option at times. A user who sees that your app chews into their monthly bandwidth allowance won’t be a user for long.
  2. Security – perhaps more relevant in certain scenarios like enterprise mobility (banking, insurance, etc.), the data that you send over the wire to mobile devices must be selective. The mantra for security is to send only what needs to be sent to the device to allow for functionality, and nothing more. In some cases, these mobile apps tap into highly secure information such as user’s bank accounts, and in that case it is important that the proper practices are used in development. Note that some concerns, like data encryption, can be offloaded to infrastructure configuration.
  3. Power – it is estimated that each individual use of a mobile device’s radio uses ~9 seconds of battery life. Therefore, it’s particularly important to consider how often your app sends or receives data through various application workflows. Can you cache data locally to avoid subsequent network calls back to the server? Can you batch dependent network calls into a single call?

Another important thing to consider when developing mobile apps, especially when adding mobile functionality to existing web or SOA apps, is that code reusability is great on the server side, but mobile usage and web usage can (and should) be treated separately. That is, you want to be able to scale APIs independently to satisfy user load from separate client types. In a case where you introduce a mobile app, you’ll likely find if trends hold up, that users will migrate to using the mobile app over the existing web app. With that, let’s take a look at mobile-enabling our go-to Apprenda sample app, Taskr.

Taskr in its initial state is a simple 3-tier application consisting of a web app (ASP.NET WebForms), a couple of WCF services to handle business logic, and a database for persisting data. The application’s purpose is to illustrate a common app architecture and usage of the Apprenda API. We’ll use this as our starting point. Taskr is available in the Developer Portal of your Apprenda instance.  If you don’t have an Apprenda instance, you can always sign up for ApprendaCloud here:, to try it out.

Original Taskr consists of several projects in one Visual Studio solution:

mobile_reference (2)

The resulting application, when deployed on Apprenda, consists of one web app and two dynamically scalable web services that communicate with each other via the Apprenda routing fabric. How this happens is outside the scope of this discussion. The resulting application, however, looks like this:

mobile_reference (3)


The UI allows you to enter new tasks and manage a glorified to-do list. Pretty straightforward. Our goal now is to add a mobile app that gives us a subset of that capability – we want to see our tasks on the go! To begin the transformation, we’re going to add a single new WCF service library to the original application solution:

mobile_reference (4)

In this service library we’re literally going to copy the original Taskr.Core.Service contract and service implementation. This means our new service will have the exact same capabilities as the original service. However, there is one small difference: our new service will be RESTful. To make this happen, we use System.ServiceModel.Web attributes on the service contract, which indicates to the WCF framework that these methods allow REST, and to the Apprenda platform that it should expose RESTful endpoints when we publish.

mobile_reference (5)

With the simple addition of this attribute, our service can be called via REST with Json payloads, and our service will respond with Json data.

Now, the big question at this point is: “Why make a new service and add these attributes there, instead of augmenting the existing Taskr.Core.Service to be RESTful?” The reason we’re doing it this way is so that we can scale Taskr.Core.Service and Taskr.Core.REST.Service independently. We have no way of knowing ahead of time which client will see more usage, the web app or the mobile app. Additionally, we may eventually need to bake in special optimizations for our mobile service to cater to the concerns noted above, that we don’t need to worry about for the existing app. Therefore, we’re making two backend services to facilitate a proper scaling capability based on usage patterns.

mobile_reference (6)Since our RESTful service starts off as an exact copy of the original Taskr Core service, we simply add the Taskr.Core.REST.Service to the solution, add WebGet and WebInvoke attributes to the service methods, and deploy the application – using Apprenda we can even patch the existing application and innocuously deploy the RESTful API without effecting regular users of the web app! Here, I’ve done that exact thing straight out of Visual Studio after testing the Taskr.Core.REST.Service locally:

mobile_reference (7)

Now let’s build the mobile app!

We’re going to use Windows Phone as the example here, but since the service is RESTful we could just as well build iOS or Android clients.

Here’s what you’ll need to build the Windows Phone app:

  • The Windows Phone SDK – In Visual Studio, when you attempt to add a Windows Phone application, if you don’t already have the SDK, you can download it. It installs the Windows Phone libraries as well as the WinPhone emulator. In my case, this is all in Visual Studio 2012 on Windows 8.
  • RestSharp – once you’ve created the new Windows Phone app, you’ll want to include a couple of packages in order to create our sample app. is a simple REST client for .NET. In Visual Studio you can use the awesome NuGet package manager to include it in your new Windows Phone app: Install-Package RestSharp
  • Windows Phone Toolkit – our app will include a date picker (for task due dates) as well as a couple extra goodies in terms of UI, so we’ll also include the Windows Phone Control Toolkit which adds standard UI control capabilities: Install-Package WPToolkit

Now we’re setup to start coding the Windows Phone application. The first thing we need facilitate is the user logging into the Apprenda platform that’s hosting Taskr. Abe Sultan wrote up a great article of mobile development here: in which he illustrated how to authenticate to Apprenda programmatically using the default REST authentication endpoints. We’ll prompt the user to enter their credentials first:

mobile_reference (8)

We’ll rely on RestSharp to handle the REST service call for us, even the serialization of the user’s input into Json to be sent to the Apprenda authentication service:

mobile_reference (10)

The user, once authenticated, is then sent to a list of their existing tasks, which is populated with a call to the API method “ListTasks”, same as the original Taskr Core service, but targeting the new REST api endpoint.

mobile_reference (9)


From here, the user can even create new tasks on their to-do list. We’ve introduced mobile functionality to the application. If it’s not obvious, the data is all being persisted to the same application database, so any data entered from the mobile application shows up in the web app, and vice versa.

Now, let’s fast forward a couple of months. We’ve found that our end users adhere to the trend of going mobile and have really migrated off of the web app and onto the mobile app. We might start adding functionality to the mobile app (like delete tasks, etc.), but in the meantime we need to scale the REST api that handles requests from the mobile – we need to handle a larger user load for the mobile than for the web app.

First, we can use the Apprenda Cloud Shell to list out the resources our application is consuming on the server(s):

mobile_reference (1)

Our intention is to add more power behind Apprenda.Taskr.Service.REST.TaskrCoreRESTService to handle the increasing usage from mobile users. To do so, we run an Apprenda Cloud Shell command like this:

acs SetInstanceCount –AppAlias taskr – VersionAlias v1 –Component Apprenda.Taskr.Service.REST.TaskrCoreRESTService +3

That single command increases the processing power, in terms of CPU and RAM, of the Taskr REST api service by 300%. Meanwhile, our users who are still using the original web app continue to do so without interruption.

It will be important to understand how this is all accomplished programmatically by looking at the attached sample code. There is a solution for the server-side components, and a solution specifically for the Windows Phone application. Adding REST capability to the Taskr service components was as simple as adding a new WCF service library and enhancing it with WCF-based REST capability. Apprenda recognizes this and automatically publishes the appropriate endpoints upon deployment. Once that REST endpoint is exposed we can access it from any RESTful client.

Atos Apprenda Support

View Comments
  1. MukhtarSeptember 12, 2013

    greate app.
    can you post some app that utlize OTP (one time password) authentication via CloudDb and consume in WP8 app

Comments are closed.