Froyo & Deacon

At today's excellent and very exciting Google IO Keynote, the fine folks at Google announced Android 2.2, codenamed "Froyo". This newest flavor of Android offers a lot of cool new stuff, and as Android enthusiasts, we at the Deacon Project are very excited! Among the new features announced was "Cloud to Device Messaging", Google's take on push notifications for Android. How might this affect Deacon? Here's our take:
We started the Deacon Project for two main reasons: Android didn't offer native push notification capability, and commercial push solutions left app developers dependent on third-parties to deliver their messages. While we're stoked to learn more about "Cloud to Device Messaging", the appearance of this new feature in Froyo doesn't really change our goals or our mission:
- While Froyo will provide out-of-the-box push messaging capability for new Android devices, there are still hundreds of thousands of devices in the wild that will never see an upgrade to Android 2.2. These users deserve push-enabled apps, too!
- The "Cloud to Device Messaging" in Froyo requires that push notifications be sent through Google's servers. For developers who value infrastructure autonomy, or those with special needs (such as physical security apps or notifications generated by embedded devices) Deacon will continue to provide push notifications through your own server.
Despite the announcement of native push offered by Android 2.2, the Deacon Project plans to continue developing our open-source library. Deacon can be a lightweight, free-software fallback for developers who want to offer push-enabled apps to older versions of Android. For autonomy-sensitive applications, it offers an infrastructure option that doesn't introduce outside dependencies. We certainly don't expect that most developers will use Deacon in favor of the stability, ubiquity and simplicity of Google's solution, but we do believe Deacon will be a good answer to some specialized needs, and will help in creating push-enabled apps for devices that don't run Android 2.2.
Be sure to stay tuned as the Deacon team continues to work toward our Beta release in early June!
Screencast: Push-Enabling your Android App with Deacon
Want to try out the Deacon Alpha release? Here's how - a simple video introduction to "Deaconizing" your app and receiving push notifications.
Assuming that you actually want to see what's happening, and not just hear me yap about it, I'd recommend using the full-screen button!
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!
DeaconTest Released
If you read our recent post about battery life, you might have asked "where can I get my hands on that app?" ... Or, maybe you thinking that is just wishful thinking on our part! Either way, the code for DeaconTest has now been posted to its own repository over at GitHub:
http://github.com/davidrea/Deacon-Test/
Over the next few weeks, we expect to transform the test app from a mundane, text-spewing utility to a full-on demonstration of Deacon's capabilities. Deacon-Test will continue as our internal testbed for the Android-specific portions of Deacon, as well.
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.)
Deacon’s Modus Operandi
A recent post over at the Android Developer Blog got me thinking: How can we design Deacon to maximize the flexibility that developers have in integrating our library into their apps...
In "Multitasking the Android Way", Google software engineer Dianne Hackborn explains Android's multitasking, and the three ways Android apps can run:
- As an Activity - Apps run in the foreground when a user navigates to them, and are subject to being killed as part of the Android Application Lifecycle if they are no longer shown on the screen.
- As a Broadcast Receiver - Apps register (using their Android manifest) to receive callback-style notifications if a particular event occurs. For instance, an app could receive a callback at a particular time by registering for a timer broadcast receiver.
- As a Service - Apps run in the background whenever enough system resources are available to sustain their operation, and can generate notifications or other user-facing actions at-will.
Realistically, we don't want Deacon's design to force app developers into any one of these modes; the more ways there are to use Deacon, the more innovative things developers will dream up to do with our little library. I envision the most common usage to be in the service mode, where an app's background service uses Deacon to listen for incoming push notifications, then act upon them in some user-facing way. But there are certainly other ways the system might be used, and we're going to do our best to make sure that Deacon can make your app push-aware no matter how you construct it.
Be sure to keep tuned in here for updates on Deacon's progress - we will be sure to make an announcement when alpha testing begins!
Push on Android: A Rundown
While we at the Deacon Project like to think we're breaking some new Android ground in releasing our push client, we're definitely not the first folks to attempt such a feat. There has been lots of talk and lots of action elsewhere, and this post is an endeavor to pull together what we know of so far. In the future, I'll likely put up a page that sums up the different methods and tools for providing push notifications to Android devices...
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?
Deacon repository online
The Deacon Project now has its own repository over at GitHub:
- Repository URL: http://github.com/davidrea/Deacon
- Wiki / Documentation URL: http://wiki.github.com/davidrea/Deacon/
I've checked in a bit of proof-of-concept code that I hastily assembled recently; it's just a quick Java hack that connects to the Meteor demo server and spits the output to the console. If you check it out, I'm sure you'll agree that Deacon has a long way to go!
You might also note that the Deacon GitHub page has a Pledgie link that looks a little like this:
Eventually, I'm confident that Deacon will be a help to someone, somewhere, who wants to add push notifications to their Android apps. If that's you, I hope you'll consider donating. Alternately, if you want to help the project get off the ground, tossing us a teeny bit of fiscal encouragement will be much-appreciated!



