It's been a while since my last post. In a nutshell, I have been busy securing contracts and working on side projects. Every time I sat down to blog, something would get in the way. But to kick off my first post in a while, I thought I would talk about my adventures in JavaME programming. Here's the post in a sentence: JavaME makes the hard stuff about cell phones easy, but probably not easy enough for most Java programmers.
Ok, I might have just incurred some serious wrath with that last bit. But let me start by saying, I've been coding in Java for 10 years (I started with 1.0 and remember when 1.1 was such an incredible improvement
So going to JavaME is a blend of "Wow! I wrote an app for a cell phone!" and a lot of "Huh? I have to write that from scratch?"
Many Java programmers forget the true strength of Java; that is, Java got dynamic loading working easily and it included a vast set of standard classes and libraries with every JDK/JRE. You don't think about collections or sorting much in the Java world--you get these for free. You don't think about network programming or doing HTTP requests--you get these for free and you get so many layers of abstraction on top you almost never have to think about mime types and such. And you sure as heck don't worry about byte order or endian-ness.
JavaME is like the early Servlet APIs. It takes care of all the nasty bootstrapping and life-cycle stuff. But that's just about all it does. Anything more complicated or higher-level just isn't there yet. It gives you things like the RecordStore so you can save stuff between session, but then it only supports saving byte arrays. That shouldn't be a big deal, right? Well, for strings, no. You just get the byte array and save it. But what about longs and ints? I've seen some code that just converts them to strings and saves the resulting array (horrible! bad! evil!). What about saving a date? You don't what to save that as a String to byte array, and you don't have the fancy Date parsers you have in Java 1.4 and greater.
So when you start with JavaME and the examples, it is all very thrilling. But as soon as you try to build a midlet of significant size or functionality, you quickly realize there is a ton of stuff that is in JavaSE that just isn't there in JavaME. And it's up to you!
I don't see this as a huge problem. I get why it is this way. Just try developing for an old Nokia phone with a heap under 600k. There's barely enough room for the midlet to load, let alone strapping on all sorts of standard libraries. That's why the L in CLDC stands for Limited friends ;-) But it might be daunting to programmers who have never written their own serialization code (or who haven't done it for a while).
Also, there's no HTTP POST included with the standard toolkit. And that, my friends, was quite a shocker. Not that it wasn't there (there is so much not there), but that I couldn't find example POST code for a long time. No one does it anymore--just about every language out there supports form encoded POSTs out of the box through standard libraries. I had to dust off old books I almost had thrown out and google like mad. I was reading RFCs I hadn't read in 10 years.
But in the end, I thought that was a hoot. It felt good to be writing my own POST code. It felt good to write my own quick sort (I initially pulled it out of an old book only to realize the 10 year old book had errors in the code!). So I enjoyed myself. But I could see many not enjoying it.
In the end, I think JavaME is an emerging toolkit/standard. I fully expect JavaME development to be like slightly limited JavaSE development in the next 3 years. But in the meantime, I'll enjoy writing new toolkits and code for tasks I haven't had to think hard about for 10 years. In the end, it's what makes programming fun :-)
2007/03/30
JavaME: Back to the Future
Posted by
Matt
at
21:06
2
comments
Labels: JavaME, Mobile Phones, rsh tech
Subscribe to:
Posts (Atom)