It is important for me point out that these new challenges require new techniques/technologies/solution to combat. For example, while using pre-processor can help maintain a single code base, it usually makes the source code unreadable and not maintainable if the number of devices is more than a handful. Also, it might not be very scalable as more people are added to the team. Using more modern techniques such as Aspect Oriented Programming (AOP) can help to speed up the overall development process and make it much less painful. AOP helps modularizing and reusing code snippet for device/operator specific issues or other optimizations without reverting to the lowest common denominator approach. There are many other mobile domain specific software/solutions in market to help tackle the mobile deployment challenges.

Ultimately it all comes down to finding the right solution to the problems. With the right solution, these problems are not insurmountable.

Allen

best regards,

Charlie

Solutions that rely on preprocessing (such as NetBeans Mobility Pack: http://www.netbeans.org/kb/50/preprocessor-syntax.html) also simplify the code porting and management issues by letting one source serve all of the different target devices and only if/then-ing on the portions of code that really require it.

While using the latest and greatest APIs is very cool and leads to compelling apps, you can’t reasonably expect all of the devices out there to support those features. So, you can either comment those out or just target your app at a smaller selection of the devices on the market.

Fragmentation in mobiles has nothing to do with technology most of the time, it has to do with marketing devices to different consumer niches. An OEM such as Nokia doesn’t come out with 20-some devices per year because they have nothing better to do – they identify different segment requirements (or operators define them for them) and produce devices that appeal to consumers. Regardless of what application technology you are using (native, Java, browser, Flash), those physical and sw differences will have an impact. While browsers may have the smallest deltas, there are plenty of differences between them as well, especially in the mobile context.

Ultimately, it’s about taking a “lowest-common-denomitator” approach and then optimizing on the aspects and devices that matter most. That will be the case regardlesss of what language, platform or runtime is in question.

The problem with developing an app specifically for a handset deal is you inevitably end up designing with the wealthy patron in mind, not the actual consumer – hence all the lame apps that showcase some whacky here-today-gone-tomorrow feature in a particular series of handset. When that handset is off retailer’s shelves, there goes your app too.

I’m in charge of handsets design and development in a European mobile operator which operates i-mode service (1.5 Millions i-mode subscribers for now)

As you may know i-mode uses a different flavor of Java which is call DoJa. We have now an experience as operator for 3 years with DoJa, and we reached to get 400 different contents on our official i-mode portal, and much more in the independant world. All those contents are running on all the i-mode phones we have launched. This is a huge difference with MIDP, where operators have to indicate to their customers which content runs on which phone.

Now we do understand much more why DoJa is far superior to MIDP : software porting from one DoJa phone to another DoJa phone is an average 5 times less work compare to the same task for MIDP. There are two main reasons to this difference :

1) NTT Docomo’s specification for DoJa, given to handsets vendors, is much more precise in terms of behavior for each described API. There is no optional features as we can find everywhere in MIDP specs. One good example is application size limit that doesn’t exist in MIDP. (DoJa 1.5 is functionnally slight superior to MIDP 1.0. Doja 2.5 is functionnaly equivalent to MIDP2.0 MMAPI Messaging API)

2) Docomo ensure itself DoJa conformance for each new handsets. Those conformance tests are extremely complete : more than 8000 tests cases for DoJa 1.5 and 14000 for DoJa 2.5. This take 3 weeks to be done before handset being approved by Docomo. Including is also a performance benchmark, and we now that it is also often difficult to port software when there are huge performance gaps between phones.

Yes the effort required by handsets vendors is higher, but the benefit for content developer is huge : each API is guaranteed to have one well defined behavior. Adapting and porting then is mostly reduced to screen size differences.

With this feedback, we can deduce why MIDP is an hassle for content developers : Sun should have put much stricter certification procedure, and should have asked to specification guys not only to write programmers documentation, but detailed handset implementation documentation and get rid of all optional features.

Regards,