Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Build Better Mobile UIs with a New Brew Framework, Part II : Page 3

Build on what you learned in Part I of this series, and learn how to create multi-screen user interfaces, manage applications using forms, and work with the model-view-controller paradigm in BREW.




Application Security Testing: An Integral Part of DevOps

Listening to Model Changes
Widgets and other bits of code can listen and receive function invocations whenever a model changes. This is the means by which a widget knows when and what to draw, and by the same token, it's how models can communicate changes to your application.

The IOU application uses a single listener, to listen on the model for the list to determine when a list item is selected. It does this using a focus listener, which receives events whenever the list's model receives changes with regard to which item has focus. It's important to realize that the focus listener isn't listening to the model of the list, but the model of the view for the list. There's a subtle but important difference: the list model contains the items of the list; the list's view model is the model for the view, and keeps track of things such as who has focus. The focus listener has been set using the code at the end of Listing 1, indicating that when the list model changes, the system will invoke the listener function Menu_ListenerFocus (Listing 3).

Unlike event handlers, you’re not responsible for chaining listeners—the BREW UI Toolkit will do that for you. Thus, Menu_ListenerFocus need only handle the menu selection action (an EVT_MDL_FOCUS_SELECT event) and populate the text models for the input form that needs to be shown before popping the menu form and pushing the appropriate edit form to the top of the form stack.

Managing the Models
When initializing a screen, you must be sure to put the appropriate contents in each widget's models. For some widgets, like labels, this is easy. A quick IWIDGET_SetText call may be all that's necessary. For other widgets, you may need to harvest data from a data store, such as a BREW database, file, or another model. Listing 3 does this, using the ITextModel instances associated with each of the input lines for a specific form. The ITextModel is a subclass of IModel, and provides information about the contents, current selection, and cursor position in a text input line. This information is provided by the TextInfo structure, which you can obtain from any text model by calling its ITEXTMODEL_GetTextInfo method. You can use this method to obtain a model's text info, select all of the text currently in the model by setting a selection range from zero to the count of characters, and then replacing the current text with the new text. This replacement metaphor is the standard one when working with text models; using replacement you can insert, delete, or append text to the contents of a text model.

But where do the text models in Listing 3 come from? In Listing 4, you can see how during the construction of an input form, IWIDGET_GetModel provides references to each input line's text model. This call returns a model of the requested interface type for a specific widget—you need to be sure to pass the interface id, not the class id, of the interface you want(an interface id's name is preceded by the prefix AEEIID_, unlike a class id’s name, which is preceded by the prefix AEECLSID_). Confusing these is a common source of errors—calling IWIDGET_GetModel with a class id instead of an interface id yields no model at all, so you’ll want to watch out. Once you get the models for each of the text input widgets, stash them aside in the application structure for use in places like href="javascript:showSupportItem('listing3')">Listing 3.

Similarly, you also need to obtain data from text models when the user chooses to commit a change. That's even easier, and there's more than one way to do it. Perhaps the most obvious is to set a listener on the model, which lets you update your application in real time with the changes a user makes to an input widget (think the focus listener in href="javascript:showSupportItem('listing3')">Listing 3). In many cases this can be overkill—some applications should only store user changes when the user chooses to commit the data to the store, perhaps when pressing a SAVE button. This is also true for IOU. The right-hand soft key triggers a save action in the form's event handler, as you saw in Listing 2. The save action, in SaveIOUForm (Listing 5), simply harvests the contents of the input widgets and commits them to the menu model.

SaveIOUForm gets the text in each of the two models by obtaining the model's text info and copying it from the TextInfo's pwText parameter. It then builds the string that will appear in the menu with the entered person and debt. Once the menu string is constructed, it's either added to the end of the menu (if the form was brought up for a save command) or used to replace the old value in the menu.

Of course, using the menu model as the data store is only a stopgap while the application is running. On application launch, initialize the model with the contents of a file, and on application exit, commit the contents to the same file (Listing 6). This code represents the IOUs as an array of fixed-length fields in wide string format, making them almost a carbon copy of the actual menu model’s contents. It's crude, but it works. A more robust application probably deserves a database, and storage of the debt amounts as numbers so that cumulative debts can be managed as actual accounts, rather than as simple textual notes.

Wrapping Up
You've learned how widgets and forms replace the existing BREW IControl metaphor for user interface development. You've learned the basics of constructing and configuring widgets, attaching them to containers, and managing application flow through forms and event handlers. Now, it's your turn: contact Qualcomm to get a pre-release of the BREW UI Toolkit, and start building your next generation application!

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 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.
Comment and Contribute






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



We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date