The Deacon Project Droid+Beacon – Open-Source Push Notifications for Android & Java

Welcome to The Deacon Project!

What's Deacon?

Deacon is a push notification library for Android and Java applications. It uses the flexible Meteor web server to deliver notifications using comet technology. For more information, check out the About Page. You can also learn how we got started, or visit our repository on GitHub.

Why should I use it?

There are commercial services that offer push on Android, and Google began supporting "cloud to device messaging" in Android 2.2. If you want to run your push notifications through your server, support earlier versions of Android, or use push in your pure Java app, Deacon is for you.

What would you do?

All I can say is wow - I'm impressed by all that's been happening with Deacon in just a few days. We've got a smattering of code in the repository, a second contributor (a fellow RIT graduate SE student) has joined the project, and traffic on both this blog and the Deacon GitHub page has already shot far past my expectations.

Now that we've got a few folks visiting, I thought I'd pose a question: Considering Meteor can create push notifications from just about any imaginable data source, and Deacon will pipe these notifications into your Android application, what would you build with Deacon+Meteor? I ask this for two reasons: first, curiosity - but more importantly, some of your application ideas might end up shaping the way we design Deacon. So give a shout in the comments - what will you build with Deacon?

Clarification: iPhone OS 4 notification approach

Not that it makes a huge difference to the Deacon Project (other than acting as an awesomeness enhancer), but I received some gentle correction on Apple's approach to push notifications in iPhone OS 4. Thanks to my friend Pauley for digging up the following video!

As it turns out, my surprise toward Apple's apparent step toward openness in allowing push notifications from third-party servers was well-founded. Even in OS 4, iPhone devs will still need to send their push notifications out via Apple's servers. The difference now? They'll be able to generate their own notifications from within the device.

Of course, none of this really has any impact on Deacon. Android still lacks native push support, and the introduction of Deacon still means a new choice in how to deliver push notifications to Android apps.

Deacon: Android’s latest bundle of joy

Update: It seems a whole lot of folks are finding this page from searches and referring links - Deacon has come a long way in since the project was announced on this blog post! Please check out the latest on the blog, as well as the project's GitHub page, to get the latest information.

It all started as a friend and I sat in a bar this past January in January of 2010, commemorating his birthday with some celebratory beverages. On his hip, an iPhone 3GS. On mine, my Motorola Droid, a shade over 3 months old. On TV, a Buffalo Sabres game.

Turns out, my friend is a pretty big Sabres fan. And each time a goal was scored in the game, his iPhone would buzz, displaying an update. I found this to be very cool, and quietly lamented the dearth of good real-time sports apps for Android. Upon returning home and doing some Googling, I discovered that Android doesn't really have any native capability for push notifications. The iPhone has - since OS 3.0 - as this video from CNet describes:

Unfortunately for iPhone developers, to paraphraseblatantly rip off 1st Timothy, there was but one way to push notifications, and that way was through Apple. Unless developers wanted to use Apple's servers for their push notification deployments, they were stuck - though I'm sure they're used to having their hands tied by the gang from Cupertino.

Doing some more hunting, I discovered a company called Xtify, who offer push notification services for Android app developers. Just run your messages through their servers, and viola! you're pushing them out to users. What's more, the Xtify solution can target notification "campaigns" to users based on their location - which is pretty cool. But still, app developers' hands are tied - the only way to send out their notifications is through Xtify's servers.

All that hunting done, I didn't really give it a second thought. After all, I'm not exactly writing any ground-breaking Android apps right now, and at the time I couldn't think of much I'd do with push notifications outside of sports scores. But then Apple announced iPhone OS 4, and along with it, a new twist on push notifications:

Push notifications - Receive alerts from your remote servers even when your app isn't running.

Notice that little 4-letter word in the middle? "Your" remote servers. Starting in the forthcoming OS 4.0, it looks like Apple will be letting developers run their push events through their own servers, and that's a big deal. (Update: Turns out, this isn't the case - iOS developers must still send push notifications through Apple's servers.) For one thing, Apple releasing their iron-fisted grasp on anything content-related is a big deal. But it also means a lot more options for app developers. Options that Android developers ought to have, too.

I decided this whole "push" thing needed a little more attention - and as a time-starved software grad student, what other reason should I need to dig deeper? I found a few ideas on the intertubes - custom implementations of XMPP (somewhat akin to what Google does with the GMail and Google Voice apps), long-held TCP connections into custom backends, and maybe a few other ideas not memorable enough to recall tonight. Unfortunately, none of them were even usable implementations, let alone ready to be used by app developers. Then I remembered a cool project I'd read about while researching push updates for liveblogs: Meteor.

Meteor is a lightweight web server (the whole shebang is under 40KB) that enables streamed, polled and long-polled HTTP-based push notifications to web browsers. The server side opens up sockets for incoming client connections, as well as data sources that can create messages to push to those clients. The client side does a pile of magical browser munging, cleverly dodging XSS security restrictions and enabling those updates to be received and placed into an open web site. How does this relate to Android?

Since Meteor uses long-held TCP connections to implement its push notifications (man I'm getting tired of typing that), provides configurable keepalives, and can be plugged into just about any notification source, it's a perfect starting point as an Android push backend. All that's needed is a native Java client library, and we'll be in business - any app developer that wants to add push notifications to their wares can set up a meteor server (or connect to an existing one) and start creating cool real-time services.

While I'm a big fan of Xtify and the cool stuff they're enabling, I'm also a big fan of independence and autonomy. I don't like the idea of depending on a third-party's server to make my app work - and if that app depends on real-time events, that dependence is wired straight into the app's core. I'd much rather handle my own back end (wouldn't we all?), and be able to wire (perhaps literally) anything I want into it. If someone is savvy enough with Java to write Android apps (no small feat) then they're definitely sufficiently handy to set up a Meteor server.

I'm sure there will be some critics of this effort. Several folks have already spoken up elsewhere with concerns about battery life and network continuity concerns. But if long-held TCP connections are so bad for battery life, how can Google get away with using them for near-instantaneous GMail and Voice pushes? I'm sure we'll discover - in intimate detail - just what implications will come with implementing such a thing on Android. And I hope you'll join me in the exploration!

iPhone OS 4 has been announced for release this summer, and the developer preview is already out. If the latest rumors about a June release of the next iPhone are to be believed, then OS 4 will probably arrive around the same time. The pressure is on - can the Deacon Project enable Android developers with an independent-server push notifications platform system cobbled-together library before iPhone OS 4 hits the streets? If I'm working alone, probably not - but perhaps with a little help, it might be doable. If you're handy with Java and interested in kicking in a few hours to a nascent project, drop me a note at (dave) (at) (daverea) (dot) (com) or hit me up in the comments section.

So, to sum up this long-winded post (kudos to those who've made it this far), I'm proud to announce The Deacon Project - Push Notifications for Android. Deacon will be a native Java library that enables server-based push messaging to Android phones using comet technology. Keep tuned in here for more information, including links to Deacon's repository, perhaps a mailing list, and a proper explanation of why it's called Deacon (and why not).