We are thrilled to announce official support for Android on the StackMob platform. Mobile developers now have a single powerful backend for both their Android and iOS applications. The process of building, deploying and scaling an Android app will be very similar to iOS and it couldn’t be easier to get started:

1. Signup for a StackMob account here to get early access.
2. Go to Github to download the SDK.
3. Go to the StackMob Platform and generate your Google ClientLogin token.
4. Check out our Push Notifications doc page on how to set up your code to register push tokens on Android.

Anyone can build, deploy and scale awesome Android apps, and we can’t wait to see what you guys build. We’re so excited to be able to offer this to entire mobile community. Lets take a deeper dive into how it all works.

New URLs

First, we’ve extended the platform to handle iOS push (APNS) and Android push (C2DM) at the same time, as seamlessly as possible.

All of the URLs used to interact with the push service will still interact with iOS only, and new URLs have been added which end with “_universal” that handle both Android and iOS at the same time.

Here they are:

Send a list of tokens:

http://youraccount.stackmob.com/push/0/yourapp/push_tokens_universal

Send to a list of users:

http://youraccount.stackmob.com/push/0/yourapp/push_users_universal

Register device tokens:

http://youraccount.stackmob.com/push/0/yourapp/register_device_token_universal

Send broadcast notification:

http://youraccount.stackmob.com/push/0/yourapp/push_broadcast_universal

Get expired tokens:

http://youraccount.stackmob.com/push/0/yourapp/get_expired_tokens_universal

Remove token:

http://youraccount.stackmob.com/push/0/yourapp/remove_token

Remove token (universal):

http://youraccount.stackmob.com/push/0/yourapp/remove_token_universal

The Android SDK is using the universal push URLs now, and the iOS SDK will be changing to the universal URLs very soon. If you’re building a new app or updating an old one, we recommend you use the new URLs!

New Infrastructure

Finally, we’ve re-built much of our push backend to be device-agnostic. Our code no longer assumes that push tokens are iOS-only. You can see the result of this change in much of our push console. When you add a token, you now have to specify the device type as well.

We have built our push infrastructure to be as flexible and scalable as possible. With this infrastructure, we can:

1. Respond to push requests asynchronously
2. Efficiently send push messages with high throughput
3. Handle large spikes in push requests (such as broadcasts to large user bases)

Here’s what it looks like:

And here’s how a typical push request works:

1. HTTP requests come in to the PushAPIServer
2. For get_expired_tokens_universal, remove_token_universal, and register_token_universal calls, PushAPIServer does the appropriate datastore operation.
3. For push or broadcast operations, PushAPIServer does a simple OAuth check and token/user validity check (where applicable) and then atomically enqueues the appropriate send action onto RabbitMQ.
   • PushAPIServer never looks up tokens (for push_users_universal and push_broadcast_universal calls) – it simply enqueues a PushQueueMessage, which has the type of send (push to a list of tokens, push to a list of users, or broadcast) and the payload to send.
4. PushServerN atomically pulls a set of M new PushQueueMessages from RabbitMQ, and for each one, does the following: Look up all the tokens for the given message. For push_tokens_universal calls this operation is trivial, but for push_users_universal and push_broadcast_universal calls this operation involves a potentially large datastore calculate & fetch operation to get push tokens for a given user or given app. each push token contains a token and a type. For each push token, do the following
   • If there is no push thread running for this app for the given token type, create one. Push threads work similarly to how Scala actors work, and we run one push thread per app per service (currently APNS or C2DM).
   • Enqueue on the appropriate push thread’s queue the token & payload to send. This is the asynchronous call to actually send the payload to the device.

This ends up being a fairly complex system with many components, but it gives the main advantage of decoupling these key systems from each other:

• The PushAPIServer tier
• The PushServer tier
• The PushThread tier

Because these systems are decoupled, we can internally build, deploy and scale them separately, which gives us a flexible system as we internally build, deploy and scale our push offering as more developers start to use the system. Here are some examples of this flexibility:

• PushServers share no state with each other, and RabbitMQ dequeues are atomic, so we can freely add them to handle bursts of broadcasts or otherwise high push load.
• Similarly, PushAPIServers share no state with each other, and RabbitMQ enqueues are atomic, so we can freely add them also to handle high load on the push HTTP tier.
• PushServers control how many messages they atomically pull from RabbitMQ. That value is currently static in code (but easily changeable with a new deploy to a PushServer), but we plan to calculate that number dynamically in the future.
• We can offer other interfaces to our push service that introduce push commands into the system at various levels. For example, our custom code interface can skip the PushAPIServer tier and directly enqueue messages into RabbitMQ for extra efficiency.Since there is a clear interface between PushAPIServer and PushServer, we can test & deploy either without disturbing the other. Having this ability helps us immensely in our everyday work.

Login Here to start building a backend for your Android application.

Don’t have a Beta invite? Signup below.