Seapegasus Blog

Monday May 22, 2006

Your Mobile Wants You To Know This

Java ME, here I come. ;-) Yesterday after coming home JavaOne, I talked to a nice Swiss business man and he spontaneously gave me his old Motorola, simply because he just had bought a new one! :-o (And no, it wasn't stolen, he had the cables and original Software on CD and all.) And as we all know, having a "set" of devices (I just bought a Nokia last week) to test apps on is the first step to Java ME development... :-)

At least that's what Rodney Aiglstorfer (?) said at his Java ME Troubleshooting session at JavaOne 2006. He did not only reveal his secrets of the trade (see below) but also made me aware of the differences in the USA and European markets: Neither did I know that a lot of Americans use mobile phones without SIM cards, nor that SIM card phones are refered to as "GSM". Probably in Europe nobody talks about this distinction because there is only one system, as opposed to the USA where you choose between GSM and CDMA.

Asia and Europe are already huge markets for Mobile applications, and the USA is about to catch up: Looks like good business perspectives for professional Java ME developers. Here are some interesting items form the JavaOne JavaME Troubleshooting session:

Debugging and Testing

• The big Java ME development secret: "Run once, test everywhere". If you are a professional Mobile developer this literally means purchasing and testing each device, or at last device family.
• Workflow secret: The first 90% of testing is done on emulators. Then you test the app on a device family (e.g. S60 phones) and then on a random selection of individual devices. Members of a "device family" in this sense do not have to be from the same manufacturer, you cluster them by features that are important to your kind of application.
• JUnit test secret: Only the GUI should need human testing - all other tests should be done automatically. Use ME4SE as MIDP library when running JUnit tests.
• Debugging secret: For most developers, the only way to debug mobile apps is using System.out.println() ... You can also write your own logfile to the Record Management System (RMS).
• Tip 1: I want to pipe in that NetBeans Mobility Pack comes with a debugger, e.g. for Siemens and Sony Ericsson devices!
• Tip 2: Declare a final static boolean and use it as a debug print switch -- in the deployment version, staticly false if-statements will be automatically stripped out by the compiler.
• Tip 3: MobileComplete.com is a remote device testing company who can provide you with test results of your application on any number of devices.

Java ME Tools

• For Java ME development you need the Sun Wireless Toolkit WTK. Some tools even offer artificial clockspeed delay etc to simulate the response (or lack thereof) of slow devices.
• There are still people out there developing sucessfully with only emacs + ant. :-) Other alternatives are the NetBeans and Eclipse IDEs.
• Java programming on Blackberry is quite a pain in the neck. Recommendation: NetBeans Mobility Pack or the Blackberry IDE.
• MacOS as a development platform is unfortunately lacking many emulators. On MacOS, the speaker himself uses Eclipse + ME4SE (from Kobjects.org).

Increasing the target group

• Use MIDP 1.0 instead of 2.0 when possible.
• Make sure your app's JAR files are as small as possible, this means 30kb-100kb.
• Avoid requiring special device or carrier APIs, bluetooth, 3D libraries, etc just because they are cool.

Java ME networking secrets:

• Only http is widely supported.
• Put each network request in separate thread to prevent lock-ups!
• Download webdata in chunks - it's faster and can be canceled; only tiny amounts of data should be fully downloaded in one piece.
• Note that the length of a stream of data is unknown in advance, the EOF is only marked by a -1.
• Closing a connection is often the cause of a crash.
• Some carriers cash webcontent -- if up-to-date data is needed, add a random number argument to the URL to make it appear new to the caching server.
• Carriers can control and change http headers, so you can't trust them.

Java ME imaging secrets:

• Use PNG file format for images. Note that MIDP 1.0 does not support transparency for PNG. There are various PNG formats, you need to try which is best.
• If you have lots of images, use tiled maps instead of several individual files to improve performance!
• Always double-buffer.

XML parsing secrets:

• Use a pull parser (with buffering, and while-switch-case), it's faster.
• Recommendation: WBXML + KXML parser.

Data storage secrets:

• Use the Record Management Store (RMS)'s RecordStore API for persistant data storage.
• Don't forget that a MIDlet cannot necessarily access all of the theoretically available memory!
• The definition of the MIDlet-Data-Size attribute varies from device to device (can refer to a hard or soft size limit!) -- so don't trust the API, always test.

Unsorted Java ME secrets:

• If you plan to develop premium services for carriers, be aware they don't pay well, some even require you to pay fees. On the other hand, premium SMS is becoming a common means of downloading pay-to-use content to your mobile phone and it's already a promising market in Europe.
• Certify (sign) your app, otherwise your app will display an annoying dialogue with each connect.
• The fewer classes your app uses, the better: Fewer classes means more free heap space, which means less crashes.
• Depending on the device, the pauseApp() method sometimes pauses, and sometimes exits!
• The speaker listed Sony-Ericsson and Nokia as examples of good mobile device manufacturers, and Sprint and Cingular as examples of good carriers.

NetBeans Evandalists #15

This cartoon reminded me... I once went to a class titled "Introduction to computer science for Cooks". Really! Half of the students only showed up for the first lecture to reveal the secret behind the title. I of course came for the hardware and Java programming basics. ;-) After the professor, a crazily self-confident but competent guy, told us the story of his life (from carpenter to university professor!), he deigned to proceed to the ritual of revealing the truth behind the class's name...:

Officially, the class's name is "Introduction to computer science for students of all faculties". So every year, the prof asked the students which faculty they were from. One year it came to pass that about half of the students answered they came from 'Domestic Economy' -- One of the classes in this slot was canceled at the last moment so they spontaneously decided to come here and learn Java. And the prof went "Huh, what's Domestic Economy? Oh that's, like, cooking, right? Whatever, then I'll go teach computer science for cooks." Well, at least his assistants thought it was funny, and when they later created UNIX accounts for the practical sessions, they created two user groups, cooks for the students and chefs for the assistants. And thusly it was done each year, and probably is still done thusly today! :-)