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
event. Thus, if your application invokes the following:
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:
AEEAppStart *pArgs = (AEEAppStart *)dwParam;
if ( pArgs && pArgs->pszArgs &&
0==STRCMP(pArgs->pszArgs, "listview" )
ShowListView( pMe );
ShowNormalView( pMe );
bHandled = TRUE;
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 probleminterapplication communication is usually used by closely coupled parties such as two development teams at one firm or two firms working togetherit imposes unnecessary coupling between the two applications.
To address these concernsthe format of the arguments and the coupling of between applicationsyou should use ISHELL_BrowseURL or ISHELL_PostURL instead.