Adding Mobile Support with Web 2.0 Touch to the NoAgenda Attack Vector Dashboard
The quest for an ideal javascript framework for mobile web applications has been a bit of a work-in-progress for some time (at least if you cared about cross-platform).
You might have got started (like me) with Jonathan Stark's excellent books Building iPhone Apps with HTML, CSS, and JavaScript
I recently discovered another project - Web 2.0 Touch - that is pitched as a mini framework with better features and more ease of use than jQTouch. Since I had a little side-project underway that could benefit from mobile support, I thought I'd give it a test drive.
And I was duly impressed. In just a few hours, I had a full and distinct mobile version of the site. Better yet, I didn't run into any weird behaviours that can plague mobile development. It just worked.
Now I'm not going to stop tracking the jQuery Mobile project or other solutions like Rhomobile, but if all you need is a quick, functional and good looking mobile view, then Web 2.0 Touch is well worth a look.
The NoAgenda Attack Vector Dashboard is the project I used Web 2.0 Touch for, and if you want to see all the intricate details of how I made the site mobile-friendly - you can! The entire site is open sourced and available on
GitHub. I'll just describe a couple of the features here...
Differentiated Views
The first has not much to do with Web 2.0 Touch per se, and is more just a demonstration of how easy it is to work with a range of view technologies in Rails.Since the application has a very specific and rich desktop presentation, I knew the mobile version was going to be very different. Here are the desktop and mobile "home pages" side-by-side:
Rather than weigh down view code with lots of conditionals, I decided to use the MIME-type method of differentiation.
If you haven't used this before, it essentially means registering a suitable MIME-type (I called it mobile), and in the main ApplicationController, the request.format is set to this type if the client is detected to require the special mobile view. Now a request to an :index page will render with index.mobile.erb (or index.mobile.haml as is my preference), while the non-mobile view will render with index.html.erb / index.html.haml.
I've added the browser gem to the project for device identification, and for this app I've decided to only specifically handle iPhone and Android. I also don't give these phones a desktop view alternative, since I know it is not going to be nice.
# config/initializers/mime_types.rb:With that in place, my *.mobile.haml view and layout files just need to focus on rendering the mobile site.
Mime::Type.register_alias "text/html", :mobile
# application_controller.rb:
class ApplicationController < ActionController::Base
before_filter { request.format = :mobile if (browser.iphone? || browser.android?) }
end
Page Transitions
The jsTouch.loadPage method is used to load and navigate pages in the Web 2.0 Touch framework.In the application, I've made this 'unobtrusive' so it might be worth pointing out what is going on. The .touch_load class is used to tag items that should initiate a page transition. The data-url and data-transition attributes tell it where to go and what transition animation to use.
.toolbarThe enableSmartphonePageLoad function runs during page load to setup the behaviour:
%h1= t('.title')
%a.button.back.touch_load{'data-url' => menu_dashboard_path, 'data-transition' => 'pop-out' }= t(:done)
.content
= render :partial => 'notes/table'
enableSmartphonePageLoad: function() {
$('.touch_load').live('click', function() {
var url = $(this).data('url') || $(this).attr('href');
var transition = $(this).data('transition') || 'slide-left';
if (url != "") {
jsTouch.loadPage(url, { transition: transition });
}
return false;
});
},
Blogarhythm: Touch - Noiseworks
read more and comment..
SNGLISH L.A.
"Of all the driveways in all the streets in the world, you had to stumble into mine.." This caused a mild double-take and u-turn while traveling down Rodeo Drive in LA with a colleague..
read more and comment..
gitfall#1: Falling off a branch
Ever had a merge fail with a fatal: git write-tree failed to write a tree message out of the blue?
It sounds terrifying, but when I got the root cause is quite mundane: file name conflicts in the merging commits that git is not smart enough to figure out without help. And when you fixup your merge, you are left with a commit that's lost one of its parents ("falling off a branch").
If you do much file reorganisation in a project with branches, it turns out this can be quite common (had it a few times on a recent project).
The script not only shows how to create the error, but two ways of resolving it and the "lost parent branch" issue:
- Merge again after fixing the first failed commit. Duh!
- Going a bit deeper and using git commit-tree to manufacture a new merge commit with the correct parentage
Lessons learned form all of this? Perhaps:
- Avoid reorganising folder structures using folder names that once were used by files (or vice versa)
- If you must do such a reorganisation, immediately merge or cherry-pick to other active branches if you can. This avoids laying a trap for a co-worker to hit later on.
Hope you enjoy the script, and if you have any others to contribute please be my guest!
Blogarhythm: Fall Out - The Police
read more and comment..
Mikko Hyppönen@TED
Doing more than just talking about viruses: he fires up a few classics in a DOS box and pokes around with a binary editor before looking at current threats and live infection data. Very cool and entertaining. Not many are brave enough to do live demos, but if you watch to the end you'll get to see how prepared he was for failure;-)
Best served with sides of:
- Daniel Suarez's Daemon
- for the extreme version of how bad things can go wrong,
- Rebecca MacKinnon: Let's take back the Internet! - because maybe organised crime is the perfect distraction as we rush headlong to enslave ourselves to the Sovereigns of the Internet, and
- Security Now! #291 - for Steve Gibson's deconstruction of stuxnet, the most spohisticated Internet-borne "weaponised payload" ever discovered... and perhaps a plausibly-deniable warning from Government(s) that "you call that a knife? THIS is a knife!"
PS: better quality vid on youtube. And yes, that is a 5 1/4" floppy.
Blogarhythm: Security - Jo Jo Zep & The Falcons
read more and comment..