It is unnecessary to say that many developers are using J2ME to develop their games and enterprise applications to take advantage of the ‘write once, run anywhere’ paradigm. Who am I do bash this very noble intention, but phones unlike many other types of computer, have no uniform set of memory and storage parameters that improves over time.
Phone specifications are dependant on price considerations more than anything else, and developers just have to work within the bounds of this unusual eco-system. It’s my opinion that the success of developers is ultimately driven by their ability to create software that has a wide platform to run on and is sold no sooner, or later, than the day both the handset manufacturer, the operator and the consumer are ready for it.
Developers are often surprised how soon certain features have suddenly become available while they totally underestimate how long it will take until other features and technologies to become available. Because it is so hard to gauge this, I have taken the attitude of spending more time on development rather than listening to inaccurate release dates from the manufacturers. And, when the device is actually here, I make sure that I’m ready to port quickly. Both your company management and the phone market require a high degree of flexibility in terms of making J2ME applications compatible with specific devices. Another truth is that it turns out that you as developer can easily underestimate how much effort it will take.
Balancing heap memory usage, storage parameters, screen size / color depth considerations, and network specifications with application size and features is already a difficult task without talking about device-specific API extensions and the various VM bugs.
So, what’s the most efficient approach to porting your applications to multiple devices?
Step 1: Research the Target Device
Before you do anything else, you must research your target device. Look for reported bugs that might be affecting your application and test it separately with test code. Get all the specifications right; it’s not so that there’s never a difference between how the device according to available documentation is supposed to perform compared to how the specific device you are using is performing. Devices with different software release dates or versions can potentially have significant differences. Take down the software numbers of your device firmware and compare them with the software version that your target mobile operator is releasing. If you don’t have the device yourself, establish a contact to test the software before you start, he/she might even give you some valuable pointers.
Step 2: Re-design the Application
In order to fit the properties of the new device, you must re-design your application architecture. If you know the available heap memory is only half as much of what you’ve been using on another device, don’t even try it, that’s loosing time. With porting, you’re not supposed to use the trail and error methodology. Take the same design considerations in mind as you did for your first version. In many cases by the time you’re done, you’ll find yourself ending up with a very different code source. Depending on whether you port from a better to a worse device or the other way around, you always benefit from rethinking the architecture of your application.
Step 3: Make the Decision
Only now, you can make an educated decision of whether it’s worth the time and effort to do the port. It is only now you can tell your boss or client what it will take and what it will cost. The success of the first two steps is important in making that decision. If the handset manufacturer can’t provide you with the detailed info to make that call, you know you’re opening your team up for a risk. No one can deny the many posts on discussion forums of developers asking for help on a device spec at the point they are halfway into something and you just know only divine help will do. It is really recommended to avoid being put in that position in the first place. It’s a good move to contact your application publisher or certification and testing partner to give them a heads-up on the device issues that might still be unclear. There is a possiblity that your features will work properly, but for other than purely technical reasons, your app gets shot down by the operator as too network intensive, unsafe or inappropriate.
Step 4: Process the Graphics
Since you are dealing with a new screen size and color depth, you are going to have to re-process the graphic elements of your application. It’s always useful to have hi-res artwork that you simply can size down in the right format and color palette depending on device. Keep in mind that in many cases reducing the amount of colors is only going to affect the jar size and your device still will use a certain flat amount of bits per pixel (ex. 16 bits) no matter how many colors you use in the .png file. The colors themselves will also look different depending on the device (even models from the same manufacturer). As there are more RGB values than distinguishable colors on the phone display (depending on display quality) there is a range of RGB values that will result in exactly the same color. However, those ranges are often device dependent. Some manufacturers do publish documentation on that, so we know what to do, to keep the color palette look the same across devices.
Step 5: Modify Your Source Code
After the first four steps, making the actual modifications to the source code should be a much easier job. Using the emulator provided by the manufacturer often saves you a bunch of time, especially if there are device specific API’s. Getting them installed properly and integrated with your IDE is another matter of course. My personal experience tells me not to care too much about the integration with my IDE, so I have a small ant build script for compiling, packaging and obfuscating and another for running it on a specific emulator. Every SDK gets one fair chance to install and integrate with my development environment, if it doesn’t, too bad. Using it stand-alone spares me a lot of frustration.
Step 6: Testing
You must test the application on the target device with the production version firmware. Don’t be tempted to upgrade your phone to the latest version of firmware if you know there are phones being sold with previous versions. It has no use; later versions are almost always better but won’t make your application better. The reality is that devices get released with bugs and you have no choice but to work around them. When testing your own application it’s hard to be critical and unintentionally some developers are too gentle with their applications. Before your application is to be certified, testing engineers will put the application through rigorous testing anyway, you can as well test it right yourself. A checklist with tests and requirements is available from most handset manufacturers and also available on microjava.com.
Knowing the bugs is becoming more valuable than knowing the entire API. As application developers, we end up finding significant bugs in almost every device we develop for, and this shouldn’t either be a secret or anything we get mad about. I do have admiration for the developers that port and develop the KVM on the handsets in a relatively very short amount of time and we know no software is 100% bug free. Micro Java Network will be releasing a number of porting guides for specific devices in the near future, which will include the known bugs as well. If you like to contribute, please send an email to info@microjava.com.
Best of Luck and check MicroJava.com for device specific porting guides.
First appeared at http://www.microjava.com.
Xavier Facon is the founder and CTO of Crisp Wireless and co-founder and director of MicroJava.com. Crisp Wireless was a pioneering company for the wireless Java industry and has developed the mLogic technology that enables very compelling client/server content publishing, commerce and community applications on Java-enabled handsets. You can contact Xavier at xavier@microjava.comwith comments or questions on this article.
