The poor state of Android JavaScript debugging

Cross-platform mobile web development is heating up and the the performance level is continuing to increase as new an more powerful devices are released. One of the allures to this style of mobile development is the single code base you can use across multiple platforms. With wrappers like Cordova and modern web frameworks you can get up and running super quick, but you incur a technical debt in debug time that you won’t know you need until it breaks in an unexpected way. It will break if you work on a sufficiently complex application.

When you start in cross-platform you’re probably thinking about hitting the most devices possible with the least amount of development time. Google reports, as of this posting, that Ice Cream Sandwich and KitKat account for 17.7% of Android installs (http://developer.android.com/about/dashboards). Those devices have it easy because they are coming with Chrome for Android installed. Chrome for Android features the future of debugging mobile web applications with the new remote debugger you can read about https://developers.google.com/chrome-developer-tools/docs/remote-debugging. That is wonderful for the future, but the other 82.3% of devices don’t get this new browser, and that means you don’t get those fancy new debugging features.

88294The first option for debugging on Android is a hosted JavaScript file that is served by a tool called Weinre. The quick way to give Weinre a try is to use the version hosted by PhoneGap at http://debug.phonegap.com. Just load up the script on that page in your app, but you’ll have to use Safari, Chrome didn’t work for me though it did for my colleague. Again poor planning for the extra Android debug efforts lead to confusion and short patience. From here you can see current CSS, DOM and execute JavaScript, but you can’t set any breakpoints. It is very slow, think slower to use than the Android ARM emulator is, and will cause frustration for developers.

Another option that you can use is jsHybugger which is an instrumentation library. This is the solution for proper JavaScript debugging, but the instrumentation does change your code when enabled and deployed to your device. I was personally met with race conditions when the JavaScript files were loaded in a large application and felt uneasy about relying on it for accurate debugging. We suffered from the same poor planning I am advising you don’t do in your project. By the time we needed to debug the app our patience was short, and we didn’t give it enough time or planning.

In the end, to debug your cross-platform mobile web application I would use a combination of both jsHybugger and Weinre. When you start your project and are thinking about all the speed of development improvements just don’t forget about debugging your program. You’ll want to allow for more time debugging your application on Android than you would on iOS. Eventually this won’t be as much of an issue, and it isn’t an issue at all of you only support Chrome for Android, but for now you’ll need to work with more than one debugging solution to deploy a successful cross-platform mobile web app.

How to Hide Your JavaScript Source Code (Don’t!)

Just don’t. If you are trying to focus on hiding your trade secret sauce that you’ve written into your new single-page JavaScript application you’re just wasting your time. If you’ve coded the entire framework and all your libraries by hand then no one will be able to understand your code enough to steal pieces, they will do an entire copy of your website. The odds are however that you’ve leaned on some existing libraries, that more of the code in your final product was written by someone else entirely. That’s completely okay! For years now as developers we’ve stood on the shoulders of giants to create our finished work. Great libraries like jQuery, frameworks like AngularJS, layout frameworks like Bootstrap all give us a great and well tested path of least resistance to launch.

The idea that you’re able to protect your code through minification or obfuscation isn’t new. ActionScript decompilers started coming out much to the dismay of Flash developers and shortly after that the ActionScript obfuscators hit the market. Minification is the process of removing all extra spacing and lines from a file or set of files for the reason of saving space. Obfuscation is the process of making your code illegible, even going so far as to encode strings that are later decoded. Obfuscation can lead to introducing hard to debug issues, and only protects your strings from a first glance as it is simple enough to unencode the entire document and retrieve said strings.

It’s the strings that can allow anyone to see in your code what your trade secret sauce is. What combination of libraries you used in a project help make it unique, but the interconnecting code that brings them together is what make it a product. Each library has a certain set of strings in them that act as markers, version numbers, unique variable names that will allow those libraries to be identified even in a minified state. You can’t hide the recipe for your JavaScript application. So stop trying! There are also restrictions on certain libraries that ask for attribution, or that they remain as part of open source projects.

View source is the spirit of the web, being able to look at how the documents and applications are structure is part of how the World Wide Web became so popular. That low barrier to curiosity where you could simply inspect the client side code being delivered to you allowed for a generation of tinkerers to be born. Those same tinkerers went on to build the libraries that you have now brought together to make your application. Don’t focus on hiding what you’ve created. Focus on making the best product possible and be proud of the libraries and frameworks you’ve used to create your product. Without a herculean effort, no one will be able to discern a gem of code that you’ve wrote, pull it out and then profit off it. Stop worrying and get back to making sweet JavaScript applications.

Launching the TheKnot.com Search BETA

Screen Shot 2012-12-24 at 4.22.03 PM

My major project of 2012, TheKnot.com Search BETA, launched earlier this month, the morning of December 14th, and it was a journey worth documenting. It began back in May when the company decided to start our own labs or internal incubator groups. One began right away in New York City and the other started a couple weeks later in Austin. I had the opportunity to join the Austin group with a team of developers and product people that I highly respected. I was grinning the whole time with excitement. With the direction that we were independent from the company but had access to the data we sequestered ourselves in a room for a few weeks. Over pots of coffee and pints of beer after work we brainstormed our some good ideas for our brides to find inspiration for their weddings. Our group started out as Judy Galani, Product Strategist, Forrest Andrews and Matt Oehlers, Senior Software Engineers, Erin Bender, Freelance Art Director, and myself as Interactive Media Developer. We “sold” the idea and working prototype to our “investors” by October and it was then time to go from prototype to production.

We had to take the design in house from this point on, but after a fond farewell and thank you to Erin we started to add in more management to the group. It was a greenfield project so our back-end developers Matt and Forrest were excited to push forward into new territories. Within a day or two we were able to deploy projects straight from Visual Studio to the AWS servers, I was blown away. Forrest focused on our MongoDB NoSQL data store and the API that I would later pull all the front-end content from, ASP.NET MVC. Matt worked on massaging the data into Apache Solr and in a matter of days we had an impressive result set coming back for queries.

Screen Shot 2012-12-24 at 4.22.40 PM copy

The front-end technology was built to be a responsive two page website that used a combination ofjQuery and Underscore.js along with HTML and CSS to create a multi-device interface that would be familiar and easy to use. The main grid view uses Masonry to create the Pinterest-esque layout for search results and Underscore.js templates to load in a different layout for different data types. The single page view focuses on a low browser width touch interface to give a very image focused search experience. To combine and minify the page scripts down I used the BundleCollection library in ASP.NET MVC which worked great. There are still a large number of extra scripts on the page but I’ve tried to load them asynchronously and not let them interfere with using the interface immediately.

The site has been up and working great for a few weeks now and launched along side a new look and feel for TheKnot.com. Go take a look, and of course let me know if you find any bugs here or on the feedback tab on the bottom!

Continue reading