Developing software for a mobile phone is supposed to be a snap, especially when you use the Java2 Micro Edition (j2me). However, just a quick perusal at the sun or nokia development sites, you’ll quickly see that simple “one size fits all” solutions simply don’t exist. In fact, there is a well-coined phrase: “Write once, test many”, when it comes to mobile development. Even Google Maps for mobile devices (www.google.com/gmm) show that it has had to generate several flavours of the app to satisfy the differing manufacturers. Then when you add in the telcos themselves, each with their own set of enabling/disabling mechanisms designed to restrict users to their particular mobile plan, you quickly find that any mobile solution can be quite messy indeed.

What makes the problem even worse is some of the ‘helpful’ comments that one can find on the internet that relate to a particular problem: they never take into account all of the different flavours of manufacturers and telcos (as if they could). For me, the bane of my existance is the HttpConnection object. It is supposed to be a simple way for a j2me application to retrieve web pages and/or post up some results. Not so.

Each implementation appears to be sublty different, which has profound effects on the way a telco will then interact with the headers that are sent with the Http request.

From a developer’s standpoint, I can simply add new headers into the Http request simply by calling:

connection.setRequestProperty()

Unfortunately, by doing so this can inadvertantly add a duplicate header. Need I say that some telcos do not cope with duplicate headers well at all? To compound the problem, there is no way for me to verify that I have added a duplicate entry. The best one can do is to attempt to make a connection and then see what happens when j2me fires some java exception (such as IOException). To compound the problem, ASP.NET 2.0 has a set of filters that limit the type of html content returned. I am stymied everywere!!!

In short, if I specify:

connection.setRequestProperty(”Host”, “www.mysite.com”)

Some phones will add a duplicate header, some phones won’t. Some telcos are OK with having duplicate headers, some telcos are not. Failure to specify this may result in the request not actually making it to the server, especially if the server is a virtual server (ie one physical server that handles multiple dot coms on the same machine). Damned if i do, damned if I don’t.

If I specify:

connection.setRequestProperty(”User-Agent”, “Profile/MIDP-1.0 Configuration/CLDC-1.0″)

Again, I run into the dreaded duplicate header issue. By failing to specify a User-Agent (and/or a ‘Accepts’ header) string, some websites (eg those running ASP.NET) will return incorrectly formatted xHTML (and return the old ghastly WML format instead).

As such, it appears that I will be forced to create a suite of ‘tests’ that will run on a mobile device, each testing different Http header sequences, all in the vain attempt to connect to a simple website.

More will come later.

Note that for a CogStream solution we have found that it is actually best to use a raw TCP socket connection (by using SocketConnection). Again, there are also problems with this approach, namely that rather when we use a SocketConnection and mimic the complete HTTP request headers, we can’t use Port 80. This is because attempting to open a direct connection to some server on Port80 will bypass a telco’s and the phone’s security model. So, CogStream for a mobile phone needs to run on an alternate port altogether.