October 21, 2016
Hot Topics:

BREW's Short Messaging Service Interfaces: Which to Use and Why

  • October 12, 2005
  • By Ray Rischpater
  • Send Email »
  • More Articles »

As with ITAPI, the process of sending an SMS message is an asynchronous one; when sending you must pass an initialized AEECallback along with a 32-bit integer in which ISMS will store the result value from the attempt to send your message. Of course, both the callback and this integer must be on the heap, not the stack, because they must remain in scope after your routine exits; it's often easiest just to allocate these as part of your application structure.

The callback is more complex, too, because it must manage both network errors and potential BREW errors that arise. It is also responsible for handling whatever retry rules are mandated by the carrier on which the application will run: Different carriers have different requirements regarding how often a handset should attempt to retry sending an SMS.

As you might imagine, receiving an SMS message is similarly complex. Without diving into the details in terms of code, the general flow is that your application receives a notification from ISMSNotifier, and then you use information in that notification to invoke ISMS_ReceiveMsg, which creates an ISMSMsg object, which you then parse by walking its list of options to determine the message sender, payload encoding, payload, and so forth. Perhaps most important to know about receiving SMS messages is that there should only be one application on the handset using ISMS to receive messages.

Which to Use and Why

By now, the choice of which to use and why should be pretty obvious: If you're writing a downloadable application, you definitely want to stick with using the relatively simple ITAPI-based interfaces to SMS sending and receiving. They're somewhat limited, to be sure (for example, there's no support for binary payloads), which may force you to be somewhat creative in how you craft a message payload (perhaps using base-64 encoding of binary data in the case where you need to send binary data). The support for SMS receipt is actually quite good, and there's a lot you can do with the ITAPI interface alone in the latest versions of BREW.

Handset manufacturers, on the other hand, are blessed with the flexibility required to write an entire messaging application in BREW using the new ISMS-based message classes. Closely reflecting the underlying implementation of an SMS message, the ISMSMsg class lets you string together the contents of an SMS message, or parse apart a received SMS message. However, these aren't things you can do as a downloadable application developer; not only would they potentially interfere with the built-in messaging application, but require privileges not available to downloadable applications as well.

Related Resources

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

Presentation on Telephony & SMS Interfaces: http://brew.qualcomm.com/brew/en/press_room/events/brew_2005/pres_video_02.html, TT501.

Mobile Messaging Technologies and Services: SMS, EMS, and MMS. Gwenaël Le Bodic, published by John Wiley and Sons.

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

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel