The New .brx and .mfx Architecture
With the advent of Brew 3 (3.1.2 and 3.1.4), Qualcomm released a powerful new method with which to interact and store resources in XML. Previously, the resource file could only be accessed through Qualcomm's resource editor application. With this new architecture, anyone can read, manage, edit, and build the .bar
files. The following code looks at what a basic resource file looks like in XML:
<?xml version="1.0" encoding="utf-8"?>
<BREWRes Name="testing" VERSION="1">
<String Id="1001" Name="IDS_STRING_EXAMPLE">
<Object Id="5001" Name="IDI_SPLASH_IMAGE">
In this example, you can see a string
block and an object
block. The string
block contains one text resource "Hello World!"
. The object block contains an image resource for a splash screen. When compiled, the binary data for all referenced images is copied into the output file.
This example illustrates the basic layout of the XML, which is compiled into binary for deployment. Because these files are in plain text, you can use Perl, Python, and batch scripts to manipulate and update their contentsautomatically rev version numbers, manage language porting, and allow for various other powerful automation tools.
Another key feature of this latest XML architecture shift is the introduction of the .mfx file. .mfx files are to .mif files as the .brx files are to .bar files. For example, NSTL requires a unique version to appear in each True Brew testing submissionin addition to the requirement that the version match between the .mif and help dialogue (which should reside in the .bar file). The following code shows where that version number comes from in the .mfx:
<String Id="8" Name="IDS_STRING_8">
As you can see, this is a small piece taken from the .mfx
file. It compiles out to the version number in the .mif
for your application. Notice that the format of the code is identical to the string resources in the .brx
file listed earlier. This is because both of these files are human-readable, so it becomes trivial to write a Perl script that will rev both the .mfx
and the .brx
files for a new version. Include this as part of your drop scripts and you have one less reason to get a failure back from NSTL.