Mobile Fun
 |
The internet is gaining momentum where mobiles are concerned. As modern technology continues to proliferate our everyday lives, a new requirement has come to light, being mobile. |
This allows us to check stock rates, email or even website statistics whilst on the move. Today I’d like to discuss the perils and some solutions to the new Wild Wild West of mobi site development. We all know that mobiles suffer from a condition called “Device Fragmentation”, this term can be found throughout the article and has to do with how handsets differ from eachother on some fundamental levels.
With mobile flexibility comes great pain though what developers call ‘Device fragmentation’. This term is the source of many woes for developers, essentially it means that what works on one mobile, might not necessarily work on another, for example, an iPhone will handle ajax requests out of the box, whereas 8000 model Blackberries have javascript functionality, but it isn’t activated out of the box. To further our troubles, images are scaled uniquely per mobile, which doesn’t always give the desired effect (a solution is discussed under the Images section).
Device Detection
One can opt for open source device data, like WURFL (Wurfl is an xml file that stores the device capabilities for most mobile phones on the market), which is a great idea … in concept, but in practice is something completely different in the sense that WURFL isn’t 100% accurate on device screen dimensions, which in turn will affect the image rendering (as mentioned in images). Solution one would be to update the WURFL database with the proper dimensions, which would work, but is a time consuming task, as there’s over 4000 WURFL mobile handset types out on the market. A second option would be to opt for a pay solution like www.handsetdetection.com which is a pay web service that allows an application to know what a mobile’s screen dimensions, supported image types and javascript capabilities are. The pro of going this approach is that you’re leaving the headache of device details to the professionals, leaving you to concentrate on the core system functionality.
Images
We love them, they colour in the world. It should really be a piece of cake to implement images on mobiles right? Wrong, they actually pose a very big peril with regards to look and feel, as images are scaled differently, depending on screen real-estate. In other words, it’s scaling based on the height and width of the handset, uniquely. We can overcome this problem by resizing images on the fly, via application code, with the proper dimensions of the handset . Next up is device fragmentation on a device level , even image types aren’t safe, as some handsets support Gif, Png or Jpeg’s respectively. This adds another operation that needs to be performed : Converting the image type to the correct type that will be accepted by the specific handset.
Javascript
Javascript is a very big part of modern sites, one would imagine that mobiles would cater for this out of the box. Which isn’t true, Blackberries for example ship with javascript support, but it’s disabled out of the box, on some handsets. Blackberries are an internal part of the business world and if you wish to target the business world, then this will need to be addressed. The best way to do this is to keep the site as simple as possible, the less moving parts, the more likely that you will be able to target a wider audience.
CSS
A wonderful tool to use, for look and feel, is CSS. This allows a mobile browser to scale down gracefully, without compromising on looks. If targeting multiple diverse handsets is your goal, then multiple CSS templates would be required, one catering for each handset respectively. Font sizes differ per handset for example, depending on screen real-estate, so one should specify font sizes per handset in the CSS file.
Emulators
Run once, test everywhere is the keyword here. Quite a few services are out there to facilitate the testing of mobi sites / Java applications on desktop / web emulators. Desktop emulators, I feel, are a bit more surefire than using a Web emulator. As they function on code specifically designed for the handset and not on a web browser that’s skinned to look like a mobile handset. In essence it’s more accurate on a desktop emulator, BUT unfortunately due to Operating System differences, it’s still got a way to go. I’ve found that what looks great on the emulator, will look different on the physical handset, in minute but crucial details. For example, buttons can be styled to look round on the handset, but when tested on the emulator it will display as a square block.
Usability
A lot of people might be tempted to go for the easy solution, to “mobify” their site with a mobile metamorphosis system, in the sense that it converts their live site’s pages into mobile friendly pages. This could definitely work, as it takes a lot of development time out of the picture, the problem is that we run into device fragmentation again, some might support Javascript, some handset’s fonts will be painfully small etc. To overcome this paradigm, I propose the use of a MVC ( Model, View ,Controller ) framework, where each View ( the Html + CSS + Javascript ) is separate per targeted handset and thus caters for that mobile’s capabilities. The Code ( Model + View ) is thus separated from the View, which allows us to run the application logic separately from what is presented to the browser, so essentially one codebase can run multiple interfaces and will in turn, lessen the Development time.
Conclusion
In conclusion, alot of people might be tempted to think that a mobi site is a trivial matter to address, I hope this article has been enlightening and made you aware of some pitfalls.
I am Johan Badenhorst, a proud member of Virtuosa’s Development team.