The Nokia N96

Just got my brand new toy. The Nokia N96, I honestly don't see the mass market appeal for such a device but I don't think I've felt this young in quite some time. This device is a whole lot of fun.

When I say fun, I don't mean this phone has a touch screen or a full keyboard, more fun like it supports live TV and has a PVR, a pretty damn good web browser, tons of codecs for all your media, good podcasting software, etc, etc. An unlocked version of this thing will set you back $800 USD. I have no idea what the target market for this device could possible be but I like it.

That being said, the N97, if not for the price tag, would be a much more serious product. Touch screen, full screen keyboard... and yes TV and PVR among other things.

Anyway, the N96 is a very good product, everything on this phone just works. The Java support is top notch with support for SVG based interfaces even which makes for some really interesting user interfaces. Again, however, budget conscious users might want to stay away here.

A video review is available here.

Microsoft SkyBox

The net is abuzz today about the rumored new user interface for Windows Mobile based devices. You can see some more information here.

However, that's not the major pain point when developing for Windows Mobile. Yes, the user interface is the major pain point for users when dealing with Windows Mobile but not for developers.

The real issue for developers is deployment. That's right, when developing for Windows Mobile, you have basically 3 options:

1. Java ME
   
2. .Net Compact
3. Native

Native is a pain due to the many different CPUs you'll encounter when dealing with Windows Mobile devices. Furthermore, many third party libraries just haven't been certified/tested on this platform. Here, I'm thinking mostly about Boost. Additionally, you'll either have the choice of using MFC or using the C Windows API. Just fun all around. Deploying a cabinet file for these devices if you can straigthen out all these issues is straight forward but getting there is a long road.

Java ME, when present, is usually the CLDC variant. Meaning it's a pain, it's light, missing many important classes, has pre-Java 5 syntax which means you can't use the majority of 3rd party libraries on it, open source or otherwise, and well, usually, not even loaded on the phone to begin with. Furthermore, if you don't have it on your phone, there isn't a convenient way to get it or upgrade it. What ships with the phone is what dies with the phone. Again, deploying a JAD file isn't terribly difficult, that is, if the phone has a Java VM to begin with and that Java VM is of decent quality. As it turns out, most Java VMs that ship on Windows Mobile aren't worth the bytes they fill up.

The last choice is .Net Compact. This one isn't too bad except for the fact that most phones don't ship a recent version of .Net Compact. Usually, you'll find .Net Compact 2 with no service packs, which is a total mess, or .Net Compact 1 ranging from service pack 3 to no service pack at all. The minimum that is actually usable is .Net Compact 2 SP2. So the problem you have now is upgrading .Net compact. The only official supported way of doing this is to download an MSI package to Vista/XP and the next time your phone connects to your PC, your desktop will upgrade your phone. Not very useful if you want to deliver applications on the show room floor.

So keep going Microsoft, keep going, and maybe someday you'll look back on this and say, what were we thinking?

Every Byte Counts

Well, it has been a while since I've posted anything. I've been really, really busy trying to figure out how to save every last byte that I can over the network for mobile applications. When all you have is an EDGE network, you really can't spare anything.

Here are some of my findings:

• Don't use SOAP. If you're going to use a standardized communication method, prefer REST to SOAP. Why? Because even if SOAP offers a lot of information in its message envelope that is very useful for implementing integrity, security, transactions and not to mention making it easy to orchestrate via an enterprise bus, it also happens to be much larger. Expressing a resource in REST will save you a lot of bytes.
• Another reason, is that REST isn't bound to XML like SOAP is. JSON is so much shorter than XML. Furthermore, most Java ME platforms have zero support for XML. To be fair, Java ME has zero support for JSON too. Support for both is readily available using 3rd party libraries however, again, the JSON library is much smaller than the XML one. Using JSON, not only do we get something that is more compact than XML, we don't lose any of the flexibility. You can express any XML construct in JSON, and just like XML, you can extend your JSON documents in the future with elements that can be ignored and parsed over by older clients.
• Gzip encoding is your friend. Mostly all HTTP servers support it, just add the "accept-encoding" header to your request. Needles to say, Java ME doesn't support gzip but once again 3rd party libraries are readily available
• Keep alive connections. HTTP 1.1 supports keep alive connections out of the box. What that means is that you can send one http request, read the response and instead of closing the socket connection, you can re-use it to send and receive additional requests and responses. This is also unsupported from Java ME, and no, to my knowledge, there are no 3rd party libraries available that support this. Fortunately, HTTP is a really simple protocol, you will need to forgo the use of the HttpConnection class and use a raw socket via the SocketConnection class. You just need to send well formed HTTP 1.1 requests to the server and you should be able to read responses just fine. This saves you the setup and tear down times associated with a full TCP socket connection every time you need to send a request. Please note however that you will need to support, at the very least, the "chunked" encoding since HTTP 1.1 compliant servers are free to use this encoding whenever they so choose.

However, most disappointingly, probably one of the best tool you can use to save bytes over the network is not available. I am talking about HTTP pipelining. HTTP pipelining as specified in version 1.1 of the protocol allows you to send many requests to the server on the same socket before you start reading any of the responses. Unfortunately, my server of choice, Glassfish, has no support for it. If Glassfish has no support, most certainly no Java EE container does either. The HTTP parser found in Glassfish is none other than Tomcat's Catalina engine. Since Catalina is used verbatim in almost every Java EE container out there, then that's it.

Most unfortunately, the Grizzly project team members have decided that HTTP pipelining is not a mandatory or important feature of HTTP 1.1 since the browsers don't enable it by default. Grizzly is the HTTP server used inside Glassfish and fronts the Catalina engine in Glassfish instead of Tomcat's own Coyote server. I disagree with this conclusion. I think this W3C document states that pipelining is indeed mandatory.

I would love to hear from someone with Jetty experience here if this feature is supported or not. I use many Java EE 5 features that would make the transition to Jetty impossible but the Apache Geronimo project does feature a certified Java EE 5 server built around Jetty.

Finally, if anyone would like to suggest more ways to save bytes in a portable manner, please feel free to comment.