Google App Engine (GAE), a cloud based solution for hosting servlets, features a whole range of APIs with two candidates for building a notification system:

• the Google channel API 
• Extensible Messaging and Presence Protocol (XMPP)

GAE implements a HTTP servlet container that can either fuel REST-based web services or plain HTML applications. In this internet-based communication model, the client normally initiates communication and pulls information from the server. A vast amount of mobile applications however requires push technology where the request is initiated by the server, i.e. GAE.

In ARLearn for instance, both the smartphone app and the Google StreetView application build on on push technology to notify the user when new content is available or when the (team) score has been altered.

XMPP and the channel API enable such push notifyications, but both have pros and cons. XMPP is the successor of the jabber protocol for exchanging chat messages. This protocol supports communicating plain chat messages and structured xml messages which makes the protocol a candidate for notifications. Originally, the ARLearn smartphone app implemented an XMPP client, listening for messages from the account that is associated with the GAE application. There are however many disadvantages to this approach:

• In order to communicate with the server, one needs a Google account. In the case of ARLearn, the user's Google account is used to communicate through the google talk server with the GAE XMPP account. This means that the GAE account becomes visible in your list of Google talk friends, which is a bit artificial.
• Google talk is a service hosted on talk.google.com on port 5222 or port 443. ARLearn experience has shown that a connection with talk.google.com on 5222 is blocked on many public or corporate networks.
• For StreetLearn - a JavaScript Google StreetView mashup - the situation is even worse, as the browser blocks communication to domains different from the domain hosting the JavaScript code.

The Google channel API implements long polling (aka 'Comet programming'). With this technique, the browser sends a request to the server that does live beyond the 30 seconds limit. The server holds this request and once information is available, a response is sent to the client. As the channel API was designed for web applications and targets JavaScript clients only, it overcomes many of the limitations of XMPP:

• No cross domain issues 
• No Google accounts necessary and thus no side effects like messing up your contact list. As this API features concepts like channels, client identifiers and tokens to access channels, it enables the dynamic creation of communication channels. 

There is one big disadvantage to the channel API: it only features a JavaScript client. As a result, native smartphone apps built in Java or Objective C cannot profit from this technology. For Java, an elegant short solution (4 java classes of core code) has been implemented by Tom Parker that reverse engineers this JavaScript API. This makes the channel API usable in java-based desktop applications like native android.