Handling Different Browser Platforms - Beginning Android Web Apps Development - page 87

But what if you want the happy medium in the sense that your app should zoom in
automatically, but should also allow the user to modify the zoom if they so wish? And
what about devices that have a higher pixel count (such as the Google Nexus One, with
480px wide)? We can address this in a few ways. The first is to just remove the user-
scalable=no line in the META tag, and adjust the scale values targeted to a certain screen
density. This lets the META tag give the initial values, but doesn't constrain the user. To
determine if this is the right move, we can conduct a bit of user testing (i.e., surveys to
see what people think of our mobile interface) or if we really are curious, we could
implement some javascript code to see what users are doing and then write it to a log
(This is beyond the scope of this topic, although resources do exist, such as the
discussion on this page: http://htmldoodads.appspot.com/zoom-level.html ). We can
also build a page that displays differently depending on the device pixel density—
something that we would have to specify in the underlying CSS, using tags for low
density (ldpi), medium density (mdpi), and high density (hdpi), and then specifying
different CSS formatting for each situation.
Finally, if we have the luxury of developing for simply one platform (i.e., only Android
phones), we can look into specific features of the browser. In this case, the Android
Webkit browser reduces the size of text elements automatically so they fit on the screen
(go view an article in an online newspaper and zoom in on a wide block of text to see
this in action). If this is our usage scenario, then no META worries exist for us. While this
can be tempting to rely on, you should thoroughly test your page on an Android device.
It also doesn't hurt to use the META tags as an extra layer of security to help the built-in
browser.
The User Agent
Sometimes specifying what the browser should do with your page isn't enough for your
needs. For example, perhaps you know certain information, no matter how it's zoomed
or formatted on a mobile device, is just too much for the average user to handle on a
small screen. Maybe your page uses a bunch of Flash applets, which don't work on an
iOS device such as an iPhone or iPad, and you'd like to redirect those users somewhere
else. Maybe there are features and functionality available on your site that are not
available across all applications and would need to be disabled for less advanced
browsers. Finally, maybe you just want to give out one web address,
http://mysite.com , and have it automatically direct mobile phones and tablets to a
special optimized version, while showing everyone else the full page. The way most sites
accomplish these goals is by reading the user agent string, supplied by the visitor's web
browser. Let's first take a look at an example user agent, and then see how we use it in
our application.
The Nexus One User Agent
The format of a user agent string is codified by RFC 1945, the HTTP specification, which
includes the definition of this string. The string is made up of the product name and
version, and an optional comment. While those are the parts of the string required by