Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Alternative BBM Dependency checker

by Retired on ‎01-20-2012 04:07 PM (3,671 Views)

The RIM supplied BBM dependency checker samples, provide two approaches to integrating with BBM. 


a) The proxy method which is appropriate when the application will not run without BBM – it directs the user to download BBM.
b) By contrast, the interface method provides a way for an application to isolate itself from the BBM, so that the application can still run even if BBM is not installed.


Why is this isolation needed?  Because if a cod (project) references any BBM methods, then BBM must on the device and at a suitable level before that cod can be loaded.  So if an application directly references BBM and there is no BBM (or no suitable level of BBM) on the device, the application will not run. 


Of the two approaches, the interface approach is probably the most useful, as most applications have functionality without BBM.  But this approach has two disadvantages:
• It requires a start up process to register the RuntimeStore Object
• The layered approach and the use of call-backs makes this quite complicated for me.


The attached project demonstrates a variation on the interface method, that creates the interface object at Application start-up, using class.forName().  Aside from this change, the sample provided is similar to the interface method, and is explained below.  After the explanation of the attached project, this document explains how to create a different structure which you may find easier to work with. 


Using class.forName(…)


Like the interface method, the application is split into 3 different projects, each of which will create a different cod. 


The 3 projects are:
1. The Application, which is dependent on the Interface code
2. The Interface code – i.e. the Library that defines the methods that will be used to call BBM, and the call backs that will come from BBM.
3. The Implementation – i.e. the actual BBM interfacing code, which is also dependent on the Interface code.


Summary of the projects


The Application in the sample is just a screen, that starts BBM and then displays information indicating the success or not of this.  The idea is that you can take this code and add it to your own Application.

The Application must be able to invoke BBM, so the interface to BBM is defined in a Library that the Application is dependent upon.  This Library contains two classes
• BBMBridge – which contains all the methods that the Application can use to access to BBM
• BBMDriveCallback – which define the methods that the Application needs to implement to get call backs from BBM. 

The idea is that you will take this Library and add the stub methods that you wish to use – either as methods that you invoke from your Application, or call backs that are invoked by BBM.

Finally we have the BBM Implementation project, which provides the real interface to BBM.  You will add the real methods to this class as you extend how you use BBM.  In fact you will probably create multiple other classes that this class uses in its processing.


How it works….


To explain the processing we will work through the code as it will be executed.


First, it is not possible to connect to BBM unless the Application has a active User Interface.  BBM needs this to get confirmation regarding the connection from the User. 


There are a number of ways that you can make sure the processing does run with a User Interface.  To make sure that this UI is available, the sample application starts the BBM integration in the
onUiEngineAttached(boolean attached)
method for the first Screen loaded – making sure that ‘attached’ is set to true. 


The actual BBM interface is started with this code:




Before we discuss the startBBM method, we need to understand the ‘this’ parameter.  The interface to BBM is, in this case, supplied with a call back.  This call back is needed so that BBM can ‘bump’ something when some work needs to be done.  In this sample, the bumping that can be done is defined in the BBMBridgeCallback interface, and the most important method (at least initially) defined in here is:


public void onInitialized(boolean success);


This method will actually be invoked as a result of the BBMBridge.startBBM(this) call, indicating if the BBM is connected or not.  It would be nice if the BBMBridge processing could just return a flag indicating this, but the BBM interface was not designed in this way unfortunately. 


So when the screen is first pushed, the processing will start BBM with “BBMBridge.startBBM(this)” and BBM will call back with “onInitialized(boolean success)“ to indicate if the connection was successful or not. 

This is all useful information, but does not explain how this approach actually invokes the real BBM, without having BBM directly linked to the Application. 


The key to this processing is the BBMBridge class. Our Application will find one of these.  If it finds one it will use it.  In the case when BBM is actually active, the one it finds will do something that uses BBM.  When BBM is not active, it will find a dummy Object.


To make sure it can find this Object, BBMBridge will look in RuntimeStore using a specific ID.  If an Object is found in there, then the Application can use it!  If one is not found, then the BBMBridge processing attempts to create a new one.  It does this using the following line:




Using this, the Application is trying to create a new instance of an Object in another cod file.  The Application knows about this cod file and knows that the class it is trying to define extends BBMBridge.  But it does not directly invoke that code, so that cod file and the associated classes are independent of the Application.  If the BBM Implementation cod is on the device and has been loaded, then this code will work correctly.  If BBM is not available or not suitable, this cod will not be loaded, for the class will not be found.  This provides an easy way to see if the application can use BBM!


First time through, if the real BBM Implementation interface class can not be loaded, the sample Application creates a dummy Object.  This is different to the Interface approach because the BBMBridge class actually implements all the methods, so that it can be used at a ‘stub’.  The stub methods will do nothing in most cases. 

In other respects, this implementation is very similar to the standard Interface approach.


Restructuring this to make things easier
“Easier” is always a personal thing, perhaps you will review this approach and decide it is not actually easier, or you don’t like the interface.  So ignore this approach if you don’t like it or think it is wrong.


As noted the structure we have is
1. The Application, which is dependent on the Interface code
2. The Interface code – i.e. the Library that defines the methods that will be used to call BBM, and the call backs that will come from BBM.
3. The Implementation – i.e. the actual BBM interfacing code, which is also dependent on the Interface code. 


Another implementation approach would have the following:

a) A start-up project, which just starts the Application.  This project is dependent on the Application project. 
b) The Application, which is a Library and dependent on the Interface code
c) The Interface code – i.e. the Library that defines the methods that will be used to call BBM, and the call backs that will come from BBM.
d) The Implementation – i.e. the actual BBM interfacing code, which is also dependent on the Interface code.  In addition, this is dependent on the Application Library.


In practise, one would probably combine (b) and (c), but for now let us assume they are separate. 


Why is this approach easier?  Because, with this structure, it is possible to use facilities from the Application, in the BBM Implementation project.  This could be a range of things such as
i) the Application’s ‘logging’ facility
ii) the Application’s ‘persisted storage’
iii) the Application’s resources, such as language files, assets, screens and the like. 

These can be used directly, rather than through call backs.  




Apologies, the attached project is created using the JDE.  If someone would like to create an Eclipse version of this, I would be very grateful. 


Also be aware that this approach will suffer the same problems as outlined in this Thread:



As I suggested in the above Thread, if you find certain levels of BBM do not work with your application, I suggest you check the BBM version in th startBBM() processing before you load the real BBMBridge and only load it when you know that it will work.  Code in the RIM supplied proxy method should show you how to do this level checking. 


Hope this is useful.


Users Online
Currently online: 20 members 2,149 guests
Please welcome our newest community members: