Research in Motion BlackBerry phones support the Java ME standard, so for a Java ME developer is easy to get started on BlackBerry. But a few things do not work as expected...
Menu
The BlackBerry has a very consistent user interface, with a menu key and a back key. These keys can not be catched by your Java ME canvas, pressing them will not call the keyPressed() method as you might have expected. Instead the menu key will always open the menu. If you have not added Java ME commands to the Canvas, the BlackBerry will create a menu itself, with 'Close' as the only alternative. The back key will trigger the command with the command type EXIT if there is one and do nothing is there is no such command.
This basically means that you should always use Java ME Commands in yor BlackBerry application. There is no other way within the Java ME API to get the BB keys to work as expected.
Other keys
There are no Nokia-style softkeys on a BlackBerry keyboard. But there is a trackball (trackwheel on older models) and a qwerty keyboard.
The trackwheel sends Canvas UP, DOWN, RIGHT and LEFT codes and trackball press can also be handled and expected. Your application should probably use these keys a lot. Key repeat is however not supported, so if the user scrolls the trackball you will get a series of keyPressed events and no keyRepeated.
The qwerty keys will call keyPressed with codes as expected, you can use getKeyName. Just remember that some models have a smaller keyboard, with two characters per key. You will always get the first character.
The return, backspace and space keys will also deliver key events as expected. The shift and alt keys will however not. Instead they affect the keycode delivered to the application. That is ok for the qwerty keys, but also it means that you can not tell if the user is holding down shift and scrolling or pressing the trackball.
Fullscreen mode
You Java ME Canvas will always cover the full screen. The call to setFullScreenMode has no effect. This also means that the sizeChanged method will never be called. So you should make sure that your application does not depend on it beging called.
The conclusion is that the BlackBerry Java ME implementation is a good one, and can be very well be used as a base for your implementation on BlackBerry. But if your midlet is based on the Canvas class and developed for Nokia-style phones you will probably need to make some changes, mainly with menues, softkeys etc. You can them detect at runtime if the midlet is on a BlackBerry or not and adjust to that.
Monday, March 16, 2009
Thursday, March 12, 2009
Java ME on BlackBerry
One of the platforms you can support with Java ME is BlackBerry. BlackBerry devices are a bit different from your ordinary cellphone. They are very good at email and includes a handful of applications.
Most of the applications for BlackBerry use the native Java API, but the device also supports Java ME midlet applications. But there are a few points to note...
Create COD files
BlackBerry supports standard jar/jad files to some extent, and installing your application entering a jad URL in the phones browser might work very well. But my experience is that sometimes it doesn't. Converting the jad/jar files to BlackBerry cod file format on your PC might be a better idea.
For this you need BalckBerry Java development tools. I use BlackBerry JDE 4.6.0, but there are new versions. You find them here.
From the command line you run something like:
This will take your yyy jar and jad files and create XXX.cod. It will also modify your jad file and add a lot of BlackBerry-specific lines to it. This makes the JAD file much larger, so will probably not want to use it for non-BlackBerry devices, even if the original data is still there (some devices have restrictions on jad file size).
If your midlet is large, it will be split into several cod files. They will all be in the yyy.cod, which might by a zip archive. So you need to check if it is (you can also check the modified jad file to see if there are several cod files in it). If it is you should unpack it and put the individual cod files on your web server together with the modified jad file. Make sure that the cod mimetype is configured on your web server, and your cod file is ready to install.
Most of the applications for BlackBerry use the native Java API, but the device also supports Java ME midlet applications. But there are a few points to note...
Create COD files
BlackBerry supports standard jar/jad files to some extent, and installing your application entering a jad URL in the phones browser might work very well. But my experience is that sometimes it doesn't. Converting the jad/jar files to BlackBerry cod file format on your PC might be a better idea.
For this you need BalckBerry Java development tools. I use BlackBerry JDE 4.6.0, but there are new versions. You find them here.
From the command line you run something like:
"C:\Program Files\Research In Motion\BlackBerry JDE Component Package 4.6.0\bin\rapc" import="C:\Program Files\Research In Motion\BlackBerry JDE Component Package 4.6.0\lib\net_rim_api.jar" codename=XXX -midlet jad=yyy.jad yyy.jar
This will take your yyy jar and jad files and create XXX.cod. It will also modify your jad file and add a lot of BlackBerry-specific lines to it. This makes the JAD file much larger, so will probably not want to use it for non-BlackBerry devices, even if the original data is still there (some devices have restrictions on jad file size).
If your midlet is large, it will be split into several cod files. They will all be in the yyy.cod, which might by a zip archive. So you need to check if it is (you can also check the modified jad file to see if there are several cod files in it). If it is you should unpack it and put the individual cod files on your web server together with the modified jad file. Make sure that the cod mimetype is configured on your web server, and your cod file is ready to install.
Monday, March 09, 2009
Portable Java ME development
The last six months or so I have been busy with developing a new application in Java ME environment. I have done some work in this envirnment before, but even though the platform has not changed much, my impression is that the quality of the implementations have improved a lot.
The goal was to support a wide selection of mobile phones:
- Nokia, both System 40 phones and Symbian System 60
- Research in Motion BlackBerry, at least the latest models like Bold and storm
- Sony Ericsson devices, where we started with Symbian UIQ models and now target mostly Xperia X1, based on windows mobile
- Samsung
- LG
- Motorola
etc...
Main focus is on more powerful, smartphone segment, but the application works well also on smaller phones.
Java ME was not the only possible choice. There is always the possibility to use native tools, for Symbian and BlackBerry at least. Our choice was to start developing on Java ME and see if it works and later add Symbian and/or BlackBerry specific code if needed. So far we have not needed it. And what surprises me is that it now works very well and very portable. When we try a new device it almost always works right away. We might need to add some code to make better use of the keyboard or make it look better, but generally it works well.
It is actually more of a problem to make it work in emulator, which surprises me. A special problem is with hasPointerEvents() method, which is supposed to tell us if the device has a touch screen or not. Since the application changes its user interface slightly depending on if there is a touch screen available or not this is a very important method for us. And on the phones it always works, but in the emulator it does not.
Another problem with the emulators is to find a good-looking emulator for demonstration purposes. There are a lot of good devices out ther, like Sony Ericsson Xperia X1 and Nokia S60 phones, but I have not managed to find good emulators for them. For the X1 I have so far not found a Java ME emulator at al, and for S60 phones there is one, but it does not look good enough for demonstration puposes. Guess this is because the development of new devices is so fast that manufacturers don't have the time to fix emulators.
The goal was to support a wide selection of mobile phones:
- Nokia, both System 40 phones and Symbian System 60
- Research in Motion BlackBerry, at least the latest models like Bold and storm
- Sony Ericsson devices, where we started with Symbian UIQ models and now target mostly Xperia X1, based on windows mobile
- Samsung
- LG
- Motorola
etc...
Main focus is on more powerful, smartphone segment, but the application works well also on smaller phones.
Java ME was not the only possible choice. There is always the possibility to use native tools, for Symbian and BlackBerry at least. Our choice was to start developing on Java ME and see if it works and later add Symbian and/or BlackBerry specific code if needed. So far we have not needed it. And what surprises me is that it now works very well and very portable. When we try a new device it almost always works right away. We might need to add some code to make better use of the keyboard or make it look better, but generally it works well.
It is actually more of a problem to make it work in emulator, which surprises me. A special problem is with hasPointerEvents() method, which is supposed to tell us if the device has a touch screen or not. Since the application changes its user interface slightly depending on if there is a touch screen available or not this is a very important method for us. And on the phones it always works, but in the emulator it does not.
Another problem with the emulators is to find a good-looking emulator for demonstration purposes. There are a lot of good devices out ther, like Sony Ericsson Xperia X1 and Nokia S60 phones, but I have not managed to find good emulators for them. For the X1 I have so far not found a Java ME emulator at al, and for S60 phones there is one, but it does not look good enough for demonstration puposes. Guess this is because the development of new devices is so fast that manufacturers don't have the time to fix emulators.
Subscribe to:
Posts (Atom)