I wanted to write about this subject for a long time, but it is so elaborate that every time I tried to, more and more issues popped into my mind... So I decided to "just write it", knowing that I may have missed a few things, but I would like to dig a bit deeper into the roots of the problems, as the effects of it are already known...
Unlike PCs, mobile phones are very different from one another. It begins with a different hardware (screen, memory, multimedia capabilities) and ends with a different OS/Virtual Machine.
One of the major differences between phone is what OS/VM they support. Some support Sun's Java (J2ME), others Qualcomm's Brew, others support Symbian and then there's the Windows CE smartphones and the Linux-based phones etc.
Going from one of the platforms listed above to the others, is more than porting - it is actually rewriting the application (And managing several codebases afterwards), and if all of the above would have had equal market shares - we might have been in a bigger problem than we already are... However, Luckily for us there is one platform that stands out, and that's J2ME.
Sun's J2ME (aka JavaME) is the dominant platform, especially in Europe, and even in the US it is becoming the de-facto standard pushing Qualcomm's Brew aside. J2ME is a Virtual Machine and as such is sometimes supported on top of other OSs, and that's what makes it so popular.
The problem is that even within J2ME, you still have to write slightly differently for various devices. Do you know Java's Motto "Write once, run everywhere"? Well in J2ME it's more like "Write once, port to 10 zillion devices, test till your fingers hurt and then hope for the best"...
Why does it have to be like that? Well, here are some of the major reasons:
1. Different profiles - Sun has defined two profiles for J2ME based mobile phones. The older one is called MIDP 1.0 and has limited features in terms of graphics manipulation, UI widgets, communications etc. The newer one is called MIDP 2.0 and is much more advanced and contains a more natural support in gaming needs. Today all devices going out to the market support MIDP 2.0, but there are still many MIDP 1.0 devices out there (For example Nokia Series 40 phones such as 6100,3100 are MIDP 1.0). In any case due to the limitations of MIDP 1.0 more and more content makers are not supporting it anymore.
2. DIfferent APIs - Some standard J2ME APIs are not necessarily available in every device. For example in the MIDP 1.0 days, the multimedia API (MMAPI) was not a "must" to define a device as MIDP 1.0 compliant. In the same way, today MIDP 2.0 contains a set of APIs the device must support, but many of the newer APIs, such as Bluetooth, PIM (Contact list access) and more are not a "must". Now, bear in mind that you can't just write a code that checks if that API is available and only if it is use it. If the API is referenced from your code and it is not available - your application will simply not run at all! So again you have to provide several codebases.
3. Proprietary APIs - In addition to Sun's formal specs and APIs, mobile devices vendors add to their phones special proprietary APIs. Usually these APIs allow the developer to utilize new technologies, or just supply a more native interface to the device hardware. The problem is that sometimes in order to create an application/game you have to use these APIs since if you don't everything would run very slow. A good example for that is NokiaUI which was an API that allows an accelerated graphics performance and enables some MIDP 2.0-like graphics manipulations in MIDP 1.0 devices.
4. Buggy Implementations - It is not uncommon to find standard J2ME versions that simply do not implement certain methods, or implement them in a wrong way. Sometimes the vendors are aware of this and mention it in their API documentations, and sometimes the developers themselves find it. So it is possible that two devices that implement the same profile, same standard APIs and same proprietary APIs, would still not work the same. For example, in Nokia 6680 if you'll try to rotate a sprite it will cost you dearly in the heap space (memory) of the device, and most likely crash it altogether...
5. Different hardware - Even if two devices share the same profile, APIs and implementation, their hardware attributes may affect how the code and even the graphical assets should look like. For example if one device has a resolution of 128x128 and the other has 240x320, you may have to produce different graphical objects for each of those. Also you may find yourself changing the UI concept altogether in the 128x128 device as it is too small for a UI that is best seen on 240x320.
The good news is that Sun is working closely with vendors to make a compliant set of APIs that should be more definitive (read my post on the MSA standard). The bad news is that we have heard before of other standards that didn't catch on in the market (Such as the JTWI). The problem is that even if one vendor does not adhere to the standard - all hell breaks loose.... (Not to mention the legacy devices that will affect us for 3 years regardless).
So let's wish Sun some luck, the mobile industry needs it...
P.S. - The photo above was taken in GamearraY's offices... These are just some of the handsets we have... So it's cool to get the newest gadgets all the time, but every such "gadget" comes with the intent of giving our developers a hard time in the porting process...