J2ME Porting: Entertaining a crowd, part 1
One of the major differences between mobile code and desktop code is the severe number of SKUs (that is, variations on the build) that you have to support to make a dent in the customer base. Device support is a truly a long tail; after a couple hundred devices you’re getting close to about 80% of the market.
The biggest problem with J2ME in this case is that, unlike the desktop/PC world of Java, the VMs are built by MANY groups with different interpretations of the spec. Even if that weren’t the case, you’re trying to support some very different hardware characteristics: memory, screen resolution, network limitations, storage, etc.
All this means is that if you want your app to be a success, you’re going to adapt your code to support hundreds of phones.
Ugh.
What’s a developer to do? Here are a few basic points that work for me:
- Stay Organized. This should go without saying, but make a concerted effort to keep your builds clean, repeatable, and stowed away well. Someone will be asking you to send them the latest working build for their Motorola C290, and you should always have it handy. Do one of these:
- Keep a folder heirarchy for your compiled files. Mine looks like:
->Builds -><app name> ->Version (e.g. 0.9.4) ->Screen Size (e.g. 176x220) <standard build> ->Custom build 1 (e.g. Nokia Series 60) <build> ->Custom build 2 ...For a solution like this, you’ll need a handy way to look up capabilities to help you dig out the right build for a handset.
- Build/adapt a simple CMS. If you’ve got some time, this is the best option you’ve got (we’re working on a new one we may be able to share with you, stay tuned). You’ll thank yourself later.
- Keep a folder heirarchy for your compiled files. Mine looks like:
- Write reusable code. Write with the intention of building what you write into a framework. OK, this will probably net you a few more KB in code, but it will save you from hurting yourself over and over again. Write as few new lines as you possibly can in a new app. Every time you fix a handset-specific bug, you’ve fixed it for everything you ever write in the future. In fact, if you’re really pathological, you can extract basically everything out of most apps into your own scripting/markup language and build your apps without writing a single line of real J2ME code. Sounds like a lot of work, not not nearly as much work as supporting two dozen codebases.
- Don’t use the APIs. Really. Do it yourself. The reasons for this tend to fall into two categories:
- Lack of control. Generally, more advanced apps don’t make use of the standard
javax.microedition.lcdui.Formdrawing mode for professional apps, and definitely not for work-for-hire (Try explaining to a client that there’s no way you can change the title’s background, see how they react!). - Lack of bug-freeness. Think it’s handy that you can change the color of a font and write it to a virtual buffer? The original Nokia Series 60s didn’t think it was useful enough to support. Get in a habit of wincing every time you take advantage of another cool GameCanvas feature to your code. Sorry!
- Lack of control. Generally, more advanced apps don’t make use of the standard
- Use a preprocessor. Java/OO purists are going to hate this, but the Java purists must hate quite a lot about J2ME. Use a preprocessor (like the one included with antenna) to build code that works against different handset sizes and capabilities.
- Use the JAD properties to tweak your code. This is far easier to manage than a total rebuild. Take advantage of the JAD properties for simple differences in builds, such as softkey codes, sound characteristics, timers adjusted to the speed of the handset, etc. Again, you’ll be sacrificing a little code size (and maybe a tiny bit of speed, in some cases), but seriously.
April 23rd, 2007 at 6:23 am
Very interesting post. Let me just inform you that Mobile Distillery (http://www.mobile-distillery.com)a french company is focused on solving the porting issues of Java ME applications on the various handsets.
At present, mobile games and applications development depends on the fact that one game or application needs to be duplicate hundreds of times for different handsets. These devices all implement Java differently and have a large variety of screen sizes, keyboard lay-outs and user interfaces…
The cost and time implications are enormous.
The basic principle “Write Once Run Anywhere” should apply here. This is the philosophy of the new Celsius V4 Porting Suite from Mobile Distillery which should ease to solve this fragmentation issues. ‘'’ Mobile Distillery‘s Celsius is a software solution which allows Java ME developers to port mobile games and applications across 550 of Java”’ enabled mobile devices.
Mobile Distillery features advanced optimisation and porting solutions and testing services for J2ME, DOJA & Brew application developers, allowing to develop content for hundreds of mobile phones with unprecedented speed and quality control, in a cost effective way.
Celsius v4 main features include: - FlashLikeForms® : powerful graphic forms in Java ME, directly portable on 550 phones ; - UnlimitedJARsize® architecture : high quality rich media mobile applications ; - Integration of your own technology plugged with Celsius portability features ; - Always connected applications with Http, SMS, Push Registry, NFC, Bluetooth ; - Now supporting US and Canada phones in addition to European handsets ; - Java ME to Brew !!; - NFC
About the author: Bertrand Louveau is in charge of developing Mobile Distillery presence in new and emerging areas of porting J2ME applications to Mobile Phones as well as new markets such as America, Eastern Europe and Asia.
April 29th, 2007 at 5:09 am
You really need a CMS to store every binary? Far better is proper use of source control, tagging every release so it can be reproduced on demand, with the source code available as well for bug fixes…
Most of the rest I’m broadly in agreement over, but I wouldn’t trust what you see on the TheoreticLabs device browser - first device I clicked on (LG KG800 - Chocolate) was stated as MIDP1 (it’s MIDP2), the second (it’s successor the KG810) apparently has no Java (MIDP2 again). When ti does get it right, it’s pretty basic info too.
I’d feel a lot more comfortable about the MobRef stats you link to if they actually declared where they came from as well. They tend to differ quite a lot from reliable stats sources I have seen, with S60 in particular coming up as way way more popular than its basic market share (based on units shipped).
Minor points though - in general, planning, care and reusable frameworks which take nothing for granted are the way forward!
May 1st, 2007 at 7:09 pm
The data in DeviceBrowser is coming straight from WURFL, which is heavily used by the WAP contingent, less so by J2ME devs, so it tends to be poor in some of those areas. Works fine for things like screen dimensions and that sort of thing.
Thanks for the thoughtful comments.
And yeah, source control is a good obvious choice for keeping track as well, and really important - I’ll be sure to include it in the followup. The upside to doing a CMS is that you can use it to deliver the proper binary to end users and the business/QA side without engineer intervention. In real life, I’ve done both a CMS and source control simultaneously, and it has worked out really well. It doesn’t have to be a complicated system, just something that’ll deliver the right build for the right phone.
I’m dubious about the MobRef sources too since the data looks weird, but it illustrates the point. Most of those online phone popularity meters are skewed some way or another.
Anyway, all in agreement.
May 3rd, 2007 at 10:55 am
[…] J2ME Porting 03May07 Yet a few more good tips on real-world J2ME development from 1ft Startup: J2ME Porting: Entertaining a crowd, part 1. Recommended. Filed under: J2ME, JavaME, Java, Development, Mobile, Technology | […]
June 10th, 2007 at 8:27 pm
[…] So, you’ve organized a clever build system that can manage a thousand different SKUs of your mobile software with the greatest of ease, and now you have to stop putting off the fun part: testing. How the heck do you really test on dozens of devices? Your first (and probably most important) stop should be a few things to consider before even loading up a phone: […]
January 20th, 2008 at 6:45 pm
[…] Russel Buckley says it’s nigh-impossible to do iterative development, and he’s right.. but the least you can do is work out some tools that make it as easy as possible. It’s really worth investing the time in a streamlined port management system for those device-loading cravings we all get. […]
July 6th, 2008 at 1:57 am
[…] 29. http://theoreticlabs.com/blog/2007/04/22/j2me-porting-entertaining-a-crowd-part-1/ ..(porting) […]