Search the site
What we do
Little Springs Design is a mobile product, research, design, and usability testing consultancy. We help wireless operators, associations, manufacturers, and application & website providers with product and UI design, patterns, training, research and strategy.
Contact us today.
Downloads
Sign up to get a free copy of our Mobile Widgets Whitepaper or almost-monthly newsletter. Or buy mobile Java or web design guidelines.
Recent blog entries
Blog topics
Blog archives
Java ME is dead. Long live Java ME.
In this "year of the mobile web" where pundits everywhere are talking about how "the web is the platform" ....
In this time of "let's get a good enough browser and then mobile will take off" ...
In this time of "Java ME is dead" ...
4 of our 6 first quarter projects have major components in Java ME. These are new applications, from companies who understand the porting issues and the complexities.
Why are they using Java ME?
- Because they need to store some of their application logic and/or data locally
- Because the app or data needs to be available without the network
- Because the application would be dreadfully slow as a web app
- Because they are creating a push messaging client that needs more rich interaction than simple SMS (and better interoperability than MMS)
This quarter is not particularly different from other quarters: we get far more work designing applications than designing web sites.
Java has lots and lots of problems. You know what they are. I think they are fixable, and the good news is that we can use the platform now. So many of the browser and widget platform possibilities keep being "just around the corner" and the opportunity is now.
Java ME is going to keep on chugging, maybe even seeing a rebirth, for quite a while yet. SavaJe doesn't spell the death of Java ME either.
10 Comments »
RSS feed for comments on this post.
I am glad you posted this. I think that push is the killer for these apps. Its what makes me excited about working on all those products. Browsing is, no matter how cool, browsing; it implies the time and casualness to sit still and deliberately browse around.
Push services — however they are coded — feels timely, relevant, local, quick and contextual. Everything a mobile device ought to be.
Comment by steven — February 18, 2008 @ 2:06 pm
hi Barbara
I think the defining point of any mobile platform is (obviously) the experience it provides, and also the points you have mentioned here. So it’s up to the stakeholders (owners, designers, developers) of the product to choose the platform wisely. I did a presentation to the local Barcamp here in Delhi, India, which was about how to choose the right mobile platform for your product, among other things. Do check it out here http://www.slideshare.net/soosixty/going-mobile-taking-internet-products-to-mobile-from-a-ucd-perspective I’d love to know your feedback.
Comment by Soo — February 18, 2008 @ 11:08 pm
sorry, that link’s not working - try this one:
http://www.slideshare.net/soosixty/going-mobile-taking-internet-products-to-mobile-from-a-ucd-perspective
Thanks for the correction, I’ve fixed it in the previous post to make sure no one gets stuck – steven
Comment by Soo — February 18, 2008 @ 11:12 pm
@Soo - I regularly like the presentations you and Ekta post; really solid concepts and good communication. This one in particular looks solid. If you’ve got the time, do contribute to http://patterns.littlespringsdesign.com with some of your learnings.
Comment by Barbara — February 19, 2008 @ 10:55 am
You are spot on, Barbara.
Even if “Web Browser Runtime” is to become a viable development platform for rich mobile apps, you are still going to face the same kinda portability issues like what J2ME faces today. Look at the desktop, designers and developers are creating websites and hacks to make it work for various desktop browser (IE, Safari, Opera, Mozilla), I am sure this very same issue is going to re-surface for mobile browser, unless we have only one and only one browser platform that dictates the play.
Apple has shown its mettle on its UI technology
Do check out what we have done on creating a game-changing UI platform for any J2ME apps to have the kinda rich UI, snazzy animation and fluid motion graphics that is miles ahead of ADOBE FLASH LITE. And it’s available on J2ME/DOJA/BREW
Videos here ->
http://mikali.blip.tv and http://www.tricastmedia.com/videos
Comment by mika li — February 19, 2008 @ 1:01 pm
wow, Barbara, we’re so honoured! Would love to!
Comment by Soo — February 20, 2008 @ 3:56 am
100% agree. That’s why I feel compelled to comment on the “Java is dead” posts I see - it’s only dead if you’re more interested in theoretical future utopias and not interested in real customers now… and Mika you’re right, future web platforms will have at least as many porting issues as today’s Java (which are all solvable). We don’t see them yet because the platforms don’t really exist yet…
Possibly interesting / relevant: more porting/fragmentation thoughts at http://blog.masabi.com/2008/01/truth-about-mobile-fragmentation.html and a discussion of the usability/funnctionality benefits of thick vs thin clients on mobile today at http://blog.masabi.com/2007/08/thick-vs-thin-clients-in-mobile-today.html
Comment by Tom Godber — February 21, 2008 @ 10:27 am
Well, the problem is that JavaME is fragmented because some manufacturer do not care of providing good software (no, I’m not on talking about HTC problem with almost no JSR support !).
We need a simple platform, where you know exactly what you got “by default” and are able to require mode feature (module) to be there.
IMHO, this is what JavaSE is about to bring (when the “OSGi trouble” will be over).
In that perspective, all we need is :
Step 1 : Bring a JNI2 (inspired by both JNA and NLink) = can call direct native code without any C/C++. As long as you’ve granted some extra per class Permision.
Step 1 : Ease OpenJDK portability by making it as much as Java made of = remove all the no more required C/C++ and replace it with Java. Full SPI oriantation as to be done so that native code are only in system specific implementation of API. For each SPI, a full Java (even a dumb one has to be brought). At the end, only a small set of C++ (& dedicated assembler) should be there.
Step 2 : Now that OpenJDK is easier portable, help porting project to port to mobile OS (from WindowsCE, MobileOSX, Android … any mobile OS and then embeded OS should be targeted first).
Step 3 : Ensure that there is modules ready in the root repository for all the JavaME JSR that bring the same features to JavaSE. This make easy migrationpath for any existing application to SE.
Step 4 : Let’s have fun with a new revolution !
Comment by testman@spam.la — February 22, 2008 @ 2:54 am
@Steven “I think that push is the killer for these apps”
You can have push with browsing: for example, a SMS message w/ an embedded URL.
@mika is right.
@testman:
Same problem still occurs w.r.t. native functionality that may or not exist, and/or different ways to exposed those up to Java.
Comment by C. Enrique Ortiz — February 22, 2008 @ 8:56 am
In response to Enrique’s point: ABSOLUTELY.
SMS firing off something else is actually my ideal behavior. By “push,” I didn’t mean pure SMS (its ugly, and often hard to retrieve) but SMS-enabled experiences. In more generic words: push-initiated information consumptiuon.
My favorite is popping open a custom app, to present the info as prettily as possible, and allow other interactions (including browse-like behaviors). Of course, getting these apps on the phone, or getting cleanly to a browser with current SMS formatting is something else.
Comment by steven — February 22, 2008 @ 9:50 am