Posted on by & filed under Content - Highlights and Reviews, Mobile Development, Web Development.

I’m always amazed when I come across an app that doesn’t appear to take the platform it is running on into account. It’s slightly jarring to be thrust into an emulation of some other platform, and it forces me to make a context switch before I can start to use the app and understand how my actions will be understood.

Games are one thing, of course — they often come with their own user interfaces and conventions. But this is expected: they are about an experience custom created from the ground up, and immersion in that experience is critical. But apps that are for consuming media, getting things done, creating content, and so on, should use the platform to the best of their ability, and when an app pops up with some other OS’s skin, my expectations for how things work are suddenly thrown in the air.

With PhoneGap, it’s so easy to adjust the look and feel of your app to the platform that it is a shame that so many apps fail to do take advantage of it. Can you replicate the native environment perfectly? No, probably not – we’re running in what amounts to a web browser, and with that comes various restrictions imposed by not only the browser, but the operating system as well. But that doesn’t mean we can’t attempt to blend in a bit so that our users feel more comfortable.

PhoneGap, thankfully, makes it easy. We can use the device.platform property to target our code for the platform, but what might be a good way to do this for our look & feel, typically achieved by CSS?

All PhoneGap apps have some typical boilerplate code in the form of:

What if when our device was ready, we attached the value of device.platform to the BODY element in the document, like so:

Values of device.platform Corresponding Platform
iPhone Simulator
iPad Simulator
Android Android
WinCE Windows Phone 7.x

For both Android and WP7, it becomes easy to target any element with a specific look and feel:

For iOS, this is more problematic since the property reports the device we’re on, not simply the platform. You can get around this in one of two ways: by assuming the default look & feel is iOS, or by altering our code a little:

Now we can target iOS like this:

We can also target, to some degree, our form factor — iPad’s receive a somewhat different UI than an iPhone receives. Of course, with iOS, this is easy to determine — device.platform gives this value to us, but for Android, we need to look elsewhere. For me, I use the screen width to help determine if the app is on a tablet or on a phone.

Now we can target phones vs. tablets like this:

Now, it’s up to you whether or not 1024 pixels is wide enough or tall enough to classify the device as a tablet or not — right now this is quite common for 7″ Android tablets, but as DPI increases, this value is likely to increase as well. For now, this seems to work pretty well, and is what I use in my apps.

With this in effect, you can make some pretty drastic changes to your interface based upon your CSS alone. While it’s not always easy to change the look and feel of your app based on the platform, but your end users will thank you.

Safari Books Online has the content you need

Check out these Phonegap books available from Safari Books Online:

20 Recipes for Programming PhoneGap explores many common features of mobile development and how they are accomplished with PhoneGap. This will include GPS location, maps, media, accelerometer, and much more. PhoneGap is a library that allows developers to interface directly with a mobile device through the use of its Javascript libraries. With the multitude of mobile platforms it is very difficult and expensive to create multiple applications in Java, Objective-C, or other native languages. Through the PhoneGap library, most web developers can convert their existing knowledge of HTML, CSS, and Javascript into mobile phone applications with very little effort.
PhoneGap Beginner’s Guide shows you how to use the PhoneGap mobile development framework to target multiple mobile platforms: iOS, Android, BlackBerry, and more with a single application. With PhoneGap, you can use existing web development skills, instead of learning a new environment for every platform on the market.
Using HTML, CSS, and Javascript, PhoneGap allows you to jump into the mobile world and develop apps for iPhone, Android, and the BlackBerry, and Beginning PhoneGap will help show you how to best take advantage of PhoneGap.
Beginning PhoneGap: Mobile Web Framework for JavaScript and HTML5 is a definitive, one-of-a-kind book that teaches the fundamentals and strategies behind cross-platform mobile application development. Instead of learning languages like Objective-C, focus on building apps from day one for Android, iOS, Blackberry, WebOS and Symbian—without the complexities of these platforms.
Head First Mobile Web shows how to use the web tech- nology you’re already familiar with to make sites and apps that work on any device of any size. Put your JavaScript, CSS media query, and HTML5 skills to work, and then optimize your site to perform its best in the demanding mobile market.
Build Mobile Websites and Apps for Smart Devices provides practical, up to date information on all aspects of Mobile Web Development, using an easy to follow, tutorial style, with step-by-step instructions and clear examples.

About this author

Kerri Shotts has been programming since she learned BASIC on her Commodore 64. She earned her degree in Computer Science and has worked as a Test Engineer and Database Administrator. Now a Technology Consultant, she helps her clients with custom websites, apps (desktop and mobile), and more. When not at the computer, she enjoys photography and taking care of her aquariums.

Tags: android, CSS, iOS, iPad, iPhone, PhoneGap,

One Response to “PhoneGap Tip: Changing Look & Feel Based on the Platform”

  1. Are Nybakk


    I’m doing something similar (combined with CSS media queries), but I’m experiencing a rather huge delay after the HTML attribute is set until the UI actually respond (on Android). I’ve checked and it’s not the deviceready event that is late. Did you experience any such issue, and if you did, did you manage to solve it?