UPDATED: March 30, 2016
If you have been reading the last couple articles you know I am a big fan of Mobvious. I use it to figure out what kind of device any given request has come from, i.e. tablet, PC, phone?
With this information Rails then serves optimized content for that device:
This set up has worked very well for me, but things have changed. Rails now comes with Action Pack Variants which make serving device optimized content amazingly simple and powerful. This article is about setting up user agent detection with Browser and variants.
Before you begin you might want to consider starting with Mobile Device Detection with Ruby on Rails. The results will be same, but completely in line with the Rails templating defaults. This article offers a slight – experimental – variation.
Although I am a big fan of Mobvious, recently I've been experimenting with Browser for user agent detection, and it's rapidly becoming my solution of choice. I also think it is a better fit for this solution, so let's use it.
Add Browser to your
Like with Mobvious, Browser will determine what kind of device the incoming request came from.
Setting up Variants
Through variants we can take this information and handle what to do with the request.
Add the methods
application_controller.rb as follows:
class ApplicationController < ActionController::Base
# Prevent CSRF attacks by raising an exception.
# For APIs, you may want to use :null_session instead.
protect_from_forgery with: :exception
request.variant = :tablet if browser.device.tablet?
request.variant = :desktop if !browser.device.mobile? && !browser.device.tablet?
before_action sets the
request.variant variable. We use this variable to assign a unique layout for requests coming from desktop PCs, tablets, mobile phones (or what ever).
Setting up Your Layouts
Layouts are the crux of the entire system. You will need to create base layout templates for the different device types you are targeting. In our case we will need:
application.html+tablet.haml (use erb if you wish)
Rails knows to respond to
request.variant with a corresponding "+<device_type>". If it cannot find it, it will serve the default
Truly "Mobile First"
If you really want to work and think "mobile first," make
application.html.haml an exclusive mobile template, with all its corresponding views, styles and scripts mobile optimized as well.
This way the default Rails files of your application will always be mobile ready, and mobile will become the default framework from which you *think* and code; a first class citizen.
You do not have to do it this way, but that is how I have done it in the code sample above, tablets and desktops are secondary. Maybe this is overkill, but that's how important I think mobile is today! (or will be soon)
The last thing we need to do is add some boilerplate for our mobile template and views. I have created a mobile foundation based on Mobile Boilerplate...
A best practice baseline for your mobile web app
Our version is configured specifically for Rails. Feel free to use it.
Clone the following base-mobile files from my github account, then copy and merge only the
base-mobile/variants folders into your application.
git clone email@example.com:maxxiimo/base-mobile.git
These files are NOT set up for the mobile first approach I mentioned above, but you can easily change that. If you do choose to add this boilerplate code to your project you will also need to add the following assets to your precompile list:
Rails.application.config.assets.precompile += %w( modernizr-2.8.3.min.js phone.css phone.js )
Desktop Foundation Code
Like with mobile, for desktop PC's I recommend setting up some foundation HTML and CSS as well:
And that's that! With these few lines of code your application can distinguish between device types and serve tailored code to those devices. But why should we do it with variants instead of my previous method?
Why Is This Good?
First off, it's always best to use what Rails offers, and now Rails has a way to address mobile baked in. Stick with the conventions. It will be better for you in both the short and long-term.
What's so powerful about serving different layouts can be found in what each template brings to the table. Each can specify a different set of styles or scripts or content or whatever, which means you can highly customize the user experience for the device type the user is on. This translates to content that makes sense for different screen sizes; user flows that makes sense for the device type; and better performance on smaller devices without compromising what can be offered on desktops.
Finally, why make the defaults mobile? I believe doing so puts mobile development at the forefront of a development teams thought process. It's harder to ignore, and believe you me it should never be ignored. In fact I predict that in the next 5 years, some websites will not even have a desktop version because 70% or more of its user base will access the site via mobile (and the mobile version will suffice for desktops).
Nearly two-thirds of American adults (64%) now own a smartphone of some kind, up from 58% in early 2014. Smartphone ownership has increased by 29 percentage points since Pew Research conducted its first survey of smartphone ownership in the spring of 2011, when 35% of Americans were smartphone owners.
- Pew Research Center, "US Smartphone Use in 2015"
In other parts the world, like China, this is already occurring.
Want to know when the next article is published? Subscribe here. Thanks for reading!