After struggling with a few apps which use lots of battery and network resources while trying to sync half the Internet onto the device, one wonders if Apple didn't accidentally have a point with their claim that most apps don't really need background processing as long as there is a way to push background notifications to the device.
But since Android does support background processing, this framework isn't limited to simply pass on notifications to the user. An app could still choose to act on some incoming notifications in the background, i.e. by fetching and caching the content which the notification event refers to. The frameworks seem flexible enough to create all kinds of new applications which create a more seamless integration of mobile and web-based applications.
This leads to a split application design, where part of the application resides on a server in the Internet, doing whatever the background service on the device would be doing, but with a lot less worries about power and bandwidth. If there is something new and interesting, a small notification is pushed to the device to alert the user, that there is something worth looking at. As long as the device has network connectivity when the user acts on this notification, the details of this notification might be about is loaded on demand. If mobile networks are ubiquitous and fast enough, the resulting experience is almost as good as an app which continuously loads and caches content in the background - and a lot friendlier on battery and network usage.
The upcoming Android 2.2 release includes support for the new Android Cloud to Device Messaging Framework, which promises to do that and then some in a generic fashion.
If an app on an Android device wants to receive some particular notifications, the application registers to receive the notification events from the Android OS and requests an authorization key from the C2DM framework and sends it to its backend server in the Internet (e.g. by http request, SMS or whatever). When the server wants to push an event to such a registered device, it uses the authorization key to contact the C2DM service, which will then push the notification to the device.
One of the sample apps included with the framework - Chrome to Phone - shows how this could work. From a Chrome browser extension, the user can choose to send the current page to their Android device, where the page then can be loaded from an entry in the notification bar:
But since Android does support background processing, this framework isn't limited to simply pass on notifications to the user. An app could still choose to act on some incoming notifications in the background, i.e. by fetching and caching the content which the notification event refers to. The frameworks seem flexible enough to create all kinds of new applications which create a more seamless integration of mobile and web-based applications.