J2ME - Write once, run anywhere?
I got asked about something in mylast posting:
If J2ME is so widely available and Java is supposed to be "write-once-run-anywhere", why do you need to bother writing apps for the other APIs, notably BREW and Symbian.
This is true in theory and marketing. In reality, it doesn't quite work that way:
1) J2me doesn't give you all the power of a mobile platform, notably the control over the peripherals, such as telephony, audio, bluetooth and irDA.
2) You cannot completely control the look and feel of a J2me app. For example, there is no standard implementation of Command softkeys - all are in the mercy of the phone manufacturers. Your app might look differently on a Nokia Symbian phone and a Motorola phone.
This is especially a problem for companies that want to create apps with a single L&F across all platforms. (For various business reasons this is highly desirable: at least it will lower your support cost for the applications).
3) Integration with native applications are limited in J2me, e.g. addressbook, calendar etc.
(... there are a few more reasons, but I need to get back to my bread&butter day time job now.)
There are notable progress to fix some of these. For example, JSR 253 will introduce a JTAPI like interface to J2me, and with CustomItems in MIDP2, you can write your own controls.
As more JSRs get introduced, the J2me API set becomes more and more powerful. Ironically, it also greatly weakens the"write-once-run-anywhere" imperative. Some of these newer JSRs are optional on some phones. That means a developer has to trade off between the more powerful APIs vs. market share. At the end of the day, might as well write it in Symbian or BREW.
If J2ME is so widely available and Java is supposed to be "write-once-run-anywhere", why do you need to bother writing apps for the other APIs, notably BREW and Symbian.
This is true in theory and marketing. In reality, it doesn't quite work that way:
1) J2me doesn't give you all the power of a mobile platform, notably the control over the peripherals, such as telephony, audio, bluetooth and irDA.
2) You cannot completely control the look and feel of a J2me app. For example, there is no standard implementation of Command softkeys - all are in the mercy of the phone manufacturers. Your app might look differently on a Nokia Symbian phone and a Motorola phone.
This is especially a problem for companies that want to create apps with a single L&F across all platforms. (For various business reasons this is highly desirable: at least it will lower your support cost for the applications).
3) Integration with native applications are limited in J2me, e.g. addressbook, calendar etc.
(... there are a few more reasons, but I need to get back to my bread&butter day time job now.)
There are notable progress to fix some of these. For example, JSR 253 will introduce a JTAPI like interface to J2me, and with CustomItems in MIDP2, you can write your own controls.
As more JSRs get introduced, the J2me API set becomes more and more powerful. Ironically, it also greatly weakens the"write-once-run-anywhere" imperative. Some of these newer JSRs are optional on some phones. That means a developer has to trade off between the more powerful APIs vs. market share. At the end of the day, might as well write it in Symbian or BREW.
0 Comments:
Post a Comment
<< Home