For many, the biggest announcement at the Qualcomm BREW Developer’s Conference this year was the public unveiling of uiOne, a new set of tools leveraging XML and Qualcomm’s existing BREW UI Toolkit (BUIT) to give developers the means to separate the look and feel of an application from its business logic. uiOne is poised to make life different—and better—for carriers, handset manufacturers, and application developers alike. Let’s see why.
Introducing uiOne
The purpose of uiOne is simple: to reduce the time to market for handsets, carrier customization, and consumer personalization. To do this, the BREW uiOne provides a clear set of abstractions, adding two new layers to the application development stack for BREW (see Figure 1).
Traditional BREW applications, like the ones you write, use the BREW APIs directly, or perhaps leverage the BUIT for their user interface. (They may also use extensions you or or others provide, but that’s not shown in Figure 1 for brevity.) The uiOne environment adds the notion of trigs, applications written using the TrigML XML vocabulary and played using the Qualcomm-provided Trigplayer on the handset. Trigs leverage actors, the interface between the XML within a trig and existing or custom extensions to provide functionality best left for C and C++, such as the interfaces to a messaging protocol.
This architecture permits the development of truly data-driven user interfaces. A BREW Trig-based application (or triglet) consists of a resource bundle that includes not just an XML definition of the application’s interface, but all of the resources required by the application.
If the Trigplayer were just a browser, and triglets the BREW equivalent of an MHTML file, there wouldn’t be much cause for excitement. However, triglets can interact with actors, which encapsulate the behavior provided by BREW extensions, so it’s possible to perform programmatic behavior too complex for a triglet, or behavior not anticipated by the uiOne architects. The actor interface, just like the UI interface, is an event-driven one, so it’s easy to do: triglets throw events with named parameters, like this:
<throw event=”dial”
target=”/actor/network”>
<param name=”number”
value=”+1 888 555 4444″/>
</throw>
This code snippet (drawn from Qualcomm’s samples) instructs the network actor to perform its dial event with the named argument number, given the value “+1 888 555 4444”, presumably dialing the indicated phone number. In turn, actors themselves can throw events back to your triglet; you could catch an incoming voice call with a snippet like this:
<load when=”incomingCall”
res=”popups/incomingCall”
target=”popupLayer”/>
This snippet’s purpose is obvious: When the incomingCall event arrives, load the incomingCall form into the triglet’s popup layer.
These snippets point to another interesting facet of triglets—although they’re built on the Qualcomm BREW resource format (BAR files), the triglet interface to a bar file’s contents is that of a virtual file system. In fact, the triglet development environment is a complex one, with a full authoring tool that, while still under development, will let you do much of the interface prototyping on the desktop, transferring compiled triglets to be rendered on the handset through the uiOne Publisher. Moreover, Qualcomm is updating the Brew Delivery System (BDS), separating the content store and creating a separate service (the uiOne Depot) responsible for providing a server-side content and application store. Together, these mechanisms will let carriers and developers update just bits of a trig at a time, so it will be possible to create dynamic patches to an application’s user interface. For example, a news application could change its entire look and feel during the weeks leading up to a major election, without the need for changes to the application’s source code.
Why uiOne Will Change How You Work
At first blush, uiOne may appear to be interesting only to handset OEMs, especially in the near term. And, on the one hand, this is true: The timetable for uiOne releases is such that as a commercial developer, you won’t be able to crank out and release a uiOne-based application in the immediate future. However, moving forward, it will become a force with which to reckon.
The reason for this is simple: It simplifies application development for many kinds of applications. Today’s applications have huge investments in user interface development in C and C++; some companies made Herculean efforts to circumvent this, building entire XML- or HTML-based user interfaces to help ease porting from one handset to another. Most of us, however, must be content to tweak user interfaces to meet new screen sizes and handset capabilities on a port-by-port basis, or else compromise on the look and feel of our application (sometimes with disastrous results). BREW uiOne will change this; by abstracting the user interface the way it does, placement and appearance can be changed much more quickly, resulting in faster porting times.
All of this has staggering implications for application developers. Over the coming months, the tool chain behind the BREW uiOne initiative will make its way first to select developers and then to all of us. The toolchain promises several key advantages:
- The separation of software logic and user interface, placing the user interface in the data segment, will permit far faster iteration during the software development process as you refine your user interface.
- As carriers adopt uiOne, opportunities open up for you to offer theme packs for your applications, providing additional sources of revenue.
- The development cost for many simple productivity applications will drop significantly, as the level of effort for user interface development drops significantly.
The third point is key: Just as tools such as Konfabulator’s widgets and Apple’s Dashboard pave the way for Web-based development techniques to make inroads into traditional application development (offering unique, customizable, and elegant applets built with a minimum of programming savvy), so too will BREW uiOne usher in new opportunities for productivity enhancements to tomorrow’s mobile handsets.
Take the time to check out the conference presentations on BREW uiOne, and when it’s available, explore the possibilities of BREW uiOne. You won’t be disappointed.
Related Resources
- Qualcomm BREW: http://www.qualcomm.com/brew
- For an introduction to the Qualcomm BREW uiOne, see the developer conference materials available at http://brew.qualcomm.com/brew/en/press_room/events/brew_2005/pres_video_01.html.
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 ^55uiOne56^@lothlorien.com.
