Mobile OS Shootout: The Cross-Platform Developer Point of View
Linked by Moochman on Mon 23rd Mar 2009 09:28 UTC
PDAs, Cellphones, Wireless Engadget's recent piece, "Mobile OS shootout", provides a relatively thorough comparison of current smartphone platforms and what they have going for them, mostly from a consumer gadget hound's point of view. They provide a bunch of nice comparative tables, among them the table "Third Party Development". From this table we learn that each platform has its own SDK, whereby some of the apps available are considered "native" - a distinction most non-developers won't be able to grok, since it depends on an understanding of runtime environments, etc. It's hard to say exactly who this table is targeting, actually; the developer or the end-user that the rest of the article seems to target. Let's just investigate some of the assumptions it makes.
E-mail Print r 1   · Read More · 38 Comment(s) http://osne.ws/gcb
Thread beginning with comment 354739
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: J2ME
by Timmmm on Tue 24th Mar 2009 14:40 UTC in reply to "J2ME"
Timmmm
Member since:
2006-07-25

Have you ever written a J2ME app? I'm guessing not. If you did you would find that it is extremely limited. Compared to a real native app it has the following limitations:

1. Java, hence slower, more power hungry and... well java is just bad.
2. Maximum app size (including all data) of around 1 MB on most phones.
3. Very simple GUI toolkit. Only supports simple (and ugly) forms. There are 3rd party alternatives but none are very good.
4. No filesystem access (unless you pay lots to get your app signed). No seek function.
5. Most other APIs also *require* your app to be signed.
6. Very small library missing lots of functionality.
7. No multitasking (at least on most phones).
8. You can't choose which buttons to assign to menu items - only give each item a priority and the phone chooses (usually in a stupid way).
9. Did I mention Java is shit?

J2ME is possibly the *worst* option. I wish Google would make a nice C++ API for Android.

Reply Parent Score: 1

RE[2]: J2ME
by spiderman on Tue 24th Mar 2009 18:18 in reply to "RE: J2ME"
spiderman Member since:
2008-10-23

Have you ever written a J2ME app? I'm guessing not. If you did you would find that it is extremely limited. Compared to a real native app it has the following limitations:

You guessed wrong. I've actually used J2ME and I find that it allows to do a lot of stuff. I believe it is the right way to do applications for several reasons. It is an open standard in the mobile world and makes your application run on a wide range of phones. This is the best way not to restrict yourself to one vendor. It is secure and portable and not just to mobile phones.
I don't agree with all your points about J2ME.

1. It is not power hungry or slow. The JIT compiles your app before running it and it is optimized for the actual phone it is running on and in many cases, it is doing it better even when the program is badly written, expecially vs badly written native apps with memory leaks and bad structure. It let the programmer concentrate on optimizing what matters the most: the algorithms, instead of trying to do efficient memory management and ending up creating bugs.
2. There is no maximum limit for J2ME apps. It is a good idea to keep them small when you transfer them to mobile phones without 3G support, but there is no limit.
3. There are a lot of them:
http://j2me.ngphone.com/opensource/ui.htm
I find that some of them are pretty good, but it is a matter of taste.
4. There is filesystem access. Most phones ask the user about it for security reasons: you don't want an application you don't know to send your data over the internet or to delete your files. On my SonyEricsson, I can select 'ask', 'allow' or 'refuse', independantly for each apps. I have several J2ME applications installed that are allowed to access my filesystem.
5. Most of them don't.
6. It depends on the phones. There are several JSR that allow you to access pretty much any feature that you can find on a phone. Is there something in particular that you are missing?
7. On most phones, each MIDlet is a task and you can do multithreading inside a midlet.
8. This is true and that is because all phones have different button layout, but the iPhone does not have buttons anyway. On touchscreens, it does not matter.
9. It's in your head

I believe J2ME is pretty nice when you know it.

Reply Parent Score: 2