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 demoparties.meteor.com.

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.

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
Homepage: http://curioustechizen.blogspot.com

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?