App Server

Overview

Every data-driven mobile application needs a central application server to process and store its data. The mobile application receives data from the server and displays it to the user. This data generally arrives as a result of the application pulling data from the server, but it can also be a result of the server pushing data to the application. In order to do this, the application server needs to keep track of all mobile devices that have their app installed, and if the application is available to multiple operating systems, it must also keep track of the operating system those devices are running so that it can route them to the correct push notification service (iOS through Apple’s APNS, Android through Google’s GCM, etc.). This can be fairly complicated, especially for cross-platform applications.

Authenticated mobile applications think in terms of users, not devices–they are not pushing data to a device, but they are pushing data to users, and these users may be authenticated on one or more devices across one or more platforms (iOS, Android, etc). This section will describe how to allow your application to send push notifications to users instead of devices by implementing a wrapper class into the server component of your mobile application.

In this example we leverage Urban Airship’s Push API to send the push notifications. This wrapper is designed to be dropped into any .NET project–it uses C# with LINQ to SQL accessing a SQL Server database. If you need to use a different technology, you can easily modify these files or use them as a guide in writing a wrapper that meets your needs.

For our example application, we wrote our application server using .NET MVC4 and WebAPI. We ran it on a Windows Azure instance with an Azure SQL database. We wrote a RESTful API for our mobile devices to get and send data. When the user logged in, the sent their username, password, device type (ios, android), and push token. If their credentials were valid, we created and returned an Auth-Token, similar to a cookie. Every subsequent request required the Auth-Token to be present in the header. In the database, we created an Auth-Token table, which had a many-to-one relationship with the Accounts table. In the Auth-Token record, we stored the push token and device type.

When it came to sending a push, we would send a push to a user, which has (potentially) many auth-tokens. We loop through the auth-tokens, sending a push to the Urban Airship API. Urban Airship has different APIs for iOS and Android, which made it necessary to switch APIs based on the device type.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s