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.
It. Is. Finished.
Posted by Dave
No, Deacon's Beta release is not finished.
But grad school is. As of 8:30 tonight, my wife and I clicked the mouse button together on my final submission of my final class of my final quarter of a master's in software engineering.
After completing 64 credits in a year, I must say, it's quite a relief! And now we'll return you to your regularly scheduled programming...
Deacon/C2DM Compatibility
Posted by Dave
After reading a bit today about Google's implementation of their new "Chrome to Phone" system, I had an idea that I think will finally give the Deacon beta release sufficient functional differentiation to earn its name.
The Cloud-to-Device Messaging feature in Android 2.2, referred to as C2DM for short, is what makes Chrome to Phone work. Your Chrome web browser contacts a Google AppEngine server, fires off a message, which is then routed through C2DM to your handset. In reading more about how C2DM interacts with developers' apps, I learned that it uses an Android's Intent objects to let an app know that a new push message has been received.
This got me thinking - how could an app developer put together an app that could work both on C2DM-enabled phones (Android 2.2 and beyond) as well as use Deacon to support pre-2.2 devices, or tablets that don't have Google's C2DM framework installed (it's only available on "with Google" devices). If a Deacon-powered service could fire an Intent that matched the format of Google's C2DM intents (reminiscent of a suggestion on the Deacon mailing list), then a developer would only need to write one set of receiving-end code. While deploying separate versions of the app (containing the appropriate service; C2DM- or Deacon-powered) would still be necessary, the code that consumes push notifications could be identical.
So, if you check out the Deacon Project Roadmap, you'll noticed that I added C2DM-compatible intent generation as a Beta release feature (and made a few other updates). Now, I'm very much looking forwarding to having time to work on it! Six days of grad school left...
Quick Update: Beta and Beyond
Posted by Dave
The tough thing thing about unsponsored open-source projects is often that - by necessity - they're left to be completed in one's spare time. For me, Deacon began as a something akin to a personal "20% project" - the analogy being that available time not dedicated to work or school could be spent working on Deacon. But in the final weeks of the final term of graduate school, the volume of such time starts to feel like negative 20%!
Clearly, the last few weeks haven't afforded much time to work on Deacon's beta release, nor will the next few - between work, final exams, preparation of my "mini-thesis" and the celebrations that friends and family have planned. Of course, this period isn't without its downtime - which often finds me making plans or cooking up ideas for Deacon. At this point, I'm planning to push hard toward the Beta in August, after life calms down a bit. This push will include working on a Deacon-powered app - mostly as a means of trying out the library myself - as well as several other enhancements and features.
Once Deacon reaches Beta status, the ball will be in the community's court. Motivation for open-source developers is often derived from adoption, and Deacon is no exception to this rule. Testing, feedback, participation and - ultimately - adoption by developers will drive the level of development that's put into Deacon: basically, "ask and ye shall receive"! Blog comments, bug submissions, feed subscriptions, link-backs and other such digital expressions of interest are the currency of the open-source world - and they're what will keep the Deacon Project going.
Push Opportunity: “Push as the new Premium”
Posted by Dave
It's no secret that the newspaper business is hurting these days - subscription rates and readership of "dead tree" newspapers have been on the decline since the mid-1990s, and some companies are rethinking the decision to provide free online versions of their content. As the population ages and society becomes more-connected, people continue to find and rely on new ways to keep informed, and new delivery channels. While my parents subscribed to our local newspaper for decades, my wife and I have never had a daily paper delivered to our home.
If there's one thing technology such as web delivery and smart phones should catalyze, it's the development of novel business models around content delivery, monetization and specialization. News can already be more customized than ever, whether along topical, geographic or other special-interest lines. It can be delivered via more channels, and the rise of smartphones, eBook readers and MIDs has only expanded the means by which we consume journalistic content. At the same time, all this choice and connectivity has come with a steep price - news outlets still need to pay to keep the lights on, and in recent years it's gotten much harder to charge for the value they generate.
There's a key differentiator that smartphones, and their near-ubiquitous connectivity, can offer: push notifications. (How'd you guess?!) Just as web browsers supplanted newsprint for those in search of digital delivery, push notifications can offer a more real-time alternative. In 1995, your local newspaper could bring you breaking news the morning after it happened. In 2000, they published it to their web site, and you found out if you happened to point your browser there. 2005 brought the rise of RSS feeds, letting software take care of all that repetitive polling for you - but feeds are still a little too geeky for mainstream. Today, however, mobile apps and push technology offer a disruptive opportunity to actually reverse the pattern of consumption.
So, newspapers of the world - do we have your attention? Turning off your online editions, choking back your feeds or continuing to rely on banner ad revenue are not the ways to stay relevant in today's digital marketplace. Offering real-time, pushed news that's tailored to users' unique interests and gets them informed before other news outlets can? That just might set you apart.
[Image: Sanja Gjenero, used under license]
Push Topics: Security
Posted by Dave
Note: This post is part of a series on the Deacon Blog that will address topics in implementing Push Notification systems. Naturally, this coverage is oriented toward the Deacon Project, but the topics and issues discussed are often widely applicable.
"Software security" - it's been a hot topic in the mobile phone world (or at least my feed reader) lately, what with multiple iPad and iPhone related security snafus at AT&T, and the release of the first major-label security software for Android phones by Norton/Symantec. With lots at stake in the mobile world - sensitive little things like GPS locations, contact lists and phone records - security should be a consideration in any mobile computing endeavor. Push notifications are certainly no exception.
Introduction
Bass, Clements and Kazman define a system's security as it's "ability to resist unauthorized usage while still providing its services to legitimate users." [1] We can decompose this requirement into two equally-important areas: determining which users are "legitimate", and restricting access to only those users. In push notification systems (and those based on Meteor in particular), there are also two types of users: push subscribers (those that receive notifications) and channel controllers (those that send notifications). Last in the rundown of areas to consider comes data transport: push notifications can traverse untrusted networks as they are generated, sent and received.
But before we dive into the security mechanisms that can be used with Deacon and Meteor, there's something important to keep in mind. For efficiency's sake, remember that push notifications should be as small as possible to minimize the load on the server. This is Google's advice when using Android's C2DM system; a notification's payload should only contain a "tickler" for the receiving app (such as an ID number or URL), which should then handle subsequent retrievals or processing after it receives the push. To enforce this behavior, Google limits C2DM payloads to 1024 Bytes - no such limit exists in Deacon, but it's still a good idea to follow the "tickler" approach.
So what can be done to secure push notification systems? It boils down to three relatively-simple practices: don't accept subscriptions from unauthorized users, use secure connections for channel controllers, and don't send data payloads that require secure transport. We'll take a look at all three after the jump...
Push Opportunity: The Tour de France
Posted by Dave
A huge opportunity for mobile push technology is in professional sports - there are few other topics where real-time updates mean so much to so many. After I bought my first Android phone last November, I searched for apps that could provide real-time coverage of the Winter Olympics: there weren't any. The few apps in the Android Market that promised coverage of the Games were disappointing. They either used battery- and bandwidth-hogging polling techniques (we're looking at you, SportsTap!), or just encapsulated browser-based data with no notifications. Not long after, Deacon got its start during the run-up to the NHL playoffs. March Madness came and went, as did the Boston Marathon, the Kentucky Derby and the Preakness, and (in a few days) the 2010 World Cup.
Tomorrow, the 2010 Tour de France will kick off in Rotterdam - and the Android Market remains disappointingly devoid of apps that can push real-time updates to eager fans. While the Tour does offer an official iPhone app, they're missing out on a substantial customer group - one that represents possibly the fastest-growing smartphone platform with a 160,000 handset-a-day activation rate. Third-party app developers are missing a significant opportunity too - with no "official" app in contention, independent developers' chances of offering the must-have app for following the Tour are much greater.
This is a call to Android developers that goes beyond Deacon: The Android ecosystem needs push apps! So far, the vast majority of Android handsets don't run Froyo - and while Cloud-to-Device Messaging from Google isn't a long way off, the opportunity to deliver push-based apps now using Deacon, Xtify, Urban Airship or whatever framework you choose is ripe for the picking!
(Image: Wikimedia Commons, public domain)
Quick Update: Beta Progress
Posted by Dave
For every time you feel like you've covered a lot of ground in software development, it seems like there are often other times when progress grinds down. We bit off a big chunk with the Alpha release of Deacon, and achieved a lot of functionality in just a few weeks' time. But without feedback, it's hard to maintain that cadence.
If you've tested the Deacon Push Notifications library, or are considering giving it a try, here's how you can help:
- Download the latest release (there's been one service release since Alpha) and try it out
- Report any issues that you find on the Deacon Issue Tracker
- Jump on the mailing list to ask questions or make suggestions
As a reminder, Deacon isn't just for Android apps! The core of Deacon, the DeaconService class, is pure Java and can be used in any Java application. We then use a wrapper around the DeaconService class to provide Android-specific functionality (such as network connectivity detection or context awareness).
Of course, our plea for assistance with automated testing is still open - feel free to comment here on the blog, or head over to Stack Overflow and add your two cents there...please?
A coder’s birthday present…
Posted by Dave
I hope you'll excuse me, but I'm going to get personal for a moment...
After spending a great morning talking about Android, lamenting car problems and happily discussing life in general with Spencer, and after enjoying a great birthday lunch with my colleagues (at which they sang, and the diner lady offered up a free slice of Godiva cheesecake), I got home and found a new email: Deacon has its first issue.
I imagine most folks would see "[GitHub] New Issue" in their inbox and groan, then perhaps click into the message with trepidation or dread - but I count this issue among the nicest birthday gifts I've received this year. Why? Because I'm pretty new at this whole "software engineering" thing, and the fact that someone out there is taking an active interest in what my friends and I have created is really, really encouraging. Maybe that's just me being a touch narcissistic, but it feels good to know that another engineer is interested enough in our project to try it out.
Though I'm not [yet] a parent, I imagine this is a bit akin to seeing your kid spit up for the first time. Sure, it's gross and it smells funny, but damned if you're not just a bit proud that it's your kid that made that mess!
(Image: Wikimedia Commons, public domain)
Countdown to Beta … little help?
Posted by Dave
According to the Deacon project roadmap, tomorrow is supposed to be the day we release our Beta edition. The library, at least, is feature-complete for Beta at this point - mostly because we identified very few new features between Alpha and Beta releases, choosing instead to focus on increasing the robustness and eliminating (sometimes preemptively) bugs.
What's missing is testing. We haven't got much expertise in the realm of testing Android applications - in particular, because there are a lot of different conditions that Deacon needs to be subjected to in order to test out its error-handling capacity, we'd really like to automate this testing. F8'ing the emulator over and over gets old very quickly! In particular, we'd like to be able to write tests that automatically toggle the emulator's (or a real device's) network connection off and on, and switch between 3G and WiFi connections. So, we turn to you, the dev community - can anyone recommend a clean way to do this without resorting to hacking around with airplane mode?
If you can help, please leave a comment on this post, check out the corresponding open question at Stack Overflow, or hit us up on the Deacon project mailing list! We'd offer you a free copy of Deacon, but since that's already open-source, the best we can offer is to buy you a beer if we should ever meet (say, at Google IO 2011?)...
As for that Beta release - well, there aren't any giant nagging to-dos holding it back, but by the same token little has changed since Alpha. It would certainly make a nice 30th birthday present for me, but I feel it should offer a bit more value. Hanging out the "Beta" flag might encourage more developers to test out Deacon, which would hopefully garner some feedback and even more opportunities for us to improve the library. For tonight, I think I'll sleep on it...
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!
Project Links
- Deacon Downloads
- Deacon Mailing List
- Deacon on Twitter
- Deacon Wiki
- Repository: Deacon Demo App
- Repository: Deacon Source Code
- The Meteor Server
Categories
Deacon's Twitter Feed
- More good press for AndSpot Market! http://bit.ly/aKZA6k
- [Deacon] http://bit.ly/aOf4cs David Rea - General code cleanup, adjusted package organization, added first few JUnit test cases
- [Deacon] http://bit.ly/bXoukg David Rea - Updated meteord.conf to correct error
- #android push notifications blog post: It. Is. Finished. http://bit.ly/aXaLkz #android
- Working out of #bouldercoffeco in the #roc #southwedge is fun - especially with a hot mocha!
Archives
Meta
