How RIM Blackberry Devices Manage Multiple Applications

Chris King
(The following is an excerpt from "Advanced Blackberry Development," published by APress.)

Back when Java ME was first developed, mobile devices could barely handle running a single app at a time, let alone multiple apps. The early promoters championed the advantages of bringing the Java virtual machine sandbox to the mobile space: Rogue apps could not infect users' phones with viruses and buggy apps could not crash and prevent you from placing calls. The entire purpose of Java ME was to enable simple, compact applications that could run with minimal resources in an isolated environment.

As the capabilities of mobile phones grow ever closer to those of desktop computers, this architecture has grown increasingly antiquated. Java ME phones now struggle against the richer multitasking operating systems found in smartphones. One major shortcoming of the original Java ME design is the inability to launch one application from another application. Again, this was sensible back in the 1990s when multitasking was beyond the physical capabilities of the device. However, there are many situations where one would like to take advantage of existing app functionality. If a photo-viewing application already exists on the device, it would be far better to launch that app to show your photos rather than reimplementing the capability within a new app and significantly increasing the app binary size.

Allowing the invocation of external apps is not as simple as it would first seem, though. How would you know whether the user has the other app installed? What would you do if he or she later deleted the other app? How can you handle upgrades, where one version behaves slightly differently from the other? And how do you avoid a proliferation of incompatible APIs for every new app?

Enter JSR 211. Content Handler API (CHAPI) seeks to resolve all these tensions by establishing a framework for communication between apps. CHAPI's philosophy encompasses several desires:

  • Request/Response Framework: Requesting apps should be able to ask for resources or for tasks, and receive information when the request is complete.
  • Loose Coupling: Apps should not need to know exactly which app is servicing the request so long as it is capable of handling it.
  • Seamless Transition: The device should automatically pass control between requesting and servicing apps, bringing each to the foreground or background as needed. The user should never need to manually exit one app and start another to complete a request.
  • Enable Discovery: Apps should be able to learn which handlers are available to service desired requests and obtain basic information about them, such as their names.
  • Expandable: New apps should be installable to provide additional capabilities, and apps should be able to initiate such installation.
  • Support Delegation: An app servicing a request should be able to enlist the assistance of other apps to complete its task.

RIM has embraced this platform, using it to allow communication with built-in BlackBerry applications and between third-party apps. It is available on all devices with software version 4.3 or higher.

The Content-Handling Architecture

Think of content handling as a client-server application. The client wants to accomplish a task, such as purchasing extra credits for a game, or acquire a resource, such as searching for a file. The client expresses its desire with a class called Invocation. The Invocation combines several elements:

*A verb, such as 'Edit', 'Open' or 'Print'


*A target, such as "http://example.com/credits.do" or
"file:///SDCard/BlackBerry/Music/NationalAnthem.mp3"

*Optional extra parameters or data

The client uses the Registry class to find whether any content handlers are available to service the request and to actually issue the request. Once the Registry receives the Invocation, it checks to see what appropriate content handlers exist to handle it. The Registry then instructs the device AMS to deliver the Invocation. Because the client and the server are separate applications running in different processes, the application-management system (AMS) will first need to create a new Java process if the app is not already running, then serialize the Invocation and copy it into the server app's memory.

Server apps use the Registry to express their interest in handling certain types of content. Apps can register by content type, such as "audio/mpeg", by extension, such as ".mp3" or both. In some circumstances, one app can specify which particular app should service the request.

When a server receives a request, it will be started if it is not already running, and then it has the opportunity to dequeue the Invocation. If multiple Invocations are pending, it can handle them one at a time, or spawn multiple threads to process them simultaneously. The server app has its own copy of the Invocation to work with; typically, it will examine the details of the request, try to fulfill the request, store any return information that might be available, and then notify the device about the success or failure of the operation.

After processing is complete, the device AMS will copy the modified Invocation instance back across the address space boundary into the client application. The client can choose to receive a notification that the request was executed and can retrieve any information that was retrieved.



Add Comment      Leave a comment on this blog post

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.