Java Mobile: Write once, run anywhere... just run!
Introduction
Here at Intohand, the core team has been working with Java on the mobile device ever since - well, the first mobile device with a Java machine. Going back to the times of the Motorola Accompli 008 and handsets like the Nokia 6310i, it's an awfully long road travelled in the last six or so years. Phones have become colour, internet connected, able to sustain calls for more than 20 minutes, and they've become hosts for a diversity of features (some of which are useful!). We've enjoyed seeing both staggeringly poor and remarkably good implementations of Java on handsets, and it's about time to reflect on the experiences with a view to how things might progress in the future. However, before we do that, let's have an appraisal of where we're at in the world of Java Mobile Development.
Java Standards
Standards form the basis for what should constitute Java Mobile. Thankfully, there's some process by which the capabilities that can be declared to exist in Java are organised. Thereafter, it's down to the individual implementations to actually represent themselves in devices, and this is where the first Java Mobile hurdle needs to be crossed.
The standards themselves do not define any boundaries of quality of implementation: you get what the manufacturer believes at the time is the relevant capability. Or not - some manufacturers look at standards with optional capability and declare support even when full support doesn't exist. This is the first challenge in determining support of a given device: when the manufacturer data says JSR-xyz is supported, what do they mean? Often, it's a tick box on a checklist of acronyms - and may not be of value to the developer who requires xyz to be implemented correctly.
So, let's park the standards for now. If you are a Java developer, just don't assume that the list of capabilities you have is accurate: treat it as a guideline for potential capability.
Physical variations
The most obvious characteristics that cause variation from device to device are literally just those - shown in the first thing that you see. The big variations for a Developer to contend with usually start with the screen size, and key mappings; thereafter the real fun starts.
While a screen may display a certain number of pixels, the way the device writes to the screen can yield a secondary problem. Phones are not equal when it comes to storing images in their heap memory, some store the images in a raw format, and some phones can display images with considerable speed - up to 50 frames per second - whereas other devices are heating up at 12 fps. The extent of memory usage variation can be considerable, and at this point we're already worrying ourselves as to the inherent function of the application in terms of the ability to support multiple devices.
So, while the screen might be too difficult we should look at something easier: key mappings. We quickly find no standards for all of the key press events - so while -6 might usually mean OK, it doesn't always. No problem, we just need to extend the support database (that we are now pondering whether we are going to need to make, populate and maintain) to handle different key mappings for each phone. While we're at it, we better start looking at key press / key release events. Believe it or not, it is the case that not all phones support key release.
On closer inspection, it seems that not all phones actually have a D-pad - or softkeys. So we're definitely going to need that device database after all.
Information can be hard to find
Before going any further, I'm going to set up the manufacturer's emulators on my desktop. These will solve porting problems because they represent the device, don't they? No. An emulator is a pretty desktop application that you can use to show your boss and colleagues that you're doing something related to coding for phones, but you really should move to a desk with your back to the wall and keep the PC's RAM memory for something worthwhile. Let's face it, your browser will be working hard while you're reading the various internet fora and furiously searching for some weird and wonderful effect that is hampering build on your shiny new device - and the browser will need that RAM.
So, I've got my database and I'm ready to start harvesting data to populate it. All I need now are the devices that are targets, and the characteristics of these. At this stage I look for the devices on sale now, and the popular handsets from the last year or so - as these will be possible targets for my application. My customer is very concerned about the latest and greatest handset that is about to be launched on their network, and if I can support that it'll help a distribution deal - all I need is the data to help with that handset. This is a massive list that will seem daunting if you aim to support one country - let alone a continent such as Europe or the US - and you haven't even left the feasibility stage of the application yet.
This is the point where many developers lose enthusiasm and seek something easier to occupy their lives with. Like finding really big prime numbers, or trying to break WPA encryption using a desktop calculator. Anything - except dealing with device fragmentation in Java.
The reality of the devices that were on sale over the last year is that they have got some really strange behaviours in their Java implementations. The good news is that you can find spec sheets for a lot of these devices, but the not so good news is that those spec sheets don't spill the beans on where your application might fail. Here are some good ones, just for starters:
Icon won't display, or displays with incorrect sizes
Jarfile is too big to download OTA
Vibrate doesn't work when the device is on charge
Heap memory varies - depending on what theme the phone has
Extended characters don't display with some font sizes
So - before you start coding, make sure you have experience of the devices from the last few years so you already know these things! This will allow you to make some guesses about the latest devices - after all, you can't find spec sheets for these, so any attempts to profile them will be based on guesswork and an intuition of the particular manufacturer's approach. You need this stuff to be understood, as you're about to hit some real challenges in scaling.
Scaling
Scaling is probably the critical aspect of Java development today. At least, if you want any return on the (now significant) efforts put into development. Scaling manifests itself in more ways than devices: often, developers face an exponential problem based on titles/devices/languages. Sometimes, the titles have to break into low tier and high tier functionality - but let's just keep it simple and assume each is another title. Probably a title that you will re-skin at the request of a distributor or carrier partner - after all, that's only another branch to maintain. Superimpose the branches on the myriad of devices to make a support list, and then the language problems can be cracked. Languages are in fact quite easy - once you understand what fonts are supported, and to what extent, and whether or not the manufacturer has put word wrapping in correctly, and whether the new language pack is going to trip up something else like pushing your application over a maximum file size. Remember that you'll need to draw some of these fonts the pixel art way. And so on.
The scaling problem means that the permutations of software are going to vary dramatically: consider that you will maintain code in the field which has perhaps two variants per title, running on at least 100 base devices, in around 8 languages. Of the space that could be occupied here, a simple application will max out with around 1800 versions before you extend language support. Just make sure you test thoroughly before release.
Some real world problems
Now, you've got the title coded, you have your port candidates, you've begged/borrowed/stolen to acquire test devices -it's test schedule time. Just a few minor problems here: make sure that the device firmware builds are understood. Believe it or not, Java machines change within model: the classic one being a smartphone that bug-fixed the JVM at its next firmware state. Not nice when you just coded round that bug...
(Note to operators: let the user agent go through your network. It'll help developers to make code better and keep your customer services a little less busy).
If you are going to group the devices, to try to catch all the similar ones from each manufacturer, make sure that the model designation is accompanied by firmware and track characteristics on this basis. Don't assume that the first model out of the door is the best: often, the later ones have deteriorating Java performance as the manufacturers try to improve battery life for subsequent shipments. Look for the weak firmware variant and try to acquire that as a reference device. Make sure you have data collection that you believe in for populating your device database.
I did all this. What next?
Congratulations! You cracked all of the above and you can start coding applications that may see the light of day. These are the real fun challenges now: if your application uses network resources, you've got the enjoyment of setting phones up to actually permit the use of the data network and/or messaging capability. That means you can invest your coding resource into understanding how the networks actually handle data events. Hang on - you didn't assume that http from the Java machine works cleanly in the real world, did you?! Shame on you! The networks are there to offer challenges, not to make your life easy!
Moving Forward
We've had a little bit of fun immersing ourselves in the strange world of Java on mobile, and this article will probably cause some amusement amongst those who've been there, and concern those who haven't. Yet we must move ahead: the key problem with Java development on mobile is actually in how the fragmentation manifests itself. When there were few devices to code for, the problem was self-limiting - now we have multiple devices, a large variation in standardised APIs, new devices every week, globalising distributor concerns, complex client-server interactions, and more challenges. All of these conspire to make Java actually less accessible than ever, and the cost barriers to commercialisation are becoming insurmountable for many companies.
This is the stage in the Java Mobile industry evolution where something dramatic has to happen if growth is to continue. At this point we might ask whether Java is the right platform, but that would be missing the fact that the platform doesn't matter. What matters is that the platform can be managed - and a lot of that management must come out of sharing information about the real world behaviour of devices. Information about real-world behaviour of Java mobile devices simply has to become accessible to all.
About Intohand Ltd
Intohand is an independent UK software house, dedicated to the production of tools that make life easy when it comes to making mobile information sites. Intohand specialises in publishing content to mobile devices, Java application coding and mobile client-server content handling applications.