CHAPI pitfalls, part I

Some week ago I went mad implementing a CHAPI based solution.
CHAPI is the Content Handling API (JSR 211), a very powerful API for interprocess communication. It allows communication between Midlets and native apps. It allows the use but also offering of services on a mobile device.
Altough CHAPI is a quite easy API, the devil lies in the details. I spent the same time searching for problems then implementing it.
One problem is: The RIM samples for CHAPI are very simple: CHAPI caller and content handler are in the same class and are equal to the application instance itself.
But when starting to build more complex solutions, you will suddenly run into strange problems.

My first tipp: enable "device security" in the simulator!
For testing CHAPI use the device security option in the simulator. With this the device is much more strict in checking security issues: the application must be signed for using protected APIs as on the real device, firewall prompts are appearing and so on.
When using CHAPI there are checks for given classnames that does not occur in normal simulator but would appear on the real device.
The error will be an exception with "Classname does not exist in the current application package". Switch on device security for seeing it as early as possible.
The cause is documented in a KB article:
http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/800429/Support_-_Classname_does_not_exist_in_the_current_application_package.html?nodeid=1518602&vernum=0

When calling Registry.getRegistry() you have to give in the classname (incl. package) of the current application. This sounds simple but is easily breaks if you have for example a library with the code that is used from different applications. Example: a menu item and a CDLC application that resists in different COD files.
Therefore the 2nd tipp: you should use:
Application.getApplication().getClass().getName()
instead of hard coded application names.


more in the next part :-)