Our content on demand download service is done, the test having gone well are giving us quite the problem on the Nokia Nseries. The damned phone cannot seem to decide which connection profile to use! Am sure it must be a teeny wheeny thin on our end and not the phones end. but it is hot, its been a long day, and frankly I am tired.Its possible…it will be done…just not today.
Ensuring a user downloads the correct Java ME application version for their phone type isn’t an easy procedure. There are a number of ways to get there but the usual process ends up with the user at a WAP site where some type of device profiling must occur. Device profiling must happen because the Java ecosystem doesn’t have a one size fits all convention. In order to cover the highest percentage of handsets developers must take into account screen size variations and Java framework implementation inconsistencies. This results in a significant number of different JAR versions of the same application.
The profiling process can be quite tricky but it is usually possible due to information provided to the server in the headers of the message sent from the browser making the request. Unfortunately third party browsers (NetFront, Opera Mobile & Opera Mini) do no stick to the conventions implemented by native browsers and it makes it very difficult for developers to determine which type of device is making the request. I would say that the problems in profiling a device when a user access the server from a third party browser are so bad it might be better to consider asking them to use the native browser instead. Google and Yahoo! mobile portals tend to treat these browsers as desktop rather than mobile browsers becuase of these problems.
To demonstrate my point check out the user agent headers (definition below) of different browsers found on the same Nokia N70 device:
Default Nokia N70 Browser:
NokiaN70-1/5.0609.2.0.1 Series60/2.8 Profile/MIDP-2.0 Configuration/CLDC-1.1
Mozilla/4.0 (compatible; MSIE 6.0; Symbian OS; Nokia N70/5.0609.2.0.1; 9399) Opera 8.65 [en]
Opera/8.01 (J2ME/MIDP; Opera Mini/2.0.4509/1378; en; U; ssr)
Mozilla/4.08 (SmartPhone; Symbian OS-Series60/1.03) NetFront/3.3
Of the three 3rd party browsers only one declares MIDP support in the user agent (this is one of the main ways of determining if the phone supports Java ME applications). Of the three only one passes across the make and model of the phone. Not one of the three communicates the “x-wap-profile” attribute in their headers (explanation below). All three change the accept headers of the device, removing any reference to Java ME support. On top of that version 8.65 of Opera Mobile seems to have a bug when it comes to downloading Java ME applications.
Frustration upon frustration! These browsers make it virtually impossible to determine what type of device they are installed on and therefore very difficult to correctly provision Java ME applications. Anyone building a robust and comprehensive profiling and provisioning platform will have to take these discrepancies into account but it’s no walk in the park! These problems probably also apply to the provisioning of other assets like video and audio services where the type of device making the request is important.
Definition of User Agent:
A hidden piece of information sent in the HTTP message headers identifying the browser or agent accessing a WAP or web page on a server.
Explanation of “x-wap-profile” attribute:
The “x-wap-profile” attribute in the HTTP message headers is a URL which points to a XML file that has detailed information about the device.
Definition of Accept Headers:
The accept headers usually tell the server what type of content types/media the device and browser can support.
Let me sleep on this….