My Journey to Android After Five Years of iOS Loyalty

I’ve been an avid Apple supporter for years, and have owned iPhones in various incarnations since their launch on June 29th, 2007 (Yes, I was one of the unfortunate / foolish folks who shelled out $599 for the shiny new handset).  Over the past five years I have watched both iOS and Android grow, but my focus has always remained on Apple.  When I was due for a phone upgrade about two years ago I naturally gravitated towards a new iPhone 4 and likely would have purchased it solely based on my belief in Apple, regardless of the phones new features.

Until recently, my experience with Android devices had been quite limited.  What initially turned me off to them was that, despite having great specifications on paper, they couldn’t seem to accomplish even the most basic tasks smoothly. Things like scrolling through a list of contacts or zooming in on a web page made it seem like the hardware and software were fighting with each other.  The unification of software and hardware is an area that Apple has always prioritized, especially with its iOS platform.

I became eligible for a phone upgrade a short while ago and, up until quite recently, had decided that I was going to wait for the next iPhone.  However, after some coercing by some of my Android-loving coworkers, I decided to do something pretty scary – ditch my iPhone in favor of a device powered by an operating system that I’d been so against for so long.  I was hesitant to say the least, but after doing some research and weighing the pros and cons, I ultimately made the switch.  I ended up purchasing a Samsung Galaxy S3, and can say that after using this phone for about ten days, I don’t regret switching one bit and really couldn’t be happier with my decision.

One major plus Android has going for them, from a developer’s standpoint, is that you can develop Android apps for free.  Apple charges a yearly $99 subscription fee to be a part of their iOS Developer Program, and while that may not be a lot of money if you’re an established company, it’s a lot to ask from someone who just wants to be able to develop for mobile devices as a hobby, with the hopes of one day maybe submitting an app for sale.

Recently, Google has begun to roll out their new operating system –Android 4.1 Jelly Bean.  One of the core features of Jelly Bean, known as “Project Butter”, is meant to help the operating system run as smoothly as possible.  Using technologies like triple buffering and vertical sync, the OS is able to run silky smooth, which really hits Apple in an area that iOS has absolutely dominated until recently.

The future is looking very bright for Google, as they’ve resolved the vast majority of the issues that I’ve had with their Android platform and, in my opinion, have caught up to, or surpassed, iOS in nearly every way.  While the iPhone UI is still slightly more polished, the differences are becoming less and less significant and are easily outweighed by the additional capabilities, raw performance, and overall sense of freedom that the Android platform provides.  I can safely say that iOS will always hold a special place in my heart, but it definitely won’t be occupying a special place in my pocket anytime soon.

Advertisements

Detecting Mobile Devices — Don’t Bother

Image of mobile phone showing this site.Author: Adrian Roselli  10/11/2011

Since I started working on the web (and was slowly coaxed to the world of Netscape from Mosaic and HotJava), clients have asked me to find ways to adjust how a page behaves based on what browser the end user has. Before campaigns like the Web Standards Project (WaSP) took hold and slowly convinced web developers, and by extension clients, that the right approach is to build for standards first, web developers struggled with everything from clunky JavaScript user agent sniffers to server-side components like the browscap.ini file for IIS. These all took time to maintain and were never 100% effective.

I am thrilled we’ve gotten to the point in the web where progressive enhancement is in vogue, finally falling in line with our own practices of the last decade or so. With the advent of mobile devices and plunging screen resolutions, we have support in the form of CSS media queries to adapt a single page to multiple devices, now referred to as responsive web design. Yes, we are still struggling with the best practices and design differences (such as forgetting print styles), but the overall concept is solid. No longer must you code a text-only page, a mobile page, a printable page, and a regular page (or the templates for each if you are using a web content management system). You can build one page and let it handle all those scenarios.

Except sometimes you find yourself in a situation where you have been asked to develop a different experience for a mobile user that lies outside the ideal of responsive sites. That different experience can be as simple as sending a user to a different page on the site if he or she is surfing on a mobile device. All those years of progress are swept away in one moment and we are back to struggling with user agents. I’d like to provide a little context on why such a simple-sounding request can be such an effort to implement.

Techniques?

If we fall back to user agent sniffing (reading the browser’s User Agent as it reports to the server), then we have an uphill battle. Just finding a comprehensive list is an effort. One site lists hundreds of user agent strings, and there is even a SourceForge project dedicated to staying on top of them all. When you consider how many different phones and browsers there are, and how often new ones come out (such as Amazon Silk), your clients need to understand that this approach is doomed to failure without ongoing updates (and fees).

If all you do is follow Google’s advice on its Webmaster Central Blog to simply look for the word “mobile” in the string, you’ll fail immediately — user agents on Android devices do not need to conform (and often don’t) to what Google says you will find. Opera doesn’t include “mobile” in its user agent (Opera/9.80 (Android 2.3.3; Linux; Opera Mobi/ADR-1109081720; U; en) Presto/2.8.149 Version/11.10), and the browser Dolphin doesn’t even include its name in the user agent string (Mozilla/5.0 (Linux; U; Android 2.3.3; en-us; PC36100 Build/GRI40) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 ).

You can take the inverse approach and instead detect for desktop browsers. It’s smart and simple as far as user agent sniffing goes, but still falls prey to the same problem of the constantly changing landscape of browsers. Given that the next version of Windows is intended to quickly switch its interface back and forth between desktop and mobile (keyboard and touch), unless the user agent for all the browsers installed on that device change as the user changes the device orientation, that technique is also doomed.

Serving different content based on screen resolution gets you around the user agent sniffing, but isn’t any more effective. With tablets approaching desktop screen resolution, and smartphone resolution approaching tablet resolution, there is no clear method for determining what kind of device a user has. An iPhone 4S held horizontally has 960 pixels of resolution and the Dell Streak tablet has 800 pixels (to clarify, the smaller device has more pixels, which is contrary to what most might expect). If you want a tablet to have a different experience than a phone, then serving it based on screen resolution won’t do it. As it is, the resolution of many tablets matches that of my netbook (1,024 x 600), which is definitely not the same type of device (it has a keyboard, for example).

What To Do?

Try to solve the objective earlier in the overall process — generate a different URL for mobile, embed it in different QR codes, look into feature detection, look at using CSS media queries to display or hide alternate content, and so on. Every case may require a different solution, but falling back to methods that were never reliable certainly isn’t the right default approach.