When I was asked to provide the next installment of the BREW Intro Series, I wrestled with various content ideas. I didn’t want to write another “Hello BREW” application, simply because that’s already been done to death.

Finally I decided it would be nifty if, over the course of several articles, I could walk my readers through the development of an application with some commercial potential, however modest.

Beyond exploring what it’s like to code with the BREW SDK, I thought it would be interesting to chronicle the process of taking a BREW app from concept to commercialization.

Thus once the code has been covered, and all the necessary documentation has been prepared, I’ll try to get it through TRUE BREW testing and then see if a carrier will make it available to consumers.

The Big Idea
The application is a simple currency conversion tool. The main screen of the prototype I developed is displayed, with each of its user-interface (UI) elements in focus, in Figure 1.

Figure 1. The Basic Design

The UI element at the top of the screen is a simple BREW list menu that the user will employ to select the first of two currencies involved in the transaction she is contemplating. The list menu is almost perfect here because it uses the limited screen real estate sparingly, yet provides the user with multiple options. I say “almost perfect” because some customization is necessary in order to assist the user with navigation. The modifications discussed below hopefully increase the likelihood that the application will pass True BREW Testing. Only time will tell!

As you can see from the first three frames of Figure 1, I’ve augmented the list menus, and the text control, by adding arrows to help the user find her way around. These visual cues are necessary since the left and right keys are used to move the focus from a list menu, while the up and down direction keys are used to move the focus from the text control or the soft key menu. This shift will undoubtedly lead to some initial confusion. The visual cues are intended to minimize the adverse impact on the user’s experience with the application.

As indicated by the graphical depiction of a Windows spinner control, the up and down direction keys are used to select a currency from the list. While the first currency menu has the focus, the user can press the right direction key to move to the Amount: text control, or press the left direction key to move to the soft key menu at the bottom of the screen. The latter is an example of “wrap-around” functionality, incorporated to speed up navigation for the user.

Assuming the right direction key is used to bring the text box into focus, the user can replace, or otherwise update, any existing entry. When the user moves the focus into the text control, our code will automatically position the insertion point at the end of its contents. While the text control has the focus, the phone’s “CLR” key can be used to backspace over individual digits (and the decimal point, if present), the ‘#’ key clears all of the contents at once, the phone’s numeric keypad is used to enter digits, and the ‘*’ key enters a decimal point. The left and right direction keys can be used to position the text insertion point within the control’s contents and the up and down direction keys can be used to move the focus to the upper and lower currency menus, respectively. The value keyed in will represent the amount of one currency involved in the transaction. When the text control has the focus, the little vertical arrows visible at the ends indicate the buttons to use in order to move to another control.

We’ll inform the user of these user-interface details in a splash screen, or in a help topic accessible from the soft key menu at the bottom of the screen. We certainly don’t have the real estate available to provide this information on the main screen.

Once the user has specified the first currency, and the sum in question, she can, as the arrows indicate, move on to the second currency menu by pressing the down direction key, or return to the first using the up direction key.

Assuming that the user moves on to select the second currency, the screen will appear as shown in the third frame of Figure 1. From this lower list menu, the user can move back up to the text control by pressing the left direction key, or down to the soft key menu at the bottom of the screen by pressing the right direction key.

Let’s assume that the user moves down to the soft key menu where, as shown in the prototype, there are two available choices: “Edit Rates” and “Exit”. As mentioned earlier, I’ll likely add a “Help” selection that the user can choose to obtain directions for using the currency converter (I need to think of a commercial name!). Additional requirements will undoubtedly surface as the application evolves.

The “Edit Rates” button will take the user to a second screen where conversion rates can be updated for each of the tracked currencies. It may be better to simply label this button “Update” and have it present a further menu where the user is given the choice of adding or removing currencies from the menus shown on the main screen or changing exchange rates. An exhaustive list of all the world’s currencies will be maintained in a file with the user merely selecting a few that are of interest. After all, if you’re an American traveling in Canada, you won’t likely need the ability to view an equivalent value expressed in British pounds or Australian dollars.

Usage Scenario
Imagine an American user is traveling in Canada and comes across some souvenir she would like to purchase. Since the item is priced in Canadian dollars, the user would select “CA Dollar” in the top-most list menu. The user would then move to the “Amount:” text control and enter the price of the item in Canadian dollars. By selecting “US Dollar” from the lower list menu, the static “Equivalent” display area would show the corresponding value in American currency. The conversion is done on the fly (whenever any of the user-interface elements change state) so there is no need for a “Calculate” button. The user could use the “Update” capability discussed above to ensure the store’s conversion rate is used in the calculation.

And the Journey Begins…
First of all, I need to point out that I try to be complete and not leave questions hanging when I write. That said, I also don’t believe in rehashing topics that are clearly spelled out elsewhere. For example I use Visual Studio 6.0. Many of you may rightly ask “How does it work with .NET?” Similarly, you might be unclear on how to use the 2.x Emulator with applications that must be compiled using the 1.1 header files. The reason that I won’t cover this ground in these articles is simple; the answers to these questions, and scores more, can be found here. Also, the searchable Developer Forums and FAQ / Knowledge Base (use the search box in the lower left part of the page) are excellent resources. Last, but not least, the documentation provided with the SDK includes detailed, usually complete, information about using the various API’s. So, if I miss something, chances are you’ll find what you’re looking for in one of these areas. As a postscript on this subject, don’t be afraid to look inside the BREW header files that come with the SDK. In some instances, you will find important information that’s not included in the SDK documentation.

In my last article, “Intro: Getting Started with BREW,” I briefly covered the SDK tools including the MIF Editor, the Resource Editor, the BREW Emulator, and the BREW Application Wizard. In addition to these primary SDK tools, we need to use Visual C++ to produce the .dll that will run on the BREW Emulator, and an ARM compiler to create the module (.mod file) that will run on the targeted device(s). We also need a class ID for the application. We’ll use the web-based class ID generator for this purpose. Note that the class ID generator is only accessible to authenticated developers who are able to log in to the Developer Extranet (i.e. you need to have obtained your Verisign authentic document ID). If you haven’t acquired access to the extranet, you can use the MIF Editor to manually create a class ID. So you’ll have a join the BREW Developer Alliance (this is a good excuse to climb aboard) or else just follow along on your screens.

The following table summarizes the contribution of each of these tools, the files they use and create, and the place each of these files occupies within the overall project.

What’s Next?
Next time, I’ll walk you through the creation of the application’s .mif and .bri. Then we’ll use the Application Wizard to lay the converter’s foundation. We’ll also cover the steps necessary to set up the development environment and integrate the BREW Emulator.

Originally published in the BREW Wireless Resource Center