Telerik blogs

When you're developing mobile applications, you'll save yourself a lot of time (and spare yourself lots of headaches) by being aware of a few debugging tools and tips. Mobile app debugging often relies on a multi-pronged approach where first you're simply working to be aware of what issues and exceptions are occurring, second, you're catching those errors as close to development time as possible on your desktop or laptop, and finally, you're debugging remotely on the device to catch anything that snuck past the first two steps. Let's take a quick look at some tips & tools you can use on each of these three general steps to help make debugging less painful.

Knowing When Errors Occur

"Knowing is half the battle." — GI Joe

In an ideal world, you'd know ahead of time all the possible exceptions that could be thrown in your app. I've never lived in that world — and if you do, I'd love an invite. In the meantime, then, what can we do to raise our awareness of the show-stopping unhandled runtime exceptions that occur, before we've had a chance to work more appropriate and elegant exception handling for the root cause into our app?

AppBuilder actually lends some help in this area with project templates. For example, the Kendo UI Mobile project template includes this snippet at the top of the app.js file:

// global error handling
var showAlert = function(message, title, callback) {
    navigator.notification.alert(message, callback || function () {
    }, title, 'OK');
};
var showError = function(message) {
    showAlert(message, 'Error occurred');
};
window.addEventListener('error', function (e) {
    e.preventDefault();
    var message = e.message + "' from " + e.filename + ":" + e.lineno;
    showAlert(message, 'Error occurred');
    return true;
});

The above code has effectively cast a very wide net. Most unhandled exceptions will trigger the window error event (though there's a slim number of ones that won't). We're taking advantage of a global error event by putting an alert in place that will notify us of the key exception metadata when the error occurs.

It's easy to underestimate the value of this snippet, until you deploy your code to a device, load your app and nothing happens. If an unhandled exception has occurred as your app starts up, you'll at least be immediately aware of it before going through the trouble of connecting your device to a remote debugger.

As your app matures, you can still make use of the global error event to not only give your app a chance to recover to a usable state in the case of unforeseen errors, but also to tie in performance and analytics packages to log the exception so your team can become aware and address the root cause(s).

Desktop Tools

When you're writing hybrid mobile apps, don't miss out on the chance to take advantage of mature browser tooling. Comfortable with Chrome's or Firefox's developer tools? Great! You can use them to track down bugs, step through code and profile your hybrid mobile app before it hits your device. The "Debugging Your Code" section of our docs has more information, but the gist is that if you are using the in-browser AppBuilder client, you can use your browser's development tools. For example, in the screen shot below, I'm using Chrome to debug an iPhone app I've written in AppBuilder:

You get the advantage of the tooling you're used to, and you get some extras from the AppBuilder simulator as well. Both the in-browser and Windows AppBuilder client simulators give you the ability to emulate changes in location:

...and you can emulate changes in connectivity:

If you're using the AppBuilder Windows client or the AppBuilder Extension for Visual Studio, you can use the Webkit-based tools available with the desktop simulator. Check out this post for a more in-depth look at how you can use the simulator. Given that it's Webkit-based, the tooling will feel very familiar to you if you've used Chrome's or Safari's developer tools. Much like its browser counterpart, the desktop simulator allows you to do things like inspect the DOM, step-debug, view network requests, emulate connectivity & geolocation changes and even record and inspect "Timelines" (as in the screen capture below):

Debugging in the Wild

The tooling shouldn't stop at your desktop, and with AppBuilder it definitely doesn't stop there. On-device debugging will be a necessity, so it's important to be aware of some of the options available.

Remote Debugging iOS

If you're using the AppBuilder Windows client or Visual Studio Extension, did you know you can remote debug your iOS app?! Be sure to read our docs, which explain how you can set this up. If you're on a Mac, you're covered as well, since you can use Safari 6+ to remote debug iOS apps as well.

Remote Debugging Android

With the release of Android 4.4, remote debugging Android devices got a much needed shot of adrenaline (see this for more info). However, there's still a huge number of devices running prior versions of Android that you'll likely need to contend with for the next year or two. Thankfully, jsHybugger exists. jsHybugger allows you to use most of Chrome's developer tools to remotely debug your hybrid app as it runs on an Android device. It's the first (& only) substantial pre-Android-4.4 remote debugging solution, based on what I've seen thus far.

Other Options

Two other well-known option for debugging on-device are Weinre and JSConsole. Weinre is based on Webkit, and allows a limited amount of visibility into your app as it runs on a device (for example — you can inspect the DOM and interact via the Console, but you can't set breakpoints or step-debug). JSConsole allows you to remotely interact (via an in-browser console) with your mobile application using a desktop browser. While it might be "lower level" debugging compared to something like using Safari to remote-debug iOS, JSConsole is impressive in that it can target any kind of web client, not just mobile web/hybrid mobile.

Where to Go From Here

I linked to these posts through this article, but if you'd like a condensed reading list which can help you get up to speed on these options, enjoy:

Jim Cowart

About the Author
is an architect, developer, open source author, and overall web/hybrid mobile development geek. He is an active speaker and writer, with a passion for elevating developer knowledge of patterns and helpful frameworks. Jim works for Telerik as a Developer Advocate and is @ifandelse on Twitter.


Related Posts

Comments

Comments are disabled in preview mode.