Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

BREW Up a Better Way to Synch Data Between Apps Using a Singleton : Page 2

The most elegant way to ensure the synchronization of data between two separate apps is to use a singleton. The problem is that BREW doesn't support global or class member variables. Learn how BREW's IModule interface lets you implement singletons—without relying on the usual methods.


advertisement
The Lifecycle of a BREW Component
Before just subclassing BREW's IModule interface in the hopes of conjuring up a singleton, it's important to understand exactly for what a BREW IModule is responsible. Unfortunately, the existing documentation in this area is fuzzy at best.

BREW modules—such as applications and extensions—are the fundamental unit of code loading. In BREW, a module can contain the implementation for multiple classes, such as an application or multiple extensions. Your module is accompanied by a module information file, which provides information regarding the classes your module contains. When BREW loads a module from disk, it represents the module with a unique instance of the IModule class. During execution, this IModule instance is a factory, creating instances of the classes it contains when requested by BREW or other applications. Once all instances of these classes in the module are released, the module itself is released, freeing the memory it used to contain its code and data.

Using the IModule Interface
Normally, you don't have to worry about the implementation of IModule. QUALCOMM BREW provides a helper file, AEEModGen.c, which contains reference source code for modules. You implement a global function, AEEClsCreateInstance, which the AEEModGen.c file invokes in a timely manner when loading your component. Internally, however, AEEModGen.c implements AEEMod_Load, which is the entry point for all modules (a quick peek at QUALCOMM make files confirms this, too—the make file instructs the linker to ensure that AEEMod_Load is the first function in the compiled module). AEEModGen.c also implements the four methods of IModule:

  • CreateInstance: BREW invokes this method when it needs an instance of a class provided by the module.
  • FreeResources: this method frees additional resources consumed by the module prior to its destruction.
  • AddRef: this method increments the module's reference count.
  • Release: this method decrements the module's reference count and cleans up after the module when its reference count reaches 0.
Implementing Singletons
A little-known fact makes the implementation of a singleton quick and easy: BREW only loads and creates a module once—regardless of how many times it is required. This makes sense, because loading a module is an expensive process—it requires updates to system tables about what classes are available and also brings in the executable from disk and allocates ancillary support structures. By implementing your class that implements the IModule contract, you can add support for singletons, class variables, or anything else you want to ensure only exists once per module. This is a little trickier than simply writing a normal BREW class, because instead of just writing a class and its methods, you must also write the module load function.





Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date