The MobileESP Project: Easily detect mobile web site visitors

Hi, folks –

As MobileESP has added new methods and variables, I’ve been more & more concerned with the potential for API collisions with other JavaScripts that may be present on the page. So I decided to work on converting the standard JavaScript code into an Object Oriented model using the literal notation technique. Since I had to touch each function anyways, I decided it was time for a deep review of the JavaScript code, as well. Simultaneously, I drafted a list of test useragent strings and tested each one against our new UA test list.

Download: OOP JavaScript Beta 1 (July 22, 2012)

REGULAR JAVASCRIPT METHOD

In the normal JavaScript method, this is how you would include and use the code to test for iPhone Tier devices (including Android and Windows Phone 7). Notice how the JS function call is available as if it had been defined on the same page.

//In the Header, load the file:

<script type=”text/javascript” src=”code/mdetect.js”></script>

<script type=”text/javascript” language=”JavaScript”>

if (DetectTierIphone())

//Do something interesting, like redirect to a mobile page

//or promote the link to the iOS app store.

</script>

OOP JAVASCRIPT METHOD

Using this OOP method, all function calls and interesting variables are accessed within a new object called “MobileEsp.” So, only one line needs to change as we add “MobileEsp.” to the function call:

//Do the stuff listed above…

if (MobileEsp.DetectTierIphone())

//Do something interesting

CHANGE LOG

In addition, I made numerous tweaks and updates to the JavaScript code. If the JavaScript switch to the OOP model is well accepted by the community, and any bugs get fixed, then I’ll start porting these tweaks and updates to the other libraries. A few people have sent in a few other requests for coding changes (especially to PHP), which I’ll also try to get in. Here are some highlights of the JavaScript updates:

• Added global variables for quick access to these very useful Boolean values: IsWebkit, IsMobilePhone, IsIphone, IsAndroid, IsAndroidPhone, IsTierTablet, IsTierIphone, IsTierRichCss, IsTierGenericMobile
• Simplified OperaMobile().
• Moved the following from DetectMobileQuick() to DetectMobileLong(): DetectDangerHiptop(), DetectMaemoTablet(), DetectGarminNuvifone(), devicePda.
• Added DetectBada(). Added it to DetectSmartphone & iPhone Tier, too.

BETA TEST FEEDBACK

Please review & test the proposed code for the new OOP JavaScript object and its many tweaks and updates. Please send feedback to me (Anthony) no later than Friday, August 10, 2012. I’d like to be able to incorporate all of the feedback and publish an official switch to OOP by the end of August.

Thank you for your continued support of MobileESP, your energies, and your ideas on how to make it better for the entire community!!!

Anthony

(anthony.hand [at] gmail [dot] com)

Hi, folks –

The 2 flavors of the ASP.NET code library were updated with two issues specific to that code base. The updates are now live on Google Code.

• The starting quote was missing for the vndRIM variable’s value.
• Removed the class statement, “using System.Linq.” The Linq API wasn’t actually used. Removing the Linq statement gives us an added bonus: compatibility for the ASP.NET code now drops from .NET 4.0 to .NET 2.0.

Many thanks to Brian W. for pointing out these issues and their solutions!

- Anthony

Hi, folks –

Thanks to some questions from Dave M., we realized that MobileESP had inconsistent support for detecting the Amazon Kindle e-Ink devices as mobile devices, plus, they were also reporting “true” as Rich CSS Tier devices (which they are not). In addition, MobileESP had no support for detecting the Amazon Kindle Fire devices in Silk browser acceleration mode, which uses a different useragent string.

We updated the MobileESP code bases twice today. The first was to standardize support for detection of the Kindle e-Ink device. Then we remembered that we had wanted to also add support for detecting the Silk browser acceleration, so we updated all of the libraries a second time to add the Silk browser support.

Here is the specific list of updates which affects the following libraries: PHP, JavaScript, Java, ASP.NET (both variants), and Python.

• Updated DetectRichCSS(): Excluded e-Ink Kindle devices, which all run black and white displays.
• Created DetectAmazonSilk(): Created to detect Kindle Fire devices in Silk mode.
• Updated DetectMobileQuick(): Updated to include e-Ink Kindle devices and the Kindle Fire in Silk mode.

Open Issue: Currently, the Android-based Kindle Fire browser is detected as a Rich CSS Tier device when in Silk mode. When Silk mode is off (i.e., normal Android browsing mode), then the device is currently reporting itself as an Android phone. (This is common behavior for 7″ Android tablets.) We’re not sure that this is the best strategy for Silk mode — should Silk mode be in the Rich CSS or basic mobile device category alongside feature phones? Please let us know your feedback.

As always, if you’d like updates on MobileESP, subscribe to the changes log on Google Code.

- Anthony

Hi, folks –

A quick update to the code libraries today.

ALL LIBRARIES: PHP, JavaScript, Java, ASP.NET (both), Python

Added support for the BlackBerry Curve Touch 9380. It’s a new monoblock all-touchscreen device from BlackBerry and is a little smaller than a Storm. Because the screen is (reasonably) large and it lacks a keyboard, we decided to add support to it to the DetectBlackBerryTouch() method. (Special thanks to Robert P. for bringing the recent launch of this device to our attention.)

PHP Bug Fix

Fixed a bug in the DetectKindle() method. The call to DetectAndroid() needed the class identifier (“this”). (Special thanks to the several people who wrote in about this one.)

Python Bug Fix

In adding support for the Curve Touch to the DetectBlackBerryTouch() method, we noticed a copy & paste error in the code. All of the existing lines of code were looking for the Storm device only. Oops! So we added in support for all necessary devices: Storm, Torch, Bold Touch and Curve Touch.

All libraries have been updated in the Google Code project and are available for download now.

- Anthony

Hi, folks –

The community has delivered another great port of MobileESP! Jury Gerasimov sent me an email last week with the good news.

Jury’s company in Irkutsk, Russia, (that’s one of the largest cities in Siberia!) has been developing a bus monitoring service. The web site was built in Python for the Django web app framework. In Jury’s own words:

We’ve made 3 versions of the web interface – desktop, modern mobile and old mobile – available on the same URL. To detect which version the server should display, we needed some server-side script, and MobileESP has the most usable set of functions among other solutions. Our main developers were quite busy, so Python translation was made by freelance guy. He knew the code will be opened so kept the structure and comments close to original.

Check out the mobile version of their bus tracking web app: www.irk.fm/bus/ (Note that the web site is in Russian naturally.)

For you Python lovers, here is the sample code they used to integrate MobileESP in Django. It looks pretty simple…

  from mobileesp import mdetect

  user_agent = request.META.get("HTTP_USER_AGENT")
  http_accept = request.META.get("HTTP_ACCEPT")
  if user_agent and http_accept:
       agent = mdetect.UAgentInfo(userAgent=user_agent, httpAccept=http_accept)
       #Do first! For iPhone, Android, Windows Phone 7, etc.
       if agent.detectTierIphone():
           HttpResponseRedirect('/myapp/i/')
       #Then catch all other mobile devices
       if agent.detectMobileQuick():
           HttpResponseRedirect('/myapp/m/')
  #For traditional computers and tablets (iPad, Android, etc.)
  return HttpResponseRedirect('/myapp/d/')  

Moving forward, we will be hosting the Python codebase in the MobileESP project on Google Code. (See the Download Page for details.) Jury and his team will assist in reviewing and testing updates.

For more information about the Python port or to contact Jury for more information about his company’s services, please email Jury directly: jury@softshape.com.

Cheers,

Anthony

Hi, folks –

Doug D. contributed some performance enhancements updates for the two ASP.NET variations of MobileESP. Here is a summary of changes:

• Variables: Converted the private member strings to constants for faster object creation.
• Removed unused property: deviceXoom.
• Wrote member strings in UPPERCASE rather than calling the ToUpper() on each one.
• Added a note to OnInit() that one may optionally override InitializeCulture() instead so that the mobile detection can happen earlier in page’s lifecycle, if necessary.

Thank you for the contributions, Doug!

Anthony

Hi, folks –

I made a few updates to the code today. Here is a summary of the changes, which are also listed at the top of each file.

PHP Only:

• Created a constructor method per new features in PHP 5.0: __construct(). (Thanks, Lee C.!!)

All Code Libraries: PHP, JavaScript, Java, ASP.NET

• Added a new variable for 2 versions of the new BlackBerry Bold Touch (9900 and 9930): deviceBBBoldTouch.
• DetectTierIphone(): Moved Windows Phone 7 to the iPhone Tier. WP7.5′s IE 9-based browser is good enough now.
• DetectBlackBerryTouch(): Updated to support the 2 versions of the new BlackBerry Bold Touch (9900 and 9930). (Thanks, Robert P.!!)
• DetectKindle(): Updated to focus on eInk devices only. The Kindle Fire should be detected as a regular Android device.

As a side note, I also learned how to “checkout” and “commit” the code updates in SVN to Google Code. Now, file updates are truly updated versions of the same file in the Google Code system rather than an entirely new file with no history. I know, it’s a silly thing that I should have learned ages ago, and my apologies for not having done so sooner. So all of today’s updates are posted as Update r205. (Let’s just say that a switch to Mac and the Versions client were the main reasons…)

Cheers,

Anthony

James M. sent us a note just before Christmas about a support issue affecting the Firefox browser on Android phones. Here is a quick overview of the issue.

Issue Summary: When using the Firefox browser on an Android mobile phone, the MobileESP code library erroneously reports the device as an Android tablet. An Android tablet is correctly identified as an Android tablet. This issue only affects mobile phones and similar small-screen Android devices like MP3 players (such as the Samsung Galaxy Player).

Root Cause: Mozilla uses the exact same useragent string for both phones and tablets. The string has the word “Android” in both. According to Google guidelines, Mozilla should include the word “mobile” in the useragent string for mobile phones. Unfortunately, Mozilla is not compliant with Google’s guidelines. The omission of the word “mobile” is the reason why phones are erroneously identified as tablets.

Work Around: MobileESP works by finding clues to the device type in the useragent string. Because Mozilla uses the same exact string when installed on both phones and tablets, MobileESP cannot recognize which type of device the browser is installed on. Here are some options:

1. Don’t worry about it too much right now. Let’s hope Mozilla does the right thing and implements Google’s guidelines on the words to include in browser useragent strings on Android.
2. Err on the side of mobile phones. Modify the code library to always return “true” for Android Phones and always return “false” for Android Tablets. You would do this by looking for the words “gecko” and “firefox” in the useragent string in each respective detection method. On the plus side, phone-optimized sites aren’t too awful on tablets. On the minus side, we aren’t fond of hacks like this, so we won’t officially add this hack to the MobileESP baseline.
3. Write to Mozilla. Ask them to follow Google’s guidelines for useragent string construction. (We’re not sure if the best feedback forum is through the MDN or the mobile project forum. In the Android Market, Mozilla provides this email address for feedback: FirefoxforAndroid@mozilla.com)

Those > and < marks get me every freakin’ time…

I just uploaded a new version of the MobileESP code to fix a bug I introduced in the last update in DetectAndroidTablet(). Please accept my apologies for that! Thank you to René B. for catching the bug.

Hi, folks –

Here we go again on the Opera mobile browser ride…  :-)

So last week, we fixed the inaccurate detection results for the very good Opera Mobile browser on Android. This week, it’s the Opera Mini browser’s turn!

Today, I made two sets of updates to the MobileESP code libraries for PHP, Java, ASP.NET and JavaScript:

1. All libraries: Updated the DetectAndroidTablet() method to prevent the Opera Mini browser from erroneously reporting as true. This fix was a significant re-write of the method’s code, so please let me know if I screwed something up. I only tested it in PHP and JavaScript and it appears to work fine….
2. ASP.NET & JavaScript Only: Updated the techniques for initializing the user agent and httpaccept variables to handle null or uninitialized strings. Sometimes spiders and similar robots don’t initialize those values. I couldn’t test these updates here, so please let me know how these work in production! (PHP and Java already had solutions for this issue.)

So what is the Opera Mini browser? The Opera Mini browser started its mobile life as a way to bring (near) desktop functionality to feature phones. Now in the Android world, the Mini browser lives on as a highly data-efficient browsing alternative. Basically, all of the hard lifting for rendering a page is done on Opera’s servers, and they just send the phone a highly compressed file. It’s a great web page pre-processing solution.

But… Note that the Opera Mini browser is not processed on the client (phone/tablet) side — it’s pre-processed on the server. For this reason, the browser does not qualify as iPhone Tier. For now, we’re leaving it in the generic mobile device tier.

Thanks to Nolan K. for bringing the Opera Mini issue to my attention. And special thanks to John H. for providing the efficient ASP.NET code fix for the user agent and httpaccept variables.

As always, please help me check for errors & bugs. I can do a light test of the PHP and JavaScript code libraries, but I don’t have access to servers to check the ASP.NET or Java code libraries. Please let me know if you find something. Much obliged!