Handset manufacturers set a very low standard with their utter lack of consistency - take a brief skim through the WURFL if you need examples. In the end though even Samsung sticks to a core set of patterns you can latch on to, once you understand your SPH from your SGH.
Windows Mobile however sees things differently. From an application programmer's perspective, you probably need to find out a couple of key things about the device:
- Screen size - currently that can be 176x220, 240x240, 240x320, 320x240, 640x480, 480x640, 800x600 and probably a few other rehashes of those figures, which makes quite a difference to the graphics you send.
- Input device(s) - devices on the PocketPC side (now, inexplicably, Windows Mobile 6 'Professional') use touchscreens with a handful of keys, devices on the Smartphone ('Classic') use phone keypads.
Traditionally a Windows Mobile UA would look a little like this:
Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320)
Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; Smartphone; 176x220)
Both those useful bits of info I mentioned are immediately available from this UA, so the standard code that all mobile developers running deployment servers are cursed to rewrite can easily select the right content and send it out. It's not perfect - we are rarely told if a JVM is present (and it's rarely integrated well enough to do an in-browser OTA installation smoothly either), and we rarely get enough info to know whether to expect the screen rotation and the QWERTY keyboard, but enough basics are there to get us where we need to be.
Apparently, however, this is not good enough. For the sake of tidiness or somesuch, some idiot over at Microsoft decided to remove both the screensize and the core platform name from the UA as of Windows Mobile 6.0 because "Since the capabilities of the Pocket PC and Smartphone versions of the browser are identical, and they're built from the identical code base, there's no reason to differentiate them any more".
For web sites being browsed, arguably might be true (though optimising AJAX just got a bit harder if you don't know what will be clicking on your bits) - but for OTA deployments you just made things way harder. This is what happens when people decide it's safe to break backwards compatibility for the sake of "tidiness" without having any clue what the consequences are, and it really annoys me.
We do now have some extra headers giving the screen size etc, and yes it is possible to adapt deployment servers everywhere to handle this - costing many months of work across the world, because the many independent solutions to the mobile deployment problem that exist were all designed to sniff just the UA.
Apparently M$ "really appear to have got mobile with Crossbow" (sorry, can't remember which hack lifted that from a Microsoft PR bot) - I beg to differ. If they really got mobile they'd know people depended on these things and just leave them the hell alone, and while they were at it put a standard well-integrated JVM on the OS and ditch .Net Compact; I fail to see how (from a 'getting the mobile marketplace' point of view) some totally random non-standard environment can be totally core and yet a JVM could be seen as an optional extra for 3rd parties to worry about, but then that's politics.
Anyway, rant over. I shall resist the urge to go and explain that I would rather see the IEMobile Team's heads removed from their bodies because, hell, it won't affect my life and go back to preparing the two big posts I've been meaning to write for ages which will be loads more relevant and interesting than this one. Grrrr.