Three essential debugging tools for mobile applications
In this post I wanted to go over some useful programs that have recently become indispensable for my daily workflow.
Adobe Edge Inspect
Probably the most famous of all candidates comes from Adobe. Edge Inspect, formerly known as Adobe Shadow, allows you to preview web designs on devices.
Once you’ve signed up for a Creative Cloud account (which is obligatory) you have to install a browser plugin and set up Edge Inspect on all the devices you want it to run on. It’s a procedure of 5 minutes.
When you have everything set up, you only need to start the Edge application on your desktop (the place where you’re gonna open your websites), open Edge on your mobile device and connect it to the host that shows up on the screen. Of course, both devices should be on the same network.
Now, every page you call in your browser will be shown synchronously on all devices that you are connected with. What’s important to know is that every device manages it’s own “browser environment", so if you’re logged into a website on your desktop doesn’t mean you’re running the same session on your mobile phone. The same applies for accepting unsigned SSL certificates, HTTP authentication and client-side caching. The latter however can easyily be cleared on all devices simultaneously with a “Refresh All" button.
The most amazing part about Edge Inspect in my opinion is the inclusion of weinre, a remote debugger for websites that provides development tools such as Firebug to make live changes to your HTML/CSS and Javascript on your device from your computer.
JS Console
The second tool I want to recommend is JS Console by Remy Sharp. This is a remote tool that serves primarily as a javascript debugger. When you go to the webpage, you’re presented a console like interface that you can write commands into.
By typing
:listen
you can create a new connection, and the site returns a javascript snippet that you need to insert into your web page, e.g.:
<script src="http://jsconsole.com/remote.js?A3909C18-1E4E-4BE6-B0B3-A17567"></script>
By doing so, and calling the website on one of your devices, you can start your remote debugging session right from the console.
For example, if you’re in the same network and you’re running a web server (like MAMP) on your desktop computer, you can call it from your mobile devices with your IP address. You just need to keep the debugging HTML file in your localhost directory so it is accessible from outside. In my case, I called the following URL from my iPhone, the IP address being the one of my Macbook:
http://192.168.1.4/remote-debugging.html
If everything went well, you’re gonna see the following in your JS Console session
Connection established with http://192.168.1.4/remote-debugging.html
You’ve taken control over your mobile device and you’re ready to debug. As an example, run the following command in the JS console terminal window and it should return the width of your device:
window.innerWidth
which in my case returns 980, the horizontal size of the layout viewport. As another example, type in the following and it should pop up an alert window on your phone:
alert('Hello World!')
Amazing. Now it’s up to you to figure out some great new ways of debugging your mobile applications remotely.
Charles
The third tool in the series is an excellent way for tracking network traffic, an aspect of debugging that the former tools do not include.
Charles is a “Web Debugging Proxy Application" which acts as an intermediary for requests between a web server and your mobile device. It
The easiest way for me to set it up was by following the instructions from this article.
Once it’s up and running, Charles allows you to track all outgoing network requests from your device and all incoming network responses going back to it, so you have a complete overview of what data is passed through it.
For every request, you can see a detailed summary of data like HTTP headers, duration, latency, download size etc. One feature that I especially enjoy is that Charles generates charts for a particular request group, e.g. all responses from a specific domain.
- A timeline chart of responses each one with their corresponding request-latency-response sequence allows me to inspect download duration and detect bottlenecks (e.g. slow JS scripts from a CDN)
- A sizes chart gives me an overview of all HTTP requests, sorted by download size so I can easily figure out which images or scripts might be problematic with respect to devices with low bandwidth
- The same can be done for duration and types, so you see what’s taking most time to download and which MIME types are making up most of the traffic
As you can see, there’s no all-in-one tool at this point that encompasses all aspects of mobile debugging, but with these applications you have a great combination of tools that can help you figure out most of the stuff you need and hopefully resolve some headaches.