Froyo & Deacon
Posted by Dave
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
Posted by Dave
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!
Deacon Alpha Released!
Posted by Dave
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!
Project addition: Mailing list
Posted by Dave
It seems like just about every open source project has a code repo (our repo, on GitHub), a project wiki (our wiki), a bug tracker (our issues) and a mailing list. As of this morning, the Deacon Project has added this last piece of the puzzle. While many open-source projects go with separate mailing lists for users and developers (and sometimes a low-traffic "announce" list), we're going with just one list while we get started. You can reach our mailing list from the Links section in the sidebar, or by surfing over to this address:
http://deaconproject.org/mailing-list/
If you're interested in contributing to Deacon, keeping tabs on what we're up to or receiving updates when we release new versions, please sign up for the deacon-talk list!
Slides & Video: Deacon Lightning Talk
Posted by Dave
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
Posted by Dave
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!
DeaconTest Released
Posted by Dave
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
Posted by Dave
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
Posted by Dave
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!