Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Interapplication Communication with Qualcomm Brew : Page 3

Learn the ins and outs of interapplication communication on Brew.


advertisement
Starting an Application with Arguments
Most of the time, starting an applet is as easy as calling ISHELL_StartApplet with the class ID of the application to start. But there's also ISHELL_StartAppletArgs, which takes an additional character string. When Brew handles this API, it makes a copy of the character string you provide, and sends it to the application being started as the pszArgs element of the AEEAppStart structure pointed to by the dwParam argument of the EVT_APP_START or EVT_APP_RESUME event. Thus, if your application invokes the following:

ISHELL_StartAppletArgs( pMe->a.,m_pIShell, AEECLSID_MYAPP, "listview" );

and my application's class ID is AEECLSID_MYAPP is found on the device, it will be created and sent an EVT_APP_START (or, if it's already running, it will receive EVT_APP_RESUME), and I can get the arguments you pass me with code such as the following in my event handler:

... case EVT_APP_START: case EVT_APP_RESUME: { AEEAppStart *pArgs = (AEEAppStart *)dwParam; if ( pArgs && pArgs->pszArgs && 0==STRCMP(pArgs->pszArgs, "listview" ) ShowListView( pMe ); else ShowNormalView( pMe ); bHandled = TRUE; } break; ... return bHandled;

The beauty of ISHELL_StartAppletArgs is that anything can be passed, so long as it's a reasonable-length string. It's an excellent means of chaining one application to another, so that one application can offer a particular feature such as media download, while another application offers a related feature, such as content search. It does have its drawbacks, however.



First, the data you pass must be a null-terminated string of reasonable length, because the Brew runtime is going to use some equivalent of STRDUP() to make a copy of the arguments you provide before passing it to the receiving application. If you're looking to pass a large blob of binary data, a FIFO is a better choice, as shown in a subsequent section of this article.

Second, there's no format imposed on the character string you pass. This is both good and bad. It gives you the freedom to use whatever you want, but at the same time, it's up to you to create a parser to interpret the string you're receiving. There's no equivalent to the UNIX getopt for Brew; over the years I've seen some pretty esoteric means of getting arguments from one application to another as a result.

Third, you have to know the class ID of the receiving application. It's not enough to know what to say, but you have to know to whom your message is being sent. While this usually isn't a problem—interapplication communication is usually used by closely coupled parties such as two development teams at one firm or two firms working together—it imposes unnecessary coupling between the two applications.

To address these concerns—the format of the arguments and the coupling of between applications—you should use ISHELL_BrowseURL or ISHELL_PostURL instead.



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap