##Transitioning a Web App to a Mobile Device Assuming you’ve built and deployed your phonegap or trigger.io wrapped web app to a mobile device, you might be in for a rude surprise.

Most likely the app will look competely out of whack. The page will zoom oddly, events won’t fire correctly and you’ll get weird haloes and zooming when you tap the page. Don’t despair, these quirks can all be ironed out.

##Responsive Markup for Height and Orientation Even if you are are using a responsive layout like twitter bootstrap or zurb foundation, the layout will need some tweaking. Those design frameworks also tend to handle the width of a device, but leave the height up to the content. For a mobile app you’ll need to add media queries and set the height of our containers. There are also media queries for orientation, so you can size things differently for portrait versus landscape.

You should be able to handle all of that at the css level with a single html document. If you are creating different markup for landscape and portrait, you might need to rethink your approach.

If this is too much for you, please hire a skilled technical designer like Nathan Cooper.

##Click Events are too Slow The next thing you might notice is that click events take too long to register. Some people give up at this point and say that javascript on mobile devices is just too slow. A little research will turn up the fact that webkit on mobile devices delays a click event for 300ms to be sure the user isn’t trying to double tap.

In a previous post, I wrote about a knockout.js specific fix. Since then I’ve come across more general purpose click handler for mobile apps that is incredibly easy. Definitely use fastclick to speed up your click events.

##Orange Halos on Button Clicks Some mobile browsers, including the HTC version of webkit that was on my phone indicate a click event by wrapping the button in a clunky green or orange border. It also takes the entire 300ms to display, which can slow down the perceived responsiveness of the app. You can remove this with the following css rule for all elements.

* {
	-webkit-tap-highlight-color: rgba(255, 255, 255, 0); 
}

##Click Events are Too Fast Now that you’ve removed the stock click feedback response in some browsers you may notice that the button doesn’t appear to actually be clicked. With twitter bootstrap buttons, the button appears to slightly depress when clicked on the web.

You can manually add the “active” class to bootstrap buttons and then remove it after the event has completed. But, if you drop some logging statements into your click handler function you’ll notice that the activity you are triggering might be too quick to actually register.

You can delay removing the active class from a button by 300-400ms to give a better respsonse. The user will actually be able to see the clicked state of the button.

var clickHandler = function (event) {
	var $button = $(event.target).addClass('active');
	doSomeStuff();
	setTimeout(function () {
	      $button.removeClass('active');
	}, 400);  
}

##Page Unintentionally Zooms or Scrolls Since we are creating an app, we don’t necessarily want the user to able to zoom or scroll the page around. We can lock the zoom down with the following viewport meta tag.

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">

##Overflow Scrolling for List Views One thing that seems to be missing for a lot of mobile browsers is the ability to set the overflow property for divs to allow for scrolling with or without scrollbars. It’d be nice to allow these divs to be scrolled by touch events. For modern mobile browsers, including the ipad it is possible to set a css property to achieve this affect.

.scrolly {
	-webkit-overflow-scrolling: touch;	
}

Unfortunately for many mobile browsers, including the stock HTC browser on Android 2.3 devices, this will not work. Luckily some smart people have created an excellent library that will handle all these cases, either with the above mentioned css or a javascript polyfill. Check out overthrow.js by the filament group.

##Javascript vs Native Performance As you can see, there isn’t a huge different in the performance of js apps when compared to native apps for typical apps. Canvas performance for games or anything that requires much in the way of native hardware support might be a little more tricky. The key to a successful app is good design and competent coding, no matter the language.

##To phonegap or Not? Phonegap or Cordova as it is now known is one of the projects that makes wrapping a web app in a native web view a fairly straightforward process. The project was acquired by Adobe, but has been taken on by the Apache Foundation as an open source project.

Phonegap is a mature project and offers numerous plugins for using the gps, camera, filesystem, etc. It is definitely worth checking out.

Unfortunately it seems to require the use of Eclipse. The configuration process seems to be somewhat involved. My goal was to build and deploy a native app in one week. I succeeded, in part, by not using phonegap.

Lately, I have been hearing good things about a company called trigger.io. They offer a service to build android and ios apps from html and javascript for free. They even include chrome apps with their freemium offering. If you pay, you can build for windows phone as well.

Theoretically you can build ios apps without the use of xcode, but I did not explore that option.

##Native Modules They also offer a solid core of native features accessible through a javascript api. You can use the camera, sms, events, contacts, geolocation, filesystem, facebook auth and some ui elements through js. I used the sms module, which was absolutely easy. The facebook api also looked like a great offering.

The in app payment module looked like it would be handy, but while it is free now, they are planning on charging in the future. Making money with that sort of thing would definitely be a service worth money.

The value that trigger.io adds is definitely worth money. The free service they offer is unbeatable for anyone getting started with mobile app development. If I were making money from an app, I would definitely consider paying for trigger.io.

##Vendor Lock I’m extremely cautious about recommending a free service that may end up costing a lot some day. Google Maps is the obvious example.

I feel like the risk involved with trigger.io is minimal because the only commitment you have to the platform is the code you write for the native modules. One could easily drop back to phonegap if the price was too high.

trigger.io is definitely worth checking out. The build process was streamlined and the tools were easy to use. I mostly stuck with the command line tools, but be sure to keep them up to date. When the company upgrades their service you need to download the latest version. There is also an excellent gui for building and deploying apps.

##trigger.io Bootstrap To get up to speed trigger.io provides a sample project on github. It is a simple single page app that uses backbone and zepto and includes animated transitions to better simulate a native app.

##Remote Debugging with Catalyst/weinre Another feature of trigger.io is catalyst, the hosted version of weinre, the remote debugger. This service works a bit like firebug or the chrome developer tools, but for apps deployed to devices. You include a script in your app and then visit the url provided by the service.

You can’t actually set breakpoints, but you can inspect the dom and output console logging statements. It is an invaluable tool for debugging natively wrapped webapps.

If you are using phonegap, catalyst is essentially the same as the phonegap weinre service.

##In Other Words Apps that use html and javascript are becoming the norm. Here is a great article that describes the difficulties one dev shop had in porting their app to Windows 8. Apparently it took all of sixty minutes to get it up and running on the new platform.

##Android or iPad? After the recent birth of my son, I have had a little time away from work. I have been using the downtime to work on some personal projects in order to build skills and perhaps increase my own personal economic resiliance.

I had been entertaining the idea of writing a native mobile app, but honestly the idea of java or objective c is not that appealing. I also think it is a waste of time to build an app that would only work on one of the platforms.

Luckily there is a compromise. By wrapping a traditional web app in a webkit view, an essentially native app can be written in html and javascript.

##Client Side Contenders For the last 15+ years, several languages have been competing for dominance in the arena of creating richly interactive applications for the web. Java and flash have both been bested by javascript in the browser. It is a safe bet that javascript will also become the lingua franca of mobile apps, as well.

Some people argue that javascript will never perform as well as cocoa and I don’t disagree. However, for the vast majority of applications, js will do the job. Since so many of us are already comfortable with javascript and html, the idea of leveraging those skills for mobile devices is appealing.

##Dead Languages I would never suggest that learning another programming language is a waste of time, but if you are proficient at javascript you already have everything you need to start writing native apps for ios and android. You’ll be able to sell them in the app store and your users will never know the difference.

##Platform Quirks There are definitely some hurdles to developing a mobile web app that works like a native app. If it was easy, everyone would be doing it. It will help if you already have experience with modern client side frameworks like backbone or knockout. Taking a strong front end approach will ease the transition. Javascript is an idiosyncratic language that needs to be used with mindfulness.