We've just had a great chat with the extremely helpful RIM Developer Relations guys, and some things came out of it which we were only slightly aware of. None are secret, just buried in spec documents and forums, so I thought it would be worth putting them up on the blog in case they are helpful to other developers:
Since Firmware 4.2.1, there has been a manager object which can not only tell you what the current API permissions are for your app, but allows you to display the device's application permissions dialogue with your favoured settings pre-populated, which the user can then choose to save if they are comfortable with them.
Used correctly, this is a great way for the app to discretely flag how the user can make their life easier, without being too intrusive. We're all about removing pain in a secure fashion, and love this! There are some pointers in this presentation, and from there you can dig into the relevant API.
A user can migrate their applications to a new device alongside their contacts, mails etc. On the face of things this is very useful, but it means your app's cod files must be as happy working on a scrollwheel Suretype device with a 240x260 screen (eg. 7100) as they are on trackball QWERTY devices with 480x320 screens (eg. a Bold).
This could have real implications for games, which often use large graphics scaled and optimised for a particular screen size. It also impacts some strategies for providing UI movement and widgets across different keyboard and scroll/pointer types on fully branded Canvas-based applications.
The application's RMS memory migrates with the app, and applications can query the device to find out its unique ID and specification, so if this is a huge problem you should always compare IDs at startup and issue an upgrade so that the user picks up a more appropriate cod.
If you want to provide proper support for the Storm's touch UI, you'll have to do it with a native UIApplication instead of a MIDlet. The MIDP Canvas touchscreen API is not expressive enough to handle the two levels of click used on the Storm.
A huge bugbear with Blackberries before was their inability to read any parameter from the jad - this made the provisioning of unique information at installation time all but impossible. The MIDlet.getAppParameter() method simply returns any value stored in the Manifest at compile time, but nothing added in the jad afterwards.
Since firmware 4.3.0, this now works - and RIM are very good at providing clear User Agents identifying the device and its firmware when browsing (unlike some others), so you can make this call at provisioning time.
There's also a great tutorial on Blackberry vs. MIDP code signing (PDF). I hope some of that information is of use to people - the guys from RIM were extremely helpful and we certainly were very happily surprised how much we got out of the meeting.
On an unrelated side-note, we've started Twittering - we're just restricting the company tweets to information relevant to mobile applications, security and transport so if any of that is you're bag feel free to follow us!