s a BREW developer, you're probably intimately familiar with the process of writing applications, but perhaps not as familiar with the process of writing extensions. In BREW, an application is a class that can only have one instance. This means that a BREW application is a singleton, an example of a class which ensures that only one instance of the class can be created (for an in-depth examination of the singleton design pattern, see Design Patterns
, by Gamma, et al.).
Occasionally, however, you may need to create a BREW extension, often to manage shared resources or a shared interface: a good place in which to use a singleton. For example, say you have a private extension between two applications that controls access to data in /brew/shared on the file system. In a case like this, you want to ensure that the extension accurately represents the state of the file system; if both applications are running (say one in background and one in foreground mode), a singleton can greatly simplify synchronization.
The typical patterns for implementing a singleton require either a global variable or a class member variable. Unfortunately, neither of these constructs is available in BREW when compiling for Over-the-Air (OTA) provisioning. This has driven many developers to experiment with the local thread storage API available in later versions of BREW, bizarre tricks like writing pointers to active data in memory to configuration files, or simply to despair.
Fortunately, there is a better way: leveraging the nature of BREW's IModule interface, which itself is a singleton enforced by BREW at creation time and using it to implement the singleton contract. To do this, you must first understand a little about how BREW instantiates components.