J2ME: Moto Key Codes

There are times when I agree that device manufacturers have to make changes in the software platform between different classes of devices... BUT ..keycodes ...commmmonnnn!!!!!

So damm frustrating ..

Seems like moto has decided to make a switch in the key code values of their handsets. The new series of handsets including the crappy yet popular RAZR and ROKR have different keycodes for the navigation keys than the earlier "Cool" phones like V600.

Here is the low down:

UP
V600 : 1
RAZR: -1

DOWN
V600 : 6
RAZR: -6

LEFT
V600 : 2
RAZR: -2

RIGHT
V600 : 5
RAZR: -5

SELECT
V600: 20
RAZR: -20

I know its just the negatives but I still have to make changes to my application. Common Moto take a cue from Nokia at being more developer friendly.

TastePhone : An awesome resource

OK.. so now i have my J2ME application ready and working on the couple of test devices. Whats Next ?

The deployment stage of any J2ME Midlet can be a nightmarish experience specially if your MIDlet has functionality that requires it to use specific API's. So how would a developer go about ascertaining the list of devices that most likely will support his/her application. Well, the easiest thing to do is to buy all the devices out there and test the MIDlet suite on all of them. Unfortunately, this is not a very practical solution.

The site maintained by Sun is decent but usually not of much help.

Device manufacturers and even carriers have developer portals that do publish the specs of devices BUT, almost in all the cases you end up not finding the detailed information you are looking for. For e.g. The specs say that a device supports MMAPI 1.0 but it usually does not mention if the device the supports the complete implementation or just the audio subset.

Among Manufacturer's dev portals, Nokia's Forum Nokia site is my personal favorite, Motorola's Motocoder site also has improved leaps and bounds in the past 6 months. I will not even talk about Sony Ericsson's specs on their own devices.

Carriers too publish the specs of some of the phones they support but most of the times they link you back to the manufacturer's site. CDMA carriers are better to work with atleast here in US cause they do have and provide the most detailed info on devices when they want to :-).

There are a bunch of third party efforts that do offer comprehensive info and benchmarks on devices but most of them are charged services.

Personally, I love the TastePhone site, its free and gives me the info that I most look for in my apps. If you are J2ME developer then its a MUST visit site for you and while your there try adding your device to the ever growing list ;-)

TastePhone, the MIDP phone benchmark midlet

Sprint PCS toolkit and Netbeans 4.1 (How To)

This post deals with ONE way to get the Sprint PCS toolkit 2.0 to work with the Netbeans 4.1 (Mobility Pack) IDE.

1) In the IDE, Open the Java Platform Manager (Tools->Java Platform Manager).
2) In the Platforms: section, select J2ME.
3) Click on the Add Platform Button.
4) In the Dialog that opens up, navigate to the Sprint Toolkit installation directory and select the 'EmulatorWTK2.0" directory.
5) Click Next and Finish up the process.

Now that the Sprint Platform has been added to the IDE, you can test it out by importing a project from the Sprint PCS toolkit. I am using the MapMuglet MIDlet suite as this uses the com.sprintpcs.util package.

Note: While importing the application, Set the Emulator Platform as the Sprint PCS toolkit 2.0 from the drop down in the final step of the import.

J2ME Wonderland

Been out of the posting loop for quiet a while. Found myself working on J2ME after about 6-7 months of hardcore BREW development last week. The whole time I spent on working in Java for mobile phones made me appreciate BREW even more. Its not the development environment or anything of that sort. Developing in Java is great, its the implementation of the JVM (KVM) on the handsets that sucks. I know the whole security, write once run everywhere routine but I feel Java draws the short straw when it comes down to cell phones.

BREW isn't perfect but it does give a developer a whole bunch of control over the flow of the applet. J2ME is sadly, very implementation dependent. Things that work flawlessly on a Nokia device will crash on Sanyo. Developing a MIDlet that in truly cross platform is an art that you learn from experience.

I learnt something new about the Security Architecture of Java MIDlets this week. On certain implementations the permissions to ask for in the MIDlet-Permissions: attribute of your JAD file are not exactly the same as mentioned in the JSR's.

For Instance, I kept getting a Security Exception while trying to access the camera on the device (JSR 135). I had everything in place. The MIDlet was signed and I was even asking for permission to capture frames from the camera.

javax.microedition.media.control.VideoControl.getSnapshot

I believe the specs on JSR 135 state that this is the permission to ask at install time but they don't mention that on certain implementations you might also want to also add permissions for other classes in a "protected package". This is the part that sucks, the specs on the JSR are too vague and give a lot of freedom to the implementers. This is good in a way cause the implementation of KVM on a device also has to take into consideration the device limitations and the carrier requirements but to a lowly developer like me .. it sucks big time. Had to add these permissions to the Jad file to finally get the MIDlet to run on the device (Thanks to some help from the Carrier support after 2 frustrating days)

javax.microedition.media.Player
javax.microedition.media.Manager

For more info on the security architecture of J2ME : Article in Sun's J2ME section

J2ME Emulators : Impressive

This is an Impressive collection of the emulators etc needed while developing in J2ME. Hats off to guys at ShareMe technologies to take the time out to compile this.

Link : ShareMe Technologies LLC