PermaLink Building Android native clients for the Meteor.js framework08/03/2013
Today's mobile developers generally fall into the responsive-css-hybrid or native app camps.  On the one hand, the idea of a single web application that runs on the site and on mobile devices sounds great to the decision makers (and generally works for simpler apps).  Unfortunately, if you want the best experience for your mobile users (you generally won't find out about issues in hybrid apps until you're mostly done with it), you may very well need a native application as Facebook found out when they kept trying to use HTML5.

In choosing a web platform for your application's web site and as an endpoint for your mobile applications, one of the checklist items inevitably includes whether it's possible to write a pure native client that will talk to your web stack because decision makers like having insurance.  Meteor.js doesn't have the typical RESTful web service APIs that other web stacks have, though you can run another Node.js instance in parallel to do this with direct access to the database.  To provide the reactivity and realtime data sync that is Meteor.js' real strength, you have to talk to the server via the DDP websocket protocol.  For the two main mobile platforms (iOS and Android) as well as ASP.Net (including Windows Phones), this is now possible.

With the ObjectiveDDP library and the android-ddp-client library, mobile developers who need native UIs to Meteor.js can now provide it. There is also a C# ASP.Net library for Windows Phone developers.

The DDP protocol is deceptively simple, but it provides transport for a flexible schema data store that is synchronized in near real-time on all clients connected to the server. On the server side, the data store is provided by MongoDB which works on collections of JSON documents (the schema is flexible because of the underlying JSON document data). Any changes to a field on a document causes that JSON document to be pushed to all clients that are subscribed to it. NOTE: this also means that when designing a schema, you should denomalize large subdocuments and only store parts of those subdocuments that are needed for display (e.g. author names and summaries) with your documents because the entire field is pushed down when a subfield changes.

The DDP Protocol is taken care of in my fork of the java-ddp-client library. While trying to create an Android application from the original library, I found that the it only showed the basics of a websocket ddp connection but didn't handle what happens to the responses. This new library can be used by any Java application or on a Java server and has unit tests that show how to maintain state (local copies of collections and connection state) in a DDP application.

The android-ddp-client library is a layer on top of the java-ddp-client library that provides an event based framework for Android applications using Android's LocalBroadcastManager. It provides classes that can be easily overridden in case you want to use a different data store or a different event bus. The default data store uses in-memory maps to hold the collections, so if you plan on sending down huge collections to the client, you should be putting it in a local SQLite DB instead.

And lastly, the MeteorPartiesDDPClient provides a full Android native client sample so you can see how the android-ddp-client library is used. The MeteorPartiesDDPClient talks to a modified version of Meteor's Parties sample which is live at

Both the java-ddp-client library and android-ddp-client library are in MavenCentral if you use Maven or Gradle for your builds, but if you use Eclipse, it's simpler to git-clone the sources and put them in your workspace.

Meteor.js isn't necessarily for web applications. You can use it as the backend server for a real-time synchronized data store that works between multiple devices. On Android, you can do this with Google Cloud Messaging and implement your own server-side data store that your devices can poll when they get GCM messages, but using Meteor.js/MongoDB is a quick and simple way to do this, while providing scaleability via MongoLabs if your databases get extremely large.

Comments :v

1. ken09/09/2013 20:00:10

You don't really need Google Cloud Messaging w/ a Meteor server unless you want to use it to wake up your app. You just need another replicated collection to sync data around.

If you want to use the Android DDP client library and handle battery management, you'd run your data inside an Android service that will be able to sync data while your app isn't running.

One thing Meteor's DDP protocol doesn't do great at is temporarily disconnected networks. If you reconnect, you have to resync the collection instead of resyncing what's missing, which isn't very efficient...

2. Kiran Rao09/09/2013 15:37:23

Hello Ken,

Thanks for this great overview about using meteor from native clients (and for your awesome android DDP client library!)

I'm wondering how meteor (or DDP or even websockets for that matter) figure while considering the network and battery managemet policies of an Android app. In particular, could you elaborate on how one might use Google Cloud Messaging in conjunction with a meteor server?

Start Pages
RSS News Feed RSS Comments Feed CoComment Integrated
The BlogRoll
March 2019
Contact Me
About Ken
Full-stack developer (consultant) working with .Net, Java, Android, Javascript (jQuery, Meteor.js, AngularJS), Lotus Domino