This is why I am very keen to get my hands on Palm's Mojo SDK and start getting beneath the hood of WebOS, a web standards based framework for mobile apps. We have seen this approach before with Opera Platform, a withdrawn technology that allowed mobile app creation using web standards, modified to allow script access to the underlying APIs, or some of them.
Not only does WebOS allow app creation using web standards, but it also purports to support application concurrency within the user application space (and not just the system apps). Let's see how that works, but there is hint of a JSON messaging bus between apps, which, if true, is a potentially elegant solution.
The real crux of the matter is how to support concurrency on a mobile device whilst supporting a meaningful user experience. For example, if App A does something useful in the background that demands the attention of the user, then how should App A get the user's attention? How should the app be given focus? This should be solved via a judicious mix of application developer control and some kind of UI convention on the device for dealing with concurrency, given that the user focus is very narrow on a mobile at any one time (and typically confined to single-window displays).
From the hints we are getting, then it seems that WebOS supports a design pattern and UI convention that I have long advocated for the support of message handling in a concurrent apps environment. This is the missing design pattern because, apart from the crude MIDP Push Registry, it is not supported on most mobile devices (mostly due to their lack of support for concurrent user applications, which even the iPhone suffers from).
The idea, shown above, is that any application can consume messages at any time. I suspect that the JSON messaging bus might support this in the WebOS (pure speculation on my part), but in the long term it is important to see mobile apps frameworks (and networks) support reliable asynchronous messaging into the device on a per application basis - i.e. the ability to send and address a message to an application on the device, not, as per SMS, to the user. Various transport means are possible (see right), although a single URL namespace convention still needs to emerge (plus reliable underlying transport - no use sending an XMPP message if we can't guarantee it's delivery, including the out-of-band case, whilst this remains problematic in wireless networks).
In the design pattern shown above, we adapt the well-known delegate model to allow each application to have an always-on response to inbound messages, which get handled by a delegate object. These are created by the application developer as part of the application itself and dispatched by the underlying OS. Clearly, there needs to be a response chain to allow higher priority processes to handle the messages and do whatever the system deems as necessary before chaining the event to the delegate object. There is also the issue of how to handle apps that wish to consume the same messages (e.g. Facebook updates)
An important feature here, which WebOS seems to have included (again, from a very outsider perspective) is the ability to bring the interruption to the user's attention in a meaningful way (and here I would defer to a mobile UI designer to suggest the best options), allowing the flow of messages, the flow of processing (via the apps themselves, not the delegates) and the user's current task flow to be managed in the best way possible by the user, given that we are stuck in a mobile with a single-window view most of the time. We could think of an "Application Messaging Console" for the user, or some other option. These options would be programmatically available to the delegate objects, per the Messaging UI Kit API shown in the diagram (sorry to borrow the term UI Kit from Mac OS X).
With this pattern, it is possible, for example, to receive a Facebook status update and bring this to the attention of the user without the need to bring the Facebook app to the foreground, or indeed load it into memory. It is up to the developer to decide how different messages into her application should be handled in terms of notifying the user and subsequently processing the message itself, or not. For example, Facebook updates could be put into a queue for the Facebook application and these then get processed by the application when it is next loaded into memory.
The delegate objects would also be presented with an API (via the Messaging UI Kit API) to determine current user attention. For example, if we know that the user is in a call, or composing an email message, then we could defer any Facebook status update alerts until after the current task has completed.
Any holistic mobile applications framework has to include messaging as an integral part of the architecture. Incredibly, this has not been the case. We have had to rely on SMS to provide a reliable out-of-band messaging transport, but one that is not adequately integrated into applications frameworks. Therefore, there still remains a big question mark (discussed in an earlier post) as to how best to implement the right-hand side of the diagram to allow reliable asynchronous messaging in the application space. It is not clear to me who is solving this problem.
Comments