Rants And Ramblings About Mobile Technology
Anders Borg writing about the fun and crazy world of mobile and Internet service technologies.
You can also read the blog via Twitter or your phone via wap.abiro.com. See the left menu for more news.
Comments on blog entries are moderated, but I'm rather liberal as long as it's not blatant advertising.
For general comments, advertising and contribution queries, please use the feedback form.
Tuesday, October 10, 2006
Automating Java ME application porting
From the title this sounds like exactly what all developers need, but it doesn't really provide a solution to the fundamental issue of being able to run the same compiled application on all Java ME / MIDP implementations, something you can do on most other application platforms, Linux excluded due to the different UIs. Yet, the steps described here at least takes you closer to being able to deliver one set of source code per application, with embedded conditions depending on phone model and set of phone features. Finding those conditions out remains though.
E.g. this statement shows where we are at: You'll need a thorough knowledge of the specific behavior of each device model.
That's impossible, even for large developers, as new handsets with even more different behavior and bugs are released each day.
A solution like J2ME Polish helps a bit, but only in terms of the UI.
I try to solve this in the following ways:
* Use MIDP 1.0 functionality if that's acceptable for a certain desired functionality. MIDP 2.0 implementations are clearly more buggy than MIDP 1.0 ditto, and MIDP 2.0 phones also support 1.0, broadening the scope of the application.
* If that's not possible (e.g. if MIDP 2.0 features or a newer JSR are required for the fundamental functionality of the application): auto-sense that the feature exists and if not give a self-explaining message to the user or try to work around the feature lack. The default error reporting simply sucks: Messages like "can't install", "can't run" etc are completely useless for both the user and the developer, so it's better to catch and report possible issues in the application.
* Test on a good spread of phones, and be prepared to handle issues from customers that try out the application on phones you haven't tested on.
* If nothing else helps, use conditional compilation. That's better than having separate source codes for different phones, as that will completely wreck later maintenance.
To get this straight in the future there has to be much tighter testing of KVMs and KVM integrations. The best way for a manufacturer to do this is to standardize on one KVM provider and use the same application platform on as many phones as possible. Many manufacturers bring in more than one KVM provider for the sake of price/feature competition, but from a technical point-of-view it's detrimental.
Also, as I've mentioned in earlier posts, the best would be if Sun took over the delivery of KVMs. That would fix one major issue with Java ME / MIDP: different interpretations of specifications and different bugs. If there's only one implementation, there's also only one set of interpretations and bugs.
Automate Your J2ME Application Porting with Preprocessing
E.g. this statement shows where we are at: You'll need a thorough knowledge of the specific behavior of each device model.
That's impossible, even for large developers, as new handsets with even more different behavior and bugs are released each day.
A solution like J2ME Polish helps a bit, but only in terms of the UI.
I try to solve this in the following ways:
* Use MIDP 1.0 functionality if that's acceptable for a certain desired functionality. MIDP 2.0 implementations are clearly more buggy than MIDP 1.0 ditto, and MIDP 2.0 phones also support 1.0, broadening the scope of the application.
* If that's not possible (e.g. if MIDP 2.0 features or a newer JSR are required for the fundamental functionality of the application): auto-sense that the feature exists and if not give a self-explaining message to the user or try to work around the feature lack. The default error reporting simply sucks: Messages like "can't install", "can't run" etc are completely useless for both the user and the developer, so it's better to catch and report possible issues in the application.
* Test on a good spread of phones, and be prepared to handle issues from customers that try out the application on phones you haven't tested on.
* If nothing else helps, use conditional compilation. That's better than having separate source codes for different phones, as that will completely wreck later maintenance.
To get this straight in the future there has to be much tighter testing of KVMs and KVM integrations. The best way for a manufacturer to do this is to standardize on one KVM provider and use the same application platform on as many phones as possible. Many manufacturers bring in more than one KVM provider for the sake of price/feature competition, but from a technical point-of-view it's detrimental.
Also, as I've mentioned in earlier posts, the best would be if Sun took over the delivery of KVMs. That would fix one major issue with Java ME / MIDP: different interpretations of specifications and different bugs. If there's only one implementation, there's also only one set of interpretations and bugs.
Automate Your J2ME Application Porting with Preprocessing
