Opinionated comments on mobile phone industry news
|
All entries are written by Anders Borg, CEO and Consultant of Abiro, that has a long experience in strategic planning, developing embedded and Java software, usability aspects, and the mobile phone industry in general. You can also read the latest Mobile News entries on your phone via wap.abiro.com, and we provide many News Feeds from popular news services. For advertising and contribution queries, please use the feedback form. News feed (local) FeedBurner Feed
|
|
Wednesday, April 26, 2006
MobHappy on Java ME
I'm also frustrated by device differences, making Java ME development hard as you need to circumvent for a lot of device-specific oddities. And to even know what those oddities are you simply need to test the application on a whole slew of phones, and in cases you have to work around real bugs that will never be fixed in the phone model in question (maybe at the manufacturer, but the majority of users will not upgrade the phone system software).
Still, I'm a strong promoter of Java ME, as it's simply the most used mobile application platform, and it's actually quite developer-friendly with very good development tools and easy to use class libraries. Read more about my thoughts on the Java ME pages.
I include my complete comment to Russell's entry below, if it happens to get erased or something. You never know. I was quite opinionated ;).
The Frustrations of Java at MobHappy
My response:
I believe I'm throwing a bit of gasoline on the fire here, but that's what comments are for. I'm as frustrated by the device differences as anybody else, but there are shades in hell too. All personal opinions of course.
I think we should be careful not falling into the "If it's not perfect it's useless" trap. All seasoned Java ME developers know it's not WORA, so let's get on with it. "Adopt, Adapt and Improve", as John Cleese once said.
The KVM provider and phone brand specific differences between phones and hence the need for testing on "all" (at least very many) phones, is the biggest issue with Java ME in my opinion (more so than the overall feature differentiation/evolution specified by Sun which is a necessity; everything evolves), but it's not a show-stopper. There are companies that specialize in such testing, by simply having most commercial handsets in their labs. In many cases such testing, especially on simple corporate client/server applications, can easily cost more than the implementation, or at least take the most time. Solutions like J2ME Polish and similar can help, provided they are used from day one.
Java ME and WAP (or HTML) are often not alternatives, as WAP has no access to local phone functionality. There's a lot of services you can't do without that. Maybe Flirtomatic doesn't need it, as I guess personal photos could be sent in via MMS equally well, etc.
Especially when we start talking games (2D, isometric or whatever) it becomes apparent WAP doesn't even come close to the interaction and functionality that's possible via Java. I could even say WAP won't cut it at all.
Let's take a more pro example: You want to show a stock chart that you can scroll and scale without latency. Is WAP or even HTML suited for that? No. Is Java ME suited for that? Yes indeed, and you don't even need any newer phone for it to work. Already MIDP 1.0 supports simple but useful vector graphics. Flash could do this, but it doesn't exist in enough phones.
I would argue that Java ME is actually good for RAD, with a big but: Writing a client/server form-type Java ME application is incredibly easy and quick, as long as you only test it on one specific phone model initially (e.g. my Mobile Blogger only took 8 hours from waking up in the morning with the idea and to publish the first version on GetJar; it certainly doesn't support all phones, but that wasn't the intention as it's free). That's RAD to me! If we talk public "for everyone to use" services the phone differences need to be understood and handled before the service is launched. I believe many still make that mistake (I did it with another (and commercial) application that I won't mention).
"The network is the computer" is very much about downloaded local applications (where Java was supposed to be used), so Java ME fits that description well in theory, provided it had been the same Java base implementation on all terminal devices.
The fragmentation _IS_ actually to a large extent Sun's fault, as Sun handed out the rights to others to make KVMs and base class libraries, which resulted in a plethora of differently behaving (and also in cases quite buggy) and differently featured implementations, instead of one "if it's a bug it's a documented feature" single reference and implementation at the same time. They didn't make that mistake with J2SE and J2EE, so why with Java ME?
Another drawback with Java ME, as opposed to J2SE and J2EE is that upgrading the KVM and class libraries can't easily be done on featurephones (which is what the majoity of people use). Typically you need to upgrade the complete phone software, which pretty much nobody does. That means from a developer point-of-view that possible bugs and other oddities stay the life-time of the specific phone model. If the phone runs BREW you can in cases easily upgrade the KVM (the KVM runs on top of BREW), but BREW is much less used in phones than Java ME, so the issue is still there.
I guess I'm getting into "Messerschmitt" mode now, but J2ME is the abbreviation of "Java 2 Platform, Micro Edition", which is even longer. I think "Java ME" as new abbreviation (no more "2") is better from a branding perspective.
Still, I'm a strong promoter of Java ME, as it's simply the most used mobile application platform, and it's actually quite developer-friendly with very good development tools and easy to use class libraries. Read more about my thoughts on the Java ME pages.
I include my complete comment to Russell's entry below, if it happens to get erased or something. You never know. I was quite opinionated ;).
The Frustrations of Java at MobHappy
My response:
I believe I'm throwing a bit of gasoline on the fire here, but that's what comments are for. I'm as frustrated by the device differences as anybody else, but there are shades in hell too. All personal opinions of course.
I think we should be careful not falling into the "If it's not perfect it's useless" trap. All seasoned Java ME developers know it's not WORA, so let's get on with it. "Adopt, Adapt and Improve", as John Cleese once said.
The KVM provider and phone brand specific differences between phones and hence the need for testing on "all" (at least very many) phones, is the biggest issue with Java ME in my opinion (more so than the overall feature differentiation/evolution specified by Sun which is a necessity; everything evolves), but it's not a show-stopper. There are companies that specialize in such testing, by simply having most commercial handsets in their labs. In many cases such testing, especially on simple corporate client/server applications, can easily cost more than the implementation, or at least take the most time. Solutions like J2ME Polish and similar can help, provided they are used from day one.
Java ME and WAP (or HTML) are often not alternatives, as WAP has no access to local phone functionality. There's a lot of services you can't do without that. Maybe Flirtomatic doesn't need it, as I guess personal photos could be sent in via MMS equally well, etc.
Especially when we start talking games (2D, isometric or whatever) it becomes apparent WAP doesn't even come close to the interaction and functionality that's possible via Java. I could even say WAP won't cut it at all.
Let's take a more pro example: You want to show a stock chart that you can scroll and scale without latency. Is WAP or even HTML suited for that? No. Is Java ME suited for that? Yes indeed, and you don't even need any newer phone for it to work. Already MIDP 1.0 supports simple but useful vector graphics. Flash could do this, but it doesn't exist in enough phones.
I would argue that Java ME is actually good for RAD, with a big but: Writing a client/server form-type Java ME application is incredibly easy and quick, as long as you only test it on one specific phone model initially (e.g. my Mobile Blogger only took 8 hours from waking up in the morning with the idea and to publish the first version on GetJar; it certainly doesn't support all phones, but that wasn't the intention as it's free). That's RAD to me! If we talk public "for everyone to use" services the phone differences need to be understood and handled before the service is launched. I believe many still make that mistake (I did it with another (and commercial) application that I won't mention).
"The network is the computer" is very much about downloaded local applications (where Java was supposed to be used), so Java ME fits that description well in theory, provided it had been the same Java base implementation on all terminal devices.
The fragmentation _IS_ actually to a large extent Sun's fault, as Sun handed out the rights to others to make KVMs and base class libraries, which resulted in a plethora of differently behaving (and also in cases quite buggy) and differently featured implementations, instead of one "if it's a bug it's a documented feature" single reference and implementation at the same time. They didn't make that mistake with J2SE and J2EE, so why with Java ME?
Another drawback with Java ME, as opposed to J2SE and J2EE is that upgrading the KVM and class libraries can't easily be done on featurephones (which is what the majoity of people use). Typically you need to upgrade the complete phone software, which pretty much nobody does. That means from a developer point-of-view that possible bugs and other oddities stay the life-time of the specific phone model. If the phone runs BREW you can in cases easily upgrade the KVM (the KVM runs on top of BREW), but BREW is much less used in phones than Java ME, so the issue is still there.
I guess I'm getting into "Messerschmitt" mode now, but J2ME is the abbreviation of "Java 2 Platform, Micro Edition", which is even longer. I think "Java ME" as new abbreviation (no more "2") is better from a branding perspective.
