ast June, Qualcomm took the wraps off one of the most significant changes to Qualcomm Brew in over two years: the Brew UI Toolkit, an entirely new paradigm for Brew user interface development. Applications written with the Brew UI Toolkit have access to user interface elements traditionally available to Brew applications, along with a slew of new controls, along with layout management, application state management through forms, and nested user interface control hierarchies.

Unfortunately, a change this wide-sweeping is not without cost: to take advantage of the Brew UI Toolkit, you must forego using the existing Brew controls based on the IControl interface. Consequently, moving to the Brew UI Toolkit is not a trivial effort, because you need to learn the new interfaces and the programming paradigm embraced by the Brew UI Toolkit team before you begin. This investment, however, more than pays off; your application has access to features difficult or impossible to implement using the previous control-based interfaces, and your application will be better structured as well. This isn't to say that you have to migrate your Brew 3.x application to support widgets; it's only an option. You're still free to use the existing control interface instead of widgets, although choosing to use the existing control interface limits your options, especially if you want to use one of the new widgets that doesn't have a corresponding IControl implementation.

The Brew UI and the Model-view-controller Pattern
Key to understanding the Brew UI Toolkit is understanding the model-view-controller (MVC) design pattern, because it's at the heart of the Brew UI Toolkit. Around for almost thirty years, MVC is at the heart of many of today's user interface frameworks, including Java Swing; you may have well used it but not recognized it. You can get a good summary of the MVC pattern here.

The MVC pattern breaks graphical UI applications up into three discrete parts: the model, view, and controller. The model is responsible for managing the application-domain data, responding to requests for information about the state of the data (typically from the view), and changes state (typically in response to requests from the controller). The view is responsible for managing the graphic output of the application. The controller is responsible for interpreting key events, menu selections, and other inputs, and passing the requests those commands represent to the view (to change its view of the model) or the model (to change its data).

In the traditional implementation, the controller accepts events from the system's event pump, uses polymorphism or traditional conditional logic to determine the appropriate action to take place within the view or model. In turn, the view listens for change notifications from the model and controller, querying the model for new data as needed when it receives a change notification. The model itself tracks the state of the application data. A common optimization for this pattern is to collapse the responsibilities of the view and the controller into a single programmatic entity; the Brew UI Toolkit uses this, letting you specify an event handler for any view. In essence, the Brew UI Toolkit provides default controllers for each view, and you're able to override this behavior with your own controller via a new event handler.

The Brew UI Toolkit provides base classes that represent the model (IModel) along with several subclasses for specific kinds of models, including a model for text (ITextModel), lists and menus (IListModel and IMenuModel respectively) as well as a general-purpose IValueModel with which you can encapsulate arbitrarily complex structures. The toolkit also provides a horde of user interface primitives from which you can build your user interface, including widgets for text input, radio and checkbox selection, buttons, text and bitmap display, and menu items and menus. All of these inherit the IWidget interface, which is conceptually similar to (but programmatically wholly unlike) the old IControl interface. Widgets can be nested, and some widgets perform layout and focus control for the widgets they contain, giving a decidedly desktop-programming flavor to the process of building your user interface. In turn, your widgets occupy a form, which is the top-level of a user interface from the perspective of your application.