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.
It's always fun when Deacon users and developers write in to let me know they've successfully integrated Deacon into the project or product. I received one such note this week... The developers of Make Me Droid have incorporated Deacon into their application builder, allowing their users to incorporate Android push notifications into apps they build with the system. Push notifications are delivered using Make Me Droid's server, so there's no need for users to worry about setting up a notification backend.
We wish the team at Make Me Droid much success with their product launch, and welcome them to the Deacon community!
Back in October, a multi-disk failure at our hosting provider caused the un-recoverable loss of the Deacon Project mailing list... Unfortunately, the list archives (which contained some useful technical info) and the member list fell victim to Mr. Murphy. There have been a few support requests since then, mostly handled in the comments here, or (more appropriately) on the Deacon Issue Tracker. This has been fine, but I wanted to move back to having a central place to collaborate, ask questions, and discuss Deacon.
Since GitHub, despite being awesome in almost every other conceivable way, doesn't seem interested in adding any manner of forum or Q&A venue, I decided to set up a Google Group for this purpose. You can find it (and join it!) here:
Links will be updated momentarily...
Happy 2012, everyone! A few months ago, the generous folks at Attendit.se donated a virtual server for Deacon testing. As of today, that server is live, running the standard set of Meteor test channels for Deacon clients.
The server address is: test.deaconproject.org (188.8.131.52)
The available channels are:
With traffic on recent bug-fixes quiet, new contributions received, and all else otherwise stable, I'm getting ready to bump Deacon to version 1.0.0. I've pushed a new tag to the Deacon repository on GitHub, and made quite a few updates to the codebase to better-accommodate anticipated downstream changes. I've decided to do this version bump because Deacon's development pace lately has been slow; my time to work on it is limited, and development is largely being driven by bug reports and contributed features. So I'm going to let features drive the minor release numbers, and bug reports drive the incremental numbers.
New in this release:
- Deacon is refactored to use a generic PushReceiver class to handle all top-level controls and configurations (i.e. start, stop, timeouts, etc.). This is sub-classed by server- or transport-specific client implementations for particular push mechanisms.
- All Meteor-specific client code has been pulled out into MeteorPushReceiver.
- The Android-specific "Deacon" class has become "AndroidPushSupervisor", which is instantiated by a hosting Android application in parallel with its chosen PushReceiver. The application registers the PushReceiver with the AndroidPushSupervisor, which will then call stop() and start() methods based on received BroadcastIntents containing network connectivity information.
- The methods in the DeaconObserver interface and DeaconObservable class have been updated, and some of the high-specificity methods have been deprecated. Those deprecated methods will still work (and, in the case of DeaconObserver, still be required in application code) but will be removed before the final 1.0.0 release.
- Important! Deacon no longer handles Android inter-thread communication using Handler and Message. This was a Demo-oriented hack to get around Android's requirement that UI object accesses only take place from the associated Activity's thread. This inter-thread communication is really the responsibility of the service that hosts Deacon (and instantiates whatever PushReceiver is required).
- Incorporate Cyrille Colin's SSL- and authentication-capable Meteor client as a subclass of MeteorPushReceiver.
- Refactor the unit test to decouple access to the PushReceiver and MeteorPushReceiver classes, and test them separately.
- Remove extraneous System.out.println() and Log.d() calls, and other general code clean-up.
Back in June, I announced some new supporters for the Deacon Project - The generous folks at Attendit.se, a telecom and IT solutions provider located in Stockholm, offered their support for the Deacon project. One specific offer they made? A virtual server in their cluster. As of yesterday, that server is online and available - and in short order I'll be provisioning it with Meteor software and our test channel scripts. Considering our current test server is an aging Dell Poweredge sitting on my rather-unreliable residential Internet connection, powered by my occasionally-problematic power utility, moving to this server will offer a big improvement in reliability and consistency. Once we're settled in, I'm also looking forward to working with the Attendit folks to perform some load and scalability testing.
But wait! There's more! Not only is the Deacon Project's server moving, but the library itself has made a move - into the Android Market! Android developer Cyrille Colin has released - as a companion to an article he wrote for a French open-source magazine - the app ZnagPush. This application uses a modified version of Deacon - which Cyrille plans to contribute back to the project - to deliver notifications and updates from Nagios server monitoring software to Android devices. Cyrille's updates included improvements to the reliability of message delivery, as well as the use of a SSL connection to the Meteor server for enhanced security. If you want an early look at some of Cyrille's code, you can find it on his GitHub fork of Deacon's repository.
Bad news to report, folks: Apparently, the hosting provider where the Deacon project's blog and mailing list are served experienced a triple-disk failure on their RAID-6 array. Beginning about September 28th, the Deacon Mailing List archives and membership data were lost. As you can see, the blog is just fine...
I am working on finding an alternate provider for the Deacon mailing list; for now, the blog will stay on its current host, but I would like to explore options for porting it to GitHub Pages...
Update 2011-10-12: I've pulled the Deacon mailing list down from host's mailman server. The redirect for existing links will be broken for a while - I'll post an update here if/when I set up a new mailing list. Since it saw very little use, either for Q&A or planning discussions, I'm debating whether to set up something new at all. In the absence of any sort of discussion group feature from GitHub, I'm leaning toward Google Groups. If you have a strong desire to see the Deacon mailing list resurrected (or any opinion on the matter) feel free to sound off in the comments...
Thanks to the testing efforts of GitHub user Bonna and our contributors at Attendit, we've uncovered a somewhat nefarious bug between Deacon and Android that leaves a parent app hanging if Deacon's connection "goes dark" without an explicit disconnect event. While this isn't the sort of event you see with emulators and comfy lab environments, it does happen out in the real world of fluctuating coverage and unpredictable 3G/4G/WiFi transitions. Thanks to some debug output from Bonna's gingerbread device, we think we've got it resolved - a fix is currently being tested in the feature-pingcheck branch, and will be merged into master if it resolves the issue.
Speaking of branches, there's something else I've been working on. Ever since reading through Vincent Driessen's nothing-short-of-stellar Git branching-model workflow write-up, I've been looking forward to using it on Deacon. After spending some time with biz-partner Pat sand-boxing around with Vincent's equally-awesome git-flow extensions and Justin Hileman's git-flow autocompletion, we're hooked. I'm already using git-flow with Deacon on my local development box, and when we're ready to merge in the bug fix I described earlier, I'll push the new branch structure to the github repository. This also means that the default branch on github will change to develop, and that master will only hold release snapshots that are used to build the .jar files found in the downloads section.
If you're using Git for version control or SCM, I definitely recommend you check out git-flow. Git is extremely flexible, and imposes very little structure on branching and merging - which is part of what makes it so powerful. But with no tool-imposed discipline, a repository with several contributors can quickly become a rat's nest of branch clutter and inconsistent tags. git-flow imposes a minimal amount of discipline that can really clean up a project's repository, and fits nicely and unobtrusively into just about any software development process. Now...if only we could improve people's commit messages!
A little over two months ago, I announced that the Deacon Project would be "back burnered" due to waning community interest and a general shortage of free time and spare cash on my part. I added a caveat, however: If anyone shows some interest in helping the project grow and mature, they have an open invitation to participate.
In the last two weeks, two new contributors have expressed an interest in seeing Deacon live "beyond beta"...
The first new contributor is a Swedish company, Attendit, providers of telephony and IT support services based in Stockholm. Leading the charge there is Ola Samuelsen, an open source software enthusiast with experience in software development and telecommunications. Along with Ola, devs at Attendit will start off by paying some much-needed attention (see what I did there?) to the Deacon issues list, fixing some longstanding issues that I've been too busy to definitively resolve on my own.
From there? We have a number of other ideas in the works too, with the goals of improving Deacon's robustness and extensibility, as well as fostering more community involvement...
Around the same time I heard from Ola, the topic of push notifications surfaced in a discussion with my partners at our engineering consulting firm, AppliedLogix. We specialize in developing embedded systems, and there are certainly many ways that the embedded world can benefit from mobile push capabilities. We're still exploring ideas, but we see several ways our firm might be involved in the Deacon Project, as well as other complimentary push-centric developments.
These days, push capabilities have gone beyond being a power-user feature for mobile software - in many application genres, they're simply expected. Now, emerging uses for push data delivery have the mobile industry buzzing, with new ideas surfacing all the time. An environment like this has a large solution space - and there's plenty of room for options of all sorts. I'm looking forward to seeing Deacon become a serious contender among those options, and thanks to the help of my colleagues at AppliedLogix, and new friends at Attendit, we have a solid shot at making that happen.
One year ago, I was working through my masters degree in software engineering. Google had not yet introduced Android 2.2 "Froyo" or cloud-to-device messaging (C2DM), and I had only purchased my first Android device (a Motorola Droid) a few months prior. Not only had Google not announced the "Gingerbread" or "Honeycomb" variants of Android - people had barely started guessing which confections would mascot these coming releases! It was amidst this zeitgeist that the Deacon Project sparked to life, late in the evening on April 16th, 2010, born of my desire to see equity in push capabilities between Android devices and their sundry fruit-themed competition.
Before the Deacon team reached our Alpha release, Google introduced C2DM with the arrival of Froyo. The team opted to press on, to offer developers an independent push alternative where they could control the entire pipeline and support older devices. At a proof of concept level, I believe the team achieved that goal. We got the attention of many app developers, peaking at nearly 2000 web page views per month. At one point, we were even offered a sponsorship; it would later fall through, but not without injecting a healthy dose of enthusiasm.
Unfortunately, we're learning that the cost of maintaining an open source project isn't zero. Domain names and hosting aren't free, coding and testing and responding to e-mails consume precious time, and motivating participation isn't easy. Thus far, our Pledgie button has gone unused, and adoption hasn't been strong enough to give the project much self-sustaining momentum. There have been many projects that flourish with the efforts of just a handful of curators (dcraw, jhead and dnsmasq come to mind), but strong uptake and personal usefulness are often requisite motivators for ongoing development. Frankly speaking, that simply hasn't happened here - and as a result, it's been difficult to attract contributions in the form of code or testing, and correspondingly difficult to achieve a self-sustaining critical mass.
I still believe that The Deacon Project could take off. It offers a value proposition - complete infrastructure control and support for all Android devices - that's beneficial for many mobile-app business models. For now, though, I will be scaling back my efforts to test and polish the Deacon library to free up time for some other projects. Of course, I'll be happy to continue answering questions via the mailing list, making minor improvements in the codebase, and watching the issue trackers. I'd also be thrilled (honored, even!) to receive code contributions in the form of pull requests and patches - and interested parties can certainly inquire about direct commit access. If you or your company really wants to see Deacon grow and mature, please contact me - with the right interest, conditions and support, there is always the potential to go further.
Another late-night coding session, another learning experience... It seems that the Linux per-process open file descriptor limit that had me a bit concerned has a bark that's worse than its bite:
dave@server:~$ ps aux | grep meteord
meteor 10613 76.2 6.6 11156 8356 pts/1 R Feb23 13:11 meteord daemon
ddr4179 11732 0.0 0.6 3004 768 pts/2 R+ 00:00 0:00 grep meteord
dave@server:~$ ulimit -n
dave@server:~$ sudo lsof -p 10613 | wc -l
As it turns out, some limits in the meteord.conf file were preventing persistent connections from many of the Deacon instances in my previous test, and so only a limited number were able to hold a connection at any given time. I've fixed that now, and the tests seem to be running a bit more smoothly. More results as I get them...