Recall that you must use an SDK with a version number that is less than or equal to the version number of the Application Execution Environment (AEE) loaded on the handsets you are targeting. Table 1 lists the handsets we are targeting and their corresponding AEE versions. Note that the size of your target market can be maximized, and TRUE BREW Testing costs can be minimized, by targeting as many phones as possible in a single application submission to National Software Testing Laboratories (NSTL)–because the first 3 submissions are free, after which you are charged $1,000 per submission. In order to target both 1.1 and 2.0 handsets with the same code, we need to use version 1.1 of the BREW SDK for this project. In order for the tools to integrate correctly, please ensure that you have Visual Studio (especially Visual C++) installed before you install the BREW SDK.
 Figure 1. Starting the BREW Application Wizard |
I am using Visual Studio version 6.0. Some of the steps outlined here may be different for Visual Studio .NET. (See “How to Create BREW Apps Using Visual Studio .NET.”)
 Figure 2. Selecting header files to include. |
The BREW Application Wizard provides the easiest way to get a new BREW project under way. After you’ve installed the SDK, open Visual C++ and select File > New to bring up the new projects dialog, shown in Figure 1. Subsequently, click on “BREW Application Wizard”. As shown in Figure 1, I named the project “converter.” The project’s subdirectory, “converter,” must be placed in the applet directory, which is in this case the default, namely “BREWDirectoryExamples” (i.e. the project’s source file will be created in “BREWDirectoryExamplesconverter”). Clicking OK kicks off the BREW Application Wizard.
Next, the “New Project Information” dialog pops up (see Figure 4) to summarize the AppWizard’s next step. It will generate a source file, converter.c, for our application. We are reminded that the app. needs a .BID (BREW ID) file that must be included in the source file using the preprocessor #include directive. At this point, you need to click the OK button so that the wizard can go ahead and create converter.c.
 Figure 4. Finishing the AppWizard. |
Next time, we’ll discuss the code the AppWizard generated. At this point, creating the .BID file and the .mif makes sense, as the application will not run without them.
For a commercial application, you need to visit the BREW extranet website (see Figure 5) since it is the only source for ID’s that are guaranteed unique. The AEE uses this ID to distinguish between different applications on a device, and in the BREW Emulator.
Problem: You can only access this site if you have been Authenticated as a BREW Developer.
Solution: If you are not yet ready to spend $400 on a VeriSign Class 3 Certificate, you can create a .bid locally, using the MIF Editor. I’ll show you how to do this.
 Figure 5. Getting a unique BREW ID from the extranet. |
To illustrate an important concept, let’s use the MIF Editor that came with version 2.x of the SDK to create converter’s .mif file. Note that version 2.x .mif’s include certain features that their version 1.0 kindred do not. Since we want the .mif to work on both 1.1 and 2.x devices, it is important that we use the lowest common denominator and save the .mif as version 1.0 (see Figure 12).
Next, you will be prompted to save the .bid file. It should be saved in “BREWDirectoryExamplesconverter”. We’ll #include it in the converter.c source file in the next installment.
Now that we have a .bid file, we are automatically returned to the MIF Editor’s “Applets” tab, where the ClassID is displayed in the drop-down list box. We can now fill in the remaining information, as shown in Figure 9. The “Name:” box holds the name that the Emulator’s application manager will display when the converter is selected. Unimaginatively, I filled it in with “Converter”. I then specified “Tools” as the “Applet Type” and provided the path to the application’s 26 x 26 pixel icon. This icon will be used to launch the application, from the Application Manager screen, on most devices.
You can use the image editor provided with Visual Studio, MS Paint, Paintshop Pro, or whatever tool you prefer, to create the bitmaps that need to be included in the .mif. Note that the background for each of the images included in the .mif must be set to the transparent color, magenta (RGB 255, 0, 255), or the application will fail test case 3.9.5 during True BREW Testing. (See the document “Application Developer’s TRUE BREW Test Guide: Requirements and Test Cases.”)
 Figure 9. Back to complete the Applets tab. |
Note that you must provide a module version number for your application (a module). Recall, however, that we are using version 2.0 of the MIF Editor to create a .mif that must be compatible with version 1.1 of the AEE. A version 1.0 .mif cannot include a version number, so I’ve left that field blank. We’ll still need to provide a version number somewhere in the converter application. For more detailed information about using the MIF Editor, please see the MIF Editor Guide that is included with the free SDK.
Now that we’ve completed a rudimentary .mif for our application, we need to save it. When you save the file, please ensure that “BREW Module Information Files v 1.00…” is selected in the “Save as type” drop-down list box. If you don’t do this, the application will fail to display on 1.1 devices because the AEE won’t be able to recognize the .mif. If you use version 1.x of the MIF Editor to create the .mif, you don’t need to worry about selecting a file format, since 1.00 is the only one available.
Next Time
I had hoped to cover the skeleton source produced by the AppWizard, the BREW Resource Editor, and the final steps required to finish setting up the development environment. In the next installment, we’ll see how far we can get without letting any individual tutorial go beyond “bite size”.
Originally published in the BREW Wireless Resource Center
