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.

Knowledge Alone is Not Enough to Succeed

I’ve been reading technical texts for years; ever since I saw dinosaurs come to life in Jurassic Park. I went to the library and started reading all the books on genetics a middle school library might have. I didn’t then and still don’t really know what I was reading, but I just kept reading for a while until my interest waned. Somewhere along the line I got the idea that this was how to be successful:

  1. Read non-fiction books
  2. Learn “useful” knowledge
  3. ???
  4. Profit!

I continued this trend when I first began my interest in computers. I tried staying away from books that covered a product (FrontPage!) since they moved so fast. I read several books talking about compilers, but I never got anywhere. I couldn’t find that piece to take the text in the book and run it on my family Windows computer. I was stuck programming on my calculator which taught me a lot of basics. None stop reading, I kept reading technical books and haven’t stopped for years. I just finished getting an MCSD that took four books. I’m so tired of working like this though, there has got to be a better way of making it in life. In my quest to master one thing I’ve become a polyglot programmer, never feeling certain if the path I’m on is the one that will lead me to the financial success I seek.

That’s what it ultimately comes down too, what technology can one become invested in that will take them to financial freedom they desire. Work for yourself, or at least remotely the majority of the time. Own a nice McMansion home you can decorate during holidays that has a two car garage in a neighborhood you can feel safe in and that has great internet speeds. I’ve found out the answer; there is no right choice.

I jumped ship on Flash development a few years back but even with that I could have continued and move into Flex and Air, both are still being used in enterprise development. That leaves me with trying to make educated guesses about which technology will enable me to reach my goal faster. Technology is wonderful and a kind of hell in that way. You can get work and complete a task in a myriad of ways. Too many choices can lead to over analysis and a paralyzing feeling that I’m making the wrong choice. There it is again, the fear that I’m making the wrong choice to get to my end goal.

There is no right choice, no one technology that will open a door that wouldn’t have opened otherwise. So long as you have your nose in a book and your head down learning you’ll never take enough action, you’ll never see the door open when it finally does. It’s not enough to learn something without acting upon it. So here’s to action over planning, to decisions over analysis in the new year. No one will see all the knowledge you’ve got and point you to that open door. Don’t wait, write, program, start something, because just knowing how to run a program won’t get you anywhere.