When developing HTML5 web apps for mobiles and tablets, simulators and emulators can only take you so far. The sooner you can test on real devices the sooner you can catch real life usability issues and vendor implementation quirks.
This post outlines a technique for rapidly testing code changes with real devices.
My desktop development setup
For more traditional desktop web apps my development environment is fairly well established. I run a local web server on my laptop (in my case Apache) which mirrors the setup on my deployment server. I have virtual hosts setup and use the /etc/hosts
file of my laptop to ensure each virtual host resolves to my local machine.
So to create a new web app I just have to create a new folder in my sites directory, for example mywebapp.home
and then create a corresponding record in my hosts
file, e.g.
127.0.0.1 mywebapp.home
This works because the hosts
file is checked prior to my laptop making a DNS request further up the chain. So anytime an application on my laptop makes a request for mydomain.home
, it is resolved to 127.0.0.1
aka localhost
.
Making this work for mobiles/tablets
The above works well for testing in multiple desktop browsers (and the iOS Simulator) but for most emulators and on all physical devices it won’t work as the hosts
file isn’t able to intercept the DNS requests.
The aim however is still to enable the devices to be able to view the content served from my laptop. Larger businesses may run their own DNS setup locally which would negate this problem but for more agile working environments we need a different solution.
The easiest solution that I’ve found is to setup a single record on a remote DNS server that points to my local IP address. Then instead of using the mydomain.home
nomenclature, switch to something that matches the DNS record you created. As an example, if I owned the domain mobiledev.com
then I could setup a wildcard DNS A record as follows:
*.mobiledev.com => 192.168.0.4
And the matching folder in my sites directory might be mywebapp.mobiledev.com
.
Then, whenever a lookup for a subdomain is made it maps to the IP address for my laptop on the local network. Any device on the same network as my laptop is then able to resolve to the web server on my machine. The crucial caveat here is that you must be on the same network for this to work. You don’t need to open any ports or setup port forwarding on your router, you’re not allowing remote access to your development server, you’re just creating a replacement for your /etc/hosts
file that can be read by other devices.
Taking this mobile
You’re more than likely able to setup your home/office network to always issue you with the same IP address, so whenever you’re on your own network the IP address will resolve to the correct machine.
But what if you travel for work or often work in a number of locations?
For this, Dynamic DNS is a great option. My DNS provider (DNS Made Easy) offers this at no extra cost and they make an API available to programatically update your DNS record. Using the API I wrote a little PHP script that I run each time I arrive at a new location/network. The script works out my new local IP address and updates the DNS record accordingly.
If this would also be of you use to you, then you can download the script from GitHub.
Note: Its worth having a fairly short TTL (time to live) value for the dynamic DNS record so that changes propagate quickly. I’ve got mine set to about 3 minutes.
Extras
Once your devices are able to resolve a domain to your development machine you can start to take advantage of some of the other tools that are springing up around mobile web development:
-
“Weinre is a debugger for web pages, like FireBug (for FireFox) and Web Inspector (for WebKit-based browsers), except it’s designed to work remotely, and in particular, to allow you debug web pages on a mobile device such as a phone.” – via docs
You can download and run it locally or make use of the PhoneGap Debug service to get up and running as quickly as possible.
-
Shadow is a Chrome extension with companion apps for iOS and Android that essentially slaves all connected devices to the current Chrome window. This enables quick page reloading across many mobile devices from your desktop device. It also has a built in version of Weinre.
Pingback: Installing Weinre on Mac OS X » Joe Lambert