November 26, 2014
Hot Topics:

Three Tricks for Faster Handset Ports with Qualcomm BREW

  • June 19, 2006
  • By Ray Rischpater
  • Send Email »
  • More Articles »

Rely on the Network

Most BREW applications use the network at some point. If your application needs to access the network anyway, why not have it fetch its configuration file over the network when it first runs? It can save the resulting data on the file system as a file or entries for the application preferences to avoid making the transaction in the future, or simply make the request each time (letting you update application configuration options after an application has shipped).

How you do this is somewhat application- and carrier-dependent, of course. Some carriers may place restrictions preventing your application from making a network transaction during the splash screen, because it may slow a user's access to the application. If you can, it's best to piggyback a request for configuration atop other network activity to keep your application as interactive as possible. Another option is to deliver whatever configuration information might be needed with the results of a specific transaction. Of course, sometimes this is implicit: if your server is serving images to applications and it knows what platform the application is running on, all it needs to do is deliver images of that type (say, BCI instead of PNG).

Unlike the previous example, where I suggest that using the platform ID is a bad choice for identifying the handset for the purposes of selecting code paths, using the platform ID is the ideal choice here, because you can pass the platform ID as an HTTP header and the server can use the platform ID as an index into a database of configuration information. Simply get the platform ID and print it into a template such as X-BREW-Platform-ID: %d, and then set a custom header using IWeb like this:
WebOpt aWebOpts[2];
AEEDeviceInfo di = {0};

di.wStructSize = sizeof( AEEDeviceInfo );
ISHELL_GetDeviceInfo( pMe->a.m_pIShell, &di );
SPRINTF( pMe->szPlatformHeader, 
         "X-BREW-PlatformID: %d", di.dwPlatformID );

aWebOpts[0].nId = WEBOPT_HEADER;
aWebOpts[0].pVal = (void *)pMe->szPlatformHeader;
aWebOpts[1].nId = WEBOPT_END;
if (IWEB_AddOpt(pMe->piWeb, aWebOpts) != SUCCESS)
{
  DBGPRINTF("SetHeaders webopt failed");
}

Your server can then look up the device's capabilities in its database and present results appropriate for the destination device. (This is, of course, analogous to how many Web applications use the HTTP User-Agent string to determine your browser type and tune the HTML content for your specific browser.)

Conclusion

In porting to new handsets, the goal is to do so with as few changes to your application as possible. By coding your application so that one binary can run on the broadest number of handsets, you reduce the both the likelihood of error (which can slow the porting process tremendously) and eliminate the costly edit-build-test cycle, reducing it to a reconfigure-test cycle. Try these tricks in your next application for Qualcomm BREW; you won't be disappointed.

Related Resources

QUALCOMM BREW: http://www.qualcomm.com/brew/

About the Author

Ray Rischpater is the chief architect at Rocket Mobile, Inc., specializing in the design and development of messaging and information access applications for today's wireless devices. Ray Rischpater is the author of several books on software Development including eBay Application Development and Software Development for the QUALCOMM BREW Platform, both available from Apress, and is an active Amateur Radio operator. Contact Ray at kf6gpe@lothlorien.com.



Page 2 of 2



Comment and Contribute

 


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

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel