Updated: Added Support for BlackBerry OS 6

August 4, 2010 at 12:33 am · Filed under Code Updates

BlackBerry launched the new Torch on August 3, the first device running the new OS 6 with a brand new WebKit-based browser. At last! A first class browser finally makes it to the BlackBerry platform!

Word on the street is that the new OS 6 WebKit browser is in the iPhone class. So, optimistically, we updated the MobileESP code with the following updates.

  • DetectBlackBerryWebKit(): Added a new method to detect for BlackBerry OS 6 devices.
  • DetectBlackBerryTouch(): Added detection for the Torch device.
  • DetectBlackBerryHigh(): Updated to explicitly exclude BlackBerry OS 6 devices. This method is reserved for devices with a “highly capable” OS 5 browser.
  • DetectTierIphone(): Updated to include detection for the new BlackBerry OS 6 method.

This is the useragent string that BlackBerry announced for the new Torch device:

Mozilla/5.0 (BlackBerry; U; BlackBerry 9800; en) AppleWebKit/534.1+ (KHTML, Like Gecko) Version/6.0.0.141 Mobile Safari/534.1+

Comments (2)

Updated: Added Support for Windows Phone 7

July 19, 2010 at 12:20 pm · Filed under General

I recently got my hands on the Windows Phone 7 SDK from Microsoft. The browser in the device emulator appears to support most or all of the CSS and JavaScript features you would expect for an iPhone Tier device. (The iPhone Tier devices include the iPhone, naturally, but also the native browsers for Android, WebOS and a few others.)

So now seemed like a good time for a preliminary update of the MobileESP code to support Windows Phone 7!

Here is a list of code updates to support Windows Phone 7 device detection. The code bases for each of the platforms have been updated using the same API signatures.

  • deviceWinPhone7: New field for storing a useragent string unique to Windows Phone 7.
  • DetectWindowsPhone7(): New method for detecting a Windows Phone 7 device.
  • DetectWindowsMobile(): Modified to disambiguate Windows Phone 7 devices from Windows Mobile 6.xx and earlier devices. This method excludes Windows Phone 7 due to the significant gap in capabilities between the 6.xx and 7 versions.
  • DetectSmartphone(): Updated to include Windows Phone 7.
  • DetectTierIphone(): Updated to include Windows Phone 7.

Comments

How To: PHP – Enable Features for Specific Devices

June 29, 2010 at 11:25 pm · Filed under How To - PHP

Here’s another quick example on how to use MobileESP project code to optimize your web site.

Let’s say that you have a single web page optimized for all iPhone Tier devices. This tier of devices includes iPhone, iPod Touch, Android, WebOS, and Windows Phone 7. And on this web page, you want to show a link to the respective app download page for each device. In other words, you only want to show the link to download the iPhone app for iPhone & iPod Touch devices, only show the Android download link to Android devices, and so on. Here’s how you’d do it.

In the page header, include the MobileESP project code:

<head>
<?php
include("/folder/mdetect.php");
//Instantiate the object to do our testing with.
$uagent_obj = new uagent_info();

You may also want to save some variables that you can reuse in multiple places on the page. For example:

//Detect methods return 1 for true, 0 for false
$isIphoneIpod = $uagent_obj->DetectIphoneOrIpod(); //Check for both!
$isAndroid = $uagent_obj->DetectAndroid();
$isWebOS = $uagent_obj->DetectPalmWebOS();

Now, further down the HTML in the Body section, you might use logic like this to show the appropriate mobile app download link:

<?php
//Print the variable part of the URL to the HTML source
if ($isIphoneIpod == 1) {
print( "<p><a href=\"http://www.mysite.com/download/iphone.htm\">" ); }
else if ($isAndroid == 1) {
print( "<p><a href=\"http://www.mysite.com/download/android.htm\">" ); }
else if ($isWebOS == 1) {
print( "<p><a href=\"http://www.mysite.com/download/webos.htm\">" ); }
//Print the remainder of the sentence
print( "Download our app today!</a></p>");
?>

That’s it!

Comments (3)

How To: PHP Redirects

June 29, 2010 at 10:57 pm · Filed under How To - PHP

We get a lot of questions about using the MobileESP project code in practice. Here’s one example on how to redirect browser traffic to optimized content.

In this scenario, we put a PHP file in the root of a web site (for example, wwww.yoursite.com/index.php), but it could be any folder or any page, as well. To keep this scenario simple, we redirect all traffic like so:

  1. iPhone Tier devices and iPads: Redirect to www.yoursite.com/i/
  2. Rich CSS devices: Redirect to www.yoursite.com/r/
  3. Generic mobile devices: redirect to www.yoursite.com/m/
  4. Desktop browsers and all others: www.yoursite.com/d/

So this is how we would write the code to achieve these goals within the index.php file. This would be the complete contents of the file:

<?php
include("/folder/mdetect.php");
//Instantiate the object to do our testing with.
$uagent_obj = new uagent_info();
//Detect iPhone Tier and iPads...
if (($uagent_obj->DetectTierIphone() == $uagent_obj->true) ||
($uagent_obj->DetectIpad() == $uagent_obj->true)
   { header('Location: http://www.yoursite.com/i/'); }
//Detect Rich CSS Tier...
else if ($uagent_obj->DetectTierRichCss() == $uagent_obj->true)
   { header('Location: http://www.yoursite.com/r/'); }
//Detect All Other Mobile Devices...
else if ($uagent_obj->DetectTierOtherPhones() == $uagent_obj->true)
   { header('Location: http://www.yoursite.com/m/'); }
//Else it's a regular PC browser -- send to regular desktop site
else
   { header('Location: http://www.yoursite.com/d/'); }
?>

That’s pretty much it! This basic strategy can be used in many ways in addition to redirects.

Comments (1)

MobileESP APIs Published!

June 7, 2010 at 12:12 am · Filed under MobileESP APIs

Just a quick note that I published the complete list of device detection methods for easier perusal.

One page is focused on the server-side programming languages for PHP, Java and ASP.NET. The other page lists the methods for the JavaScript API — with the heavy caveat that JavaScript support is very poor among mobile devices in general.

Enjoy!

Comments

Updated: Better iPad Handling, Improved Windows Mobile Detection

May 8, 2010 at 7:00 pm · Filed under Code Updates

I just uploaded the code bases for the following issues:

  • In the DetectIphone() method, added a call so that the Apple iPad does not provide a false positive. (We also do this so that iPod Touches don’t report themselves as iPhones.)
  • In the QuickMobile() method, added a call for the iPad so that iPads do not report as TRUE. Why do this? Instead, if you want to provide a special UI design for iPads (such as special layouts or to remove Flash), then make an explicit call using the new DetectIpad() method. Otherwise, let the iPad visitors get your regular web site rather than a site optimized for a small mobile phone’s screen.
  • In the DetectWindowsMobile() method, added some new calls. One call checks for “ppc”, which is an indicator of Windows Mobile Professional (aka PocketPC) and is often the only clue for many such devices. The other call looks for both “HTC” and “Windows”. Many HTC Windows Mobile Professional devices try to pass for regular PCs, so this seems to be the best technique for sniffing (most of) them out.

I’ve already uploaded the code to the Google code repository. Please let me know if you spot any bugs!

UPDATED (June 6, 2010): Thanks to Tony, we discovered that the initial enhancement to detect PocketPC (“PPC”) in the DetectWindowsMobile() method also accidentally caught Macintosh PowerPC browsers. So I did a quick update today based on the suggestions which ought to hopefully disambiguate the desktop Macs.

Comments (10)

Best Practices in Mobile Web Site Access

May 8, 2010 at 6:48 pm · Filed under Mobile Web Site Design

Designing mobile-optimized web sites is hard enough. Imagine spending all of that time and money building a fantastic mobile-optimized web site — only to discover that no one actually visits the site because they can’t find it.

Experienced mobile web users have learned to expect that major web sites also have mobile versions. Unfortunately, the major mobile web sites use a handful of conventions for providing access to the mobile-optimized version of their sites. Some sites offer “m.mycompany.com” while others use “mycompany.com/wap” among many other variations.

So what is the best practice for supporting all of these different mobile web site address conventions? Support all of them, of course! Don’t turn away mobile traffic unnecessarily (nor the juicy mobile advertising dollars, if your site is ad supported). Best yet — it’s easy to do and ought to take only a few minutes’ of your tech team’s time. (Okay, maybe as long as an hour…)

Directory Structure

At Hand Interactive, all mobile-optimized web pages are saved in the “m” directory. So our mobile-optimized home page is actually:

www.hand-interactive.com/m/index.htm

Virtual Sub-Domains & Directories

It doesn’t matter too much where your content lives, whether it’s the “m” directory, “wap”, “mobile”, “foo” or whatever. What does matter is whether your users can find your mobile content.

So this is where you need to take the smart approach and re-direct the short list of easily “guessable” domains and directories to your mobile content’s real home.

We recommend that you enable the following addresses and redirect them to your mobile content. Click on the links to see them work with Hand Interactive’s own web site.

iPhone-Specific Sub-Domains & Directories

There are a growing number of companies offering content that has been optimized for display on the iPhone (plus iPod Touch, Android, Palm WebOS, etc. etc.). As with generic mobile web addresses, there appears to be one of several approaches to web naming that companies follow.

We don’t currently have any iPhone-specific content, but if we did, we would store it in the “i” directory. Until we do, we redirect the following sub-domains and directories to our regular mobile content directory (/m):

Summary

In summary, the best practice is to support all of the obvious sub-domains (like wap.mycompany.com) and directories (like www.mycompany.com/wap) and redirect them to the real location for your mobile content.

(This article is re-posted from the original source on Hand Interactive.)

Comments (1)

Developer Guide Series: How should I divide up the world of mobiles?

May 8, 2010 at 6:31 pm · Filed under Mobile Web Site Design

Here are  a few quick recommendations for dividing up the mobile world online. You can use the FREE open source MobileESP mobile device detection code to help you optimize your web experiences.

OVERVIEW

In general, I recommend having two versions of each web page. They can offer the same news, articles, and other content, but the UIs (especially around page layouts, navigation and search) may vary considerably between them.

  • One mobile site should be optimized for iPhone, Android, WebOS and other “iPhone Tier” devices.  These devices can display rich CSS (with CSS-driven layouts, colors, buttons, input fields, etc.) and handle rich JavaScript (such as sliding drawers, thumbnail image marquees, smart CSS-coded”popoups”, etc.). Use the DetectTierIphone() method to detect these.
  • The other mobile site is for all other mobile devices, including smartphone devices with poor CSS and/or JavaScript capabilities (Nokia S60, BlackBerry, Windows Mobile) and the long list of mass market “feature phone” devices with small screens and limited browsers. (Think the Motorola RAZR, LG Dare, and anything else you can get free on a plan nowadays.) Use the DetectTierRichCss() and DetectTierOtherPhones() to detect these.

RICH CSS DEVICES

A quick note on what I call “Rich CSS devices.” If you’re really fancy, you could show the iPhone version of the page to Rich CSS devices (like BlackBerries and Nokia phones), but there are… a few issues with such a plan.

First, the Rich CSS class devices often display CSS acceptably if you are willing to make many compromises in your design. Plus, since these devices can’t reliably use JavaScript (or for some like BlackBerries, not at all), you would have to disable JavaScript features on these pages. So, unless you have a very compelling reason to go through such pain, I recommend simply offering these devices your general mobile-oriented pages.

Look at it this way: Why cripple the experience for your iPhone and Android users just so a few Nokia and BlackBerry users can see a prettier-but-crippled web page?

OPTIMIZATIONS FOR IPHONE THAT OTHER DEVICES CAN USE — OR GRACEFULLY IGNORE

As you may have heard, the iPhone has some extra smarts built into the browser. When you optimize your web site for the “iPhone Tier” of devices, the good news is that some of these features can also be used by other devices since most of them share the WebKit-based browser engine. Whatever the other devices can’t use, they will simply ignore silently and without causing error popups. Of course, I’m hoping that other devices pick up some of these unsupported features soon-ish. But in the meantime, don’t leave these out!

<HEAD> Section

  • Optimize the Viewport for Mobile Screenwidths: <meta name=”viewport” content=”width=device-width, user-scalable=no”> (Alternatively, you could turn on scaling, if you prefer. Helps ensure content is re-laid out when the user rotates touchscreen devices.)
  • Set the Favicon: <link rel=”shortcut icon” type=”image/x-icon” href=”images/favicon.ico”> (Some mobile browsers store the favicon for the bookmarks list, too. Not used by iPhone.)
  • iPhone Home Screen Icon Image: <link rel=”apple-touch-icon” href=”images/apple-touch-icon.png”> (The icon needs to be 57 x 57 pixels.)
  • Run a Web Page in Full Screen Mode: <meta name=”apple-mobile-web-app-capable” content=”yes”>
  • Content is Mobile-Optimized: <meta name=”HandheldFriendly” content=”true” /> (De fact standard, not used by iPhone. Tells search engines and mobile browsers the content is mobile friendly.)

CSS Styling

  • Input Field Virtual Keyboard Optimization: Tell the device’s virtual keyboard if the input field is for general text entry, an email address (<input type=”email” />), a telephone number (type=”number”) or a web address (type=”email”). Supported by the iPhone; other mobile browsers ignore these hints for now and default to plain text. [View article]
  • Input Field – Turn On Auto-correction and Auto-capitalization: Sometimes you want these features on and sometimes you don’t. For example, you explicitly want them off in an email input field. Or you might want them on in a site-wide search input field. Here’s how: <input type=text autocorrect=”on” autocapitalize=”on” /> (Seems to be iPhone only)
  • Input Field – Show ‘Watermark Hint’ Text: Show the label in the input field or an instructional hint such as “Enter search” which is shown only in an empty input field. Here’s how: <input type=text placeholder=”Enter search” /> (Seems to be iPhone plus some desktop browsers. You might consider a fancy JavaScript technique for clearing the field for non-iPhone devices on focus if the text in the input field matches the placeholder value.) 
  • Rounded Corners: Don’t use clumsy images to give your boxes rounded corners! Instead, use CSS. All of the iPhone Tier devices can use the “-webkit-border-radius” and related CSS hints, so please use them!
  • CSS3 No-Image Buttons: There are multiple techniques available for displaying custom buttons without using background images. They look great on the iPhone Tier device browsers.
  • iPhone Animations: Mobile CSS/JavaScript toolkits like jqTouch are great and can include cool iPhone-specific animations — which don’t work on other devices. So be sure to turn them on only for iPhone devices. (For example, by putting animations in a separate CSS file that you dynamically load only for iPhone devices. Use the DetectIphoneOrIpod() method in MobileESP.)

Comments (2)

Updated: Detect iPad & Amazon Kindle

April 7, 2010 at 11:14 pm · Filed under Code Updates

I just updated the code to include detection methods for:

  • Apple iPad: Useful to know so that you can replace Flash content with content formatted using HTML5 or CSS/JS. You might even develop a special web site optimized for its display and new UI conventions.
  • Amazon Kindle: This device includes a browser, even though its eInk display is pretty much just black & white (and gray).

P.S. -

Thanks, Pieter V., for the bug review of the Java version of the code!

Comments (3)

Introducing the MobileESP Project!

January 2, 2010 at 5:00 pm · Filed under General

Don’t you wish there were an easy way to detect whether your web site visitor is connecting with a desktop PC or a mobile device of some sort? When you install the FREE MobileESP source code on your web site, it’s easy to integrate mobile device detection so you can offer, for example, an iPhone optimized version for modern touchscreen devices (including Android & WebOS) and/or a leaner, faster-loading site without Flash, AJAX, or fancy JavaScript for the widest array of mobile devices.

The MobileESP project seeks to provide web site developers an easy-to-use and lightweight API for detecting whether visitors are using a mobile device, and if so, what kind. The APIs provide simple boolean results for popular individual device OS categories (such as iPhone, BlackBerry, Symbian S60, and Windows Mobile), device capabilities (e.g., J2ME), and broad classes of devices, such as “iPhone Tier” (iPhone/Android/WebOS) and smartphones.

This project maintains and extends the original code created by Anthony Hand of Hand Interactive ( http://www.hand-interactive.com ). The code library has been ported to: PHP, Java, and APS.NET (C#) for server-side detection, and JavaScript for more limited client-side detection. The APIs are designed to be consistent across code languages.

The MobileESP project is easy to use, install, and customize. This project is not meant to replace other projects offering greater specificity and control, such as WURFL or HandsetDetection.com.

For the latest source code, please visit the Google Code site which hosts the code repository:

http://code.google.com/p/mobileesp/

Comments