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.