Debugging Phonegap apps has its own catch; you start out working in webtechnology but the need to check if things look great on your phone a.s.a.p. is always present. And then there is the difference per platform on what tools are available for debugging.
iOS, for one, has built-in remote debugging capabilities that will let you check your browser console and mutate the page DOM and set breakpoints on your JS code. These are important tools that will help you tackle nasty bugs and speed up your development proces
In a series of posts called “Pimp your Phonegap Android dev stack” I share some ins and outs on some tools that make a fast development stack setup for building Phonegap Android apps.
First of all: I am in no way affiliated with the product- and service providers mentioned herein. They didn’t approach me and the tooling mentioned is used by me because I investigated options and they came across as (my personal) winners.
Console log switch
Printing simple statements to the console using the famous console.log(‘your message here’) statements seems like a dirty solution. The statements change your codebase, often they are forgotten and every time you remove / relocate / comment out these calls is a window for code bugs to come crawling in.
When you’re using flashy JS libraries or frameworks chances are that they have neater logging implementations embedded that won’t put stuff in the console when you build with the –release parameter behind their CLI.
I must agree that plain console logging isn’t the worlds prettiest thing to use, but sometimes it just has its own advantages over remote debugging with JS breakpoints.
One instance would be the case where you’re using an array of objects in your business logic to calculate values or display information on screen and there is just something wrong; you COULD place a breakpoint and check all items where things go wrong, BUT adding a console.log in the iteration (wether it be an .each / for / … loop) that displays the vital information of each element is just a huge timesaver. This will let you print out the entire array and enables you to identify the anomaly that is causing the bug you’re investigating.
So what if you could add nice console.log statements and decide with a single statement if you want the console.log calls to actually display anyting or not (where the latter would be the case when you’re releasing your app)?
You’re actually asking for a log switch, and here it is:
[crayon-633e208aaf932009345092/] Source: the code above has been derived from this StackOverflow answer by Justin, whom I’d like to thank for the simple and neat implementation.
When you save the above code in a .js file that’s included in a html file (along with jQuery) it will enable you to switch your console.log statements on or off in a single statement. Since console.log is default ON, disabling it would be as easy as adding:
[crayon-633e208aaf940830222984/] Re-enabling it at a later point (ie: this is useful if you’re deploying an AdHoc testing version with an embedded log switch) can be done by adding:
- Easy setup
- No need to alter / comment out / remove all those console.log statements for release builds
- You can use your own debug logging implementation or 3th party ones as long as it depends on console.log and the .log statements will be silenced
- This is just for plain logging; if you’re into differentiated logging with various types (warning, error, message, etc) this will not be sufficient
- This script will need you to manually disable logging; needs hacking when you want to disable logging based on build actions with tools like Grunt
Nevertheless, this provides for an easy solution that will help you debug your Phonegap app for Android without increasing bug chances and keeping the device log clean when the app is released.