At BREW 2005, the BREW uiOne environment was shown to developers with great public fanfare. At that time, aimed primarily at carriers and manufacturers, the dynamic UI customization environment was only released to a few specific partners over the summer of 2005. Announcements followed as companies including AllTel, O2, and Sprint announced they’d be using the solution to provide customizable handset UI’s; the first handsets shipped with uiOne support that winter. Now, a full year after the first announcements, developers are making new themes for handsets on the Sprint network, and the first BREW uiOne enabled handset is shipping in Europe. How can you get in on the action?
In this article, I tell you what you need to get started, give you a short tour of the BREW uiOne solution, and explain where the current market is going for BREW uiOne applications.
What You Need
To begin, you need the BREW uiOne SDK. You can get this from the Qualcomm Web site, currently from https://brewx.qualcomm.com/brew/sdk/download.jsp. To get the SDK, you need to be a BREW Authenticated Developer. This process is well-documented at Qualcomm’s Web site, and takes four steps:
- Apply for an Authentic Document ID for BREW.
- Complete the BREW ISV registration form by reviewing and accepting the BREW Developer Agreement.
- Register an account with NSTL, Qualcomm’s third-party testing authority.
- Review the Operator Guidelines.
This is exactly the same process you follow to develop and distribute traditional C-based BREW applications, so if you’re already developing BREW applications, you’re all set.
What uiOne Is
The uiOne environment is many things. To carriers, it’s a way to distribute highly customized user interface packages called trigs (more on them in a moment). As such, the uiOne environment includes a distribution server carriers can use to generate revenue from trigs. For handset manufacturers, it’s a collection of BREW applications and extensions including a player application that can be bundled on the handset and configured for a specific carrier—for example, the Sprint uiOne solution includes a customizable favorites application that presents its user interface using a uiOne trig, letting users customize the look and feel of the handset’s idle and favorites application down to the icons and positions on each menu item. For developers, it’s a way to create new themes for existing applications such as Sprint’s, or a way to create whole new applications as handsets begin to ship with support for uiOne.
At the heart of uiOne is the trig, a custom UI for a BREW device. Under the hood, a trig is a collection of resources bound together by TrigML, an XML-based markup language that describes the resources and how users may interact with them, and potentially actors that perform native interactions not directly possible within the trig’s environment. For example, a custom voicemail application to ease access to a carrier’s voicemail system might have a user interface written in TrigML, a host of bitmaps and a bitmap font or two for the look and feel, and an actor or two to interface with the ITAPI interface in BREW to make and manage the call to the voicemail server.
On the C or C++ side of the house, actors support trigs by providing functionality not directly exposed using TigML. An actor is a BREW extension following a specific interface that can handle events or monitor attributes of a trig. In response to events or attributes it performs actions (such as ITAPI manipulations, fetching new content via HTTP, or other activities) on behalf of the trig.
Trigs themselves are divided up into triglets that reside within the trig. The triglet is the atomic part of a trig that can be dynamically updated by the server, replacing or augmenting what’s on the virtual file system. This is the “secret sauce” of the BREW uiOne solution; new triglets can have the same functionality but look remarkably different than existing triglets running on the handset without needing new binary code. It’s as if not only the resources, but also all the layout code were in an application’s resource file—which, under the hood, is how it works, because the TrigML language describes the user interface layout of the trig.
A published trig can be either a full-blown executable or a single resource (BAR) file. The former incarnation is most common, in that it consists of a ZIP file containing the MOD, BAR, MIF, and some metadata in a trig metafile known as the TMF. Once this is created for an application, however, it’s enough to simply update the BAR file that contains the resources for the trig.
You create trigs using the TrigBuilder, a Windows-resident application that provides a graphic design studio for creating trigs. The TrigBuilder lets you manage trig parcels, the source files that describe a trig, including adding and removing resources and TrigML from a package. Parcels do their work using a virtual file system that represents the components of a trig as if they resided on their own file system. The TrigBuilder includes a simulator for viewing the results of your work on your workstation, and the necessary components to run trigs on a handset that lack the necessary code in ROM (as most do today).
Getting Started
Once you download the uiOne SDK, it’s best to begin by walking through the Quick Start Guide to uiOne and then the uiOne SDK Tutorial to gain a full understanding of what’s possible. However, if you’re eager to get started, you can always open one of the presupplied parcels and just begin editing, getting a feel for how things work in the simulator. There’s also a wealth of presentations on the topic from this year’s developer conference at http://brew.qualcomm.com/brew/en/press_room/events/brew_2006/brew_2006.html.
To build your first real trig, however, requires some planning. Qualcomm recommends making a paper prototype to plan the screens; this is even more important than it is for traditional C-based applications, because the development environment is so GUI-focused. You needn’t have the final artwork done; mock-ups using a simple drawing program or even pencil and paper are enough to let you determine the relationship between the various screens and subscreens (described as layers in TrigML).
Once you do this, you should identify what extensions may be required in addition to your trig. For example, you may want to create some bitmap fonts using the Qualcomm-provided BREW Bitmap Font Generator tool, or you may need an actor to access other BREW interfaces.
You can start actually writing your trig by opening a new parcel or creating an existing parcel. Typically, your parcel will be divided into multiple trigs; a base trig that contains the commonly accessed resources and scripts, and triglets that may be updated dynamically. You spend most of your time (unless you’re writing actors, too) at this stage, iterating over your TrigML and resources building your application. You should stop and examine your work frequently, using both the simulator and a device; the TrigBuilder makes it easy to download your application to the device, so on-handset testing is even easier than it is with C-based BREW applications. As a result, the process of developing and testing your application becomes highly iterative.
Once you’re ready to deploy your trig, it’s simply a matter of exporting it as MOD, BAR, MIF, and TMF files and putting it through its paces like you would any other binary application.
Moving Forward
What lies in store for uiOne and developers? It’s clearly gaining ground as a carrier-supported customization mechanism; Sprint opened their developer program to new Sprint Themes at the BREW 2006 developer conference in June. By partnering with Sprint, you already can create and sell themes re-skinning the handset’s idle and favorite screens on handsets that include the Sanyo MM-7500. With the launch of a BREW uiOne handset on O2, the same should soon be true in Europe as well on the O2 network.
Developing whole applications is currently possible with BREW uiOne, although distribution is slightly more problematic. To date, Qualcomm and carriers have focused on solving the “deep personalization problem”—enabling handset owners to skin more than the wallpaper and ring tones on their handset—rather than on launching BREW uiOne support on a swath of handsets. Thus, downloadable application developers may want to wait before building BREW uiOne-enabled versions of their applications, because it is not clear if or when BREW-enabled carriers will adopt the BREW uiOne infrastructure for third-party application distribution.
On the other hand, if you’re working in concert with a handset manufacturer, it’s a very good time to begin looking at BREW uiOne as a solution to your theming problems for either existing or new applications. While relatively straightforward, the Sprint Themes application shows the viability of embedding BREW uiOne applications on new handsets; the same work could well apply to other embedded applications on tomorrow’s handsets as well.
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 ^75uiOne76^@lothlorien.com.
