Deacon Sighting: Make Me Droid
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!
Deacon Version 1.0.0, Release Candidate 01
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.
It’s Moving Time
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.
Onward! Deacon Project gains new contributors, presses toward 1.0
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.
Deacon Demo App: Prettied up and Ready to Rock
For quite a while (read: since October) I've been meaning to spend some time improving the Deacon demonstration application. What we had before was OK - it connected to the Deacon test server, showed some messages coming in, and generally indicated that something was happening behind the curtain. But I wanted to add more configurability, and more visibility into Deacon's state. Most importantly, I wanted to switch to running Deacon in a service, rather than within the app's user interface activity.
With the 1.0 release of the Deacon Demo app, you can choose the channel to subscribe to on the Deacon project's test server, as well as stop and re-start the Deacon instance. Icons and text indicate whether the Deacon instance itself is running, as well as whether the device has a network connection. If you navigate away from the Deacon Demo app's UI, the corresponding service will create a notification if any push messages are received that contain a prime number payload - clicking the notification in the pull-down list will bring you back to the Deacon Demo activity.
You can download this app directly from GitHub using the QR Code below. Make sure you have the "Unknown sources" checkbox ticked in your device's Application Settings!
Please log any problems you encounter, or feature requests, at the Deacon-Demo issue tracker. For a look at the source code or more project details, check out the Deacon Demo GitHub project page.
Deacon Beta Released!
The Deacon team is proud to annouce the release of the Beta version of the Deacon push notifications library for Android!
If the Deacon Project blog's hit stats are any indication, weekends on the web are pretty quiet when it comes to Android Push Notifications. But this weekend has been a busy one around Deacon HQ... After plenty of third-party testing over the last month, as well as some code updates and experimentation, this weekend marks the entry of the Deacon push library for Android and Java to "Beta" status.
In addition to all the functionality included in Deacon's Alpha Release, Beta includes updated design information, the beginnings of an automated test suite, and several bug fixes. Contrary to previous indications on this blog, the Beta release does not include compatibility with Google's C2DM framework. While this was an exciting potential feature, the Deacon developers received precisely zero interest in it from the developer community. Unless robust demand for C2DM compatibility appears in the comments section, or on the Deacon Project mailing list, further development in this area will not be pursued.
In the run-up to this Beta release, several developers contacted me to express an interest in Deacon. Were it not for their enthusiasm, and their constructive feedback on Deacon's operation, I would likely have shelved the project entirely. Special thanks to Lee J. (@britishturbo, developer of Tweetissimo) and Kasper Holtze for their encouragement and interest.
At this point in Deacon's evolution, the library should be sufficiently robust to permit development of push-based Android and Java applications with a reasonable expectation of performance and stability. While Deacon has not (to my knowledge) been tested in large-scale deployments or production environments, the real-world tests to which it has been subjected indicate that it is robust to changing network conditions, consumes network bandwidth efficiently, and minimally impacts handset battery life. It is my hope that this Beta release will encourage more developers to actively test Deacon in their push-based Android applications, and that they will report on their experiences on Deacon's mailing list and bug tracker.
Following this Beta release, I plan to move to a largely reactive and contribution-based model for Deacon development. I will gladly follow up on reported issues, respond to mailing list inquiries and make any code changes needed. Further, I will welcome submitted patches and pull-requests in order to incorporate code changes from the community. However, barring changes resulting from my own Android app development activities, I do not plan to aggressively add features or enhancements. Deacon, like most Open-Source projects, belongs to its community, and community involvement will be the key driver in its ongoing evolution. In short: Ask and ye shall receive. Code and ye may contribute. But sit thee not silent.
[Image: Wikimedia Commons (public domain)]
Deacon Alpha Released!

The Deacon team is proud to annouce the release of the Alpha version of the Deacon push notifications library for Android!
This release implements all of the Alpha functionality listed on Deacon's Project Roadmap: connect to a single Meteor server, receive push notifications from multiple channels using the long-polling technique, and automatically manage server connections in response to changes in the state of a device's network connection. Additionally, we pulled "notification catch-ups" ahead from our Beta release into Alpha; this feature of Deacon provides automatic retrieval of push notifications that might be missed due to network interruptions.
There are two ways to try out Deacon's Alpha release: download the source code (tagged 0.1.0_alpha) at GitHub, or grab the Deacon alpha jar file from the repository downloads area. Either can be added to your Java or Android project's build path, and their use is described over at the API Reference.
Of course, to test out Deacon you'll need a Meteor server that's configured to "speak Deacon" and format its push notifications the way Deacon expects. If you want to set up your own (following the server installation instructions on the Meteor web site), the source code includes a meteord.conf file that's ready to go out of the box. While setting up a Meteor server is fantastically-easy, you might just want to try out Deacon by itself. In this case, you can use our test server:
| Server: home.daverea.com Port: 4670 |
||
| Channel name | Channel description | Data payload |
| 2sec | Sends a push notification every 2 seconds | Random integer |
| 10sec | Sends a push notification every 10 seconds | Random integer |
| 1min | Sends a push notification every 1 minute | Random integer |
| 10min | Sends a push notification every 10 minutes | Random integer |
We hope you'll give Deacon a try! It's probably a bit rough around the edges, but the more developers test it out, the better it will become. You can leave feedback here in the comments, use the Deacon Issue Tracker at GitHub, or join the deacon-talk mailing list for a direct line to the dev team. To all those who download and try Deacon, we thank you for being part of what makes Open Source Software so great!
Slides & Video: Deacon Lightning Talk
It's been just a few hours since Spencer and I joined a bunch of other way-cool, enthusiastic, funny, friendly and very welcoming techies from Interlock Rochester. The venue, Coworking Rochester, was way-cool too, and they even had beer! At any rate, we figured we would share our slides with you here, and some video too (thanks to Computer411, one of the attendees)...just hit "Continue Reading" below!
Deacon: Appearing at a Lightning Talk near you

Ever been to a Lightning Talk? I haven't ... but (along with fellow Deacon contributor Spencer) I'm going to be giving one on The Deacon Project this coming Friday! We'll be attending Rochester Interlock's second lightning talks event, giving a five-minute rundown of what Deacon is and how it works, and hopefully drumming up some local interest in the project.
- Who? Deacon contributors, alongside a whole bunch of cool makers, devs and other fun people...
- Where? Coworking Rochester, 72 Cascade Dr. Rochester, NY 14614
- When? Friday, May 14th at 7:00PM
- Why? Learn about cool stuff people are doing, including Deacon!
Progress: Battery Life Testing
As a runner, I know a thing or two about milestones. Whether it's watching the mile-markers tick by during a race, or just topping that pesky hill climb on a weekday jog, there's something about crossing landmarks that's encouraging. It makes you want to run that much harder...
In the marathon of software development, Deacon has been passing some exciting milestones this past week. For one thing, we've got our own Meteor test server set up, complete with a customized configuration and message format. Thanks to that achievement, we've been able to start testing with feed sources that are a little more controlled than the Meteor Demo Server!
Setting up our own feed server enables something important from the Deacon Roadmap - battery life impact testing. While some preliminary tests by Deacon contributor Faisal Abid (using the high-bandwidth "shooting star" stream from Meteor) had us a little nervous, today offered some very promising results. We set up Deacon in a test app, running on a Motorola Droid, receiving one push notification per minute from the test server - and in three hours of continuous operation, the app didn't move the battery meter, or even appear on the handset's "Battery Use" screen. After almost seven hours of cumulative operation, Android reports that the Deacon test consumed about 2% of the battery's capacity power used since the handset was unplugged - not bad for a message a minute, with hardly any use and no telephone activity!
While our initial battery testing is about as scientific as it is precise (which is "not very"), it at least gives us a rough idea of how much energy Deacon consumes - and we still have plenty of room for optimization. For now, we'll keep working toward Deacon's alpha release having put to rest any concerns that long-held TCP connections will drain too many precious milliamp-hours!
(Both of the screenshots above were taken from the Droid that ran the test, just after it was plugged back into the system in debug mode. The test started at 11:30AM and ran [almost] continuously.)






