Tuesday, May 02, 2006

J2ME Midlet signing

I've been searching the 'Net for procedures and guidelines procuring a real digital certificate to sign mobile codes (in our case, Symbian .sis files and J2ME .jad & .jar files) before they get to our customers' mobile phones.

Not having much cash at hand, it's a little difficult for my company to pay a lot (between US$199-$500 annually) just for a piece of document (a digital one at that!) that basically ascertain you are who say you are on the 'Net. For some environments, it is becoming necessary to have a certificate before our code (application) will run at all. For others, like J2ME, it is simply to save all that hassle on the part of the users, who have to say "Yes" to every operation your app is meant to do on the mobile phones, such as taking picture, listing down their files, and connecting to the 'Net. What started out as a security requirement has become an obstacle to rolling out good, smooth user applications (who wants to say yes a hundred times just to display a hundred files?!)

In any case, here's summarizing what experience I've gathered from the people who've tried and sometimes succeeded, sometimes didn't:

  1. Don't get your hopes up eliminating ALL those pesky pop-up permission windows

    Sometimes, not all the permissions requests you have indicated will be granted. Some handset firmwares/operators will relent enough to give you blanket permission; some will merely relent to ask the end-user's explicit permission only once at the beginning of the session. AFAIK, midlet signing is very useful when your app runs JSR-75 (so that your end users are spared having to click 'Yes' to every file/every contact in every folder that is about to be listed). You have been warned.

  2. Expect different performance raise (or non-raise) on different manufacturers' (Nokia handsets should perform reasonably uniformly) and different handset models

    Same handsets in different countries and running different operators' SIM cards may end up giving you different behaviors. Some might 'repress' the permissions you requested. You have been warned a second time.

  3. Make sure you get the right certificate: code-signing cert, not the SSL type!

    It might waste you a few hundred dollars if you get the wrong type. Also, not all Certificate Authorities (CAs) have their code-signing root certs already preloaded on the mobile handsets your app is meant to run on! Check and double-check! You have been warned a third time.

If you find this summary relevant but too short, here are tutorials & troubleshooting and helpful links to better, longer discussions on midlet signing issues. And I wish you success in your applications' launch!

No comments: