The topic of mobile phone development is a minefield of myths, false truths and misconceptions. In this post I will try to clear things up a bit as much as I can and also take a look at how to exploit geolocation from our mobile devices.
The Mobile Web
One of the most common misconceptions I come across is that there is no need for a website to adapt to a mobile device. The reasoning behind this idea is the fact that the internet is platform independent and that the browser should do the dirty work. When faced with such an argument I tend to respond with another: “If the website will not adapt to a mobile device, can that mobile device adapt to your website?” The typical response I get is: “Sure, why not? You might need to scroll a bit more but it looks fine.” Let’s set the screen resolution topic aside for a moment and consider the following example: Let’s say your website uses cascading menus which open up when the user hovers over them with the mouse. Let’s also say that we are going to browse the website using something like an iphone or similar multi-touch smartphone. Will that menu work? Can you “hover” over the menu using a touch screen? Not to my knowledge, so one of your more important features on your homepage is lost on a mobile device. And this is not some mobile phone from the late 90’s we’re talking about, but a latest-generation smartphone running a proper HTML browser. It’s not that the phone is not willing to adapt to the site, it simply can’t.
Screen resolution is another factor. I remember back at the beginning of my career as a developer (late 90’s) we had desktop machines that boasted an 800x600 screen resolution (1024x768 if you were lucky) while our end users only managed 640x480. It was company policy however that all the software we produced had to target 640x480, irrespective of what resolutions we were able to push. Today, the sheer variety of devices out there pushing all sorts of different resolutions is quite staggering and scary at the same time, but makes it even more important for developers to be aware of screen real estate and its effect on user experience.
Another myth I sometimes hear is that people are not using their mobile phones to browse the web. This might be true of people using ‘classic’ phones but it would be naïve (or rather stupid) to think that smartphone users (which are on the rise) aren’t. We as end-users still want to use the same websites we use on our desktop machines on our mobile devices, it’s the way we use them that’s different.
These are just a few considerations on why developing for mobile phones/devices should be treated differently. For a product to be successful, developers must be aware of the platform they are targeting, and let’s face it…
It’s a Jungle Out There
As mentioned earlier, the sheer variety of mobile devices available today is staggering and their capabilities are equally varied. The evolution of the mobile phone in particular is quite remarkable. The mobile phone started out as being just that, a phone which you could carry around and use anywhere you liked. We then had low-end mobile devices with very basic web support and limited memory. At this stage a mobile phone stopped being just a mobile phone and became a device. These were followed by devices that supported HTML and Java applications. Today’s smartphones are literally hand-held PC’s running fully fledged OS’s – my Android “phone” has a 1Ghz processor, half a gigabyte of RAM and 8Gb internal storage. I use it to browse the internet, check my email, run office apps and sometimes, even phone people up . The number of people using such devices is constantly on the rise and so the landscape of web development is rapidly changing. In some cases, mobile device browsers are better at handling cutting-edge HTML5 and CSS 3 features than their desktop counterparts for instance. Try http://www.html5test.com from your favorite desktop and mobile browsers, you might be surprised at the results!
If a web product is to be successful in this varied landscape, it is vital that the developers understand the targeted devices, not just at a software level, but even at the hardware level. What does the device support? What does it allow it’s users to do and how? I recently came across this article by Dan McKenzie that deals with how to go about designing for Android which is currently the most popular smartphone platform out there. Quite an interesting read.
We’ve seen some of the “limitations” brought by mobile devices, such as smaller screen real estate and no “hover” but it would be wrong to think that it’s all bad news. Mobile devices also bring to the table interesting and powerful features which are missing from their desktop counterparts. One of these features is geolocation.
Geolocation
Geolocation is one of those features that brings with it a whole range of possibilities for our web applications. Location-based services, geo-marketing, geo-tagging, geo-targeting and web analytics are just a few examples. Gelocation adds meaning to global positioning where rather than just a simple set of co-ordinates, your position is described in terms of street name and how far you are from the closest restaurant!
Your device can determine its position in various ways including GPS and, WiFi positioning and even through Cell information of your mobile phone network. One way of making use of this information is through the W3C Geolocation API, an effort by the W3C to standardize the way a mobile device retrieves positioning information.
So, how do we use this API? The first thing we need to determine is whether our browser supports it by querying the “navigator.geolocation” object:
If (navigator.geolocation==undefined) {
alert (“Your browser does not support Geolocation API”);
}
If the API is supported we can go ahead get our current location by calling the “getCurrentPosition” function. This is an asynchronous call which receives two callbacks, one for handling the returned position and another to handle any errors. You can also (optionally) specify additional properties to improve accuracy for instance. Here’s an example:
function pageLoaded(){ //this function is called from the body's onload event
if(navigator.geolocation==undefined){
document.getElementById("MSG").innerText = 'Geolocation is not supported';
} else {
document.getElementById("MSG").innerText = 'Geolocation is supported';
navigator.geolocation.getCurrentPosition(userLocated, locationError)
}
}
function userLocated(position)
{
var lat = position.coords.latitude;
var lon = position.coords.longitude;
var alt = position.coords.altitude;
var tim = position.timestamp;
// display the returned values on the page
document.getElementById("LAT").innerText = lat;
document.getElementById("LON").innerText = lon;
document.getElementById("ALT").innerText = alt
}
function locationError(error){
//handle error;
}
We can also use the W3C Geolocation API to track the device’s location. By tracking the location we can also determine other factors such as speed, distance and direction of movement which can be used by our application. Here’s an example:
var watchID = false;
function toggleTracking(){
if (watchID==false){
watchID = navigator.geolocation.watchPosition(userLocated, locationError);
document.getElementById("btn_trk").value = "Stop Tracking";
} else {
navigator.geolocation.clearWatch(watchID);
watchID = false;
document.getElementById("btn_trk").value = "Start Tracking";
}
}
To track the device's position, a call is made to the "watchPosition" method of the geolocation object which accepts two callback functions just like the "getCurrentPosition" method. "watchPosition" also returns an handler to the watch (watchId) which is used later to stop tracking by calling the "clearWatch" method.
I must confess that I had trouble testing the tracking function, especially while on foot. I tried creating a function that calculated the distance being travelled as well as the direction but could not test it very well as the response time was jerky at best. I admit that walking up and down the corridor of my house might be too small a distance for proper testing but it was the best I could do since I was editing javascript on my laptop and copying files to and from my mobile phone. I did register some position changes at times but it was sporadic and not enough to draw any conclusions. I have however installed a code editor on my mobile phone such that I can edit the code on the go. The plan is to test the code while travelling to work to see if I can get more encouraging results. I’ll also play around with the A-GPS settings to see what effect they have on accuracy. I’ll let you know how it goes.
Subscribe to email feed
