hy, oh why, should you use yet another file to house string, image, and binary resources? With Brew there are several good reasons. As every experienced developer knows, each handset has its own quirks, differences, and eccentricities. You also know that no project has the same specification for more than a few weeks. In small organizations, it is nearly impossible to expend engineering time to compensate for each individual handset and resource requirement change.
This article explores how the cannon of BREW's resource filesalong with the recently added XML resource file architecturecan help simplify your project's resource management, starting with the very basic and moving to the more complex.
The most basic resource file is the .bar file. This file allows anyone with a text editor to modify and control resources at runtime on the handset. This makes it very simple to call out the IDs for your resources and swap them out at a later time. Additionally, this ability allows for different language support, conforming to spec changes, and different screen resolutionsall without recompiling. These benefits do come with a small cost in overhead and some small drawbacks. String literals in code take up slightly less space inline than they would in the .bar file (though code with resources in-line makes comprehending source for the uninitiated straightforward and easier to read). Each call to the resource file must also make use of the files-system and that can be very slow, at times. These few drawbacks are drastically overshadowed by the benefits of the run-time resource file.
Enough talk; let's look at how to load resources from the .bar file in code:
#define APP_RESOURCE_FILE "myapp.bar"
#define MAX_STRING_SIZE 64
//Returns a pointer to a newly allocated string
AECHAR * MyApp_GetString(IShell *pShell, int nStringID)
AECHAR *wszResource = MALLOC( MAX_STRING_SIZE * sizeof(AECHAR));
MAX_STRING_SIZE * sizeof(AECHAR) )
As the above code shows, loading a string resource from the .bar
file is quite simple. Create a wide-string buffer to hold the resource, pass it into the shell function with the resource name, and ID and your resource now resides in memory. To display, simply load the text resource into an IStatic
| Author's Note: A common mistake in dealing with wide-strings is to specify in the number of AECHARs in your destination string. This will result in half the buffer being filled. Be sure to specify the number of bytes used by the buffer (in this case its length times two).
Brew will also pre-load an IImage object from the resource file for you:
pImage = ISHELL_LoadResImage(pIShell, "myapp.bar", IDI_MYIMAGE);
//Error handling here
This code is very simple and demonstrates how helpful these Brew resource files can be. Brew's ISHELL
object will do the leg work of creating an IImage
object given the resource filename and the ID
. The IDI
are prefixes that denote types for images and strings. It's a simple way to differentiate between your resource types at a glance.
For other ways to use the resource file, be sure to read through the documentation for the Brew SDK. The Menu and Text controls also interface directly with the resource file (information on how to use these UI objects is also found in the SDK documentation).