Debugging Titanium Applications using Safari Web Inspector

Debugging Titanium Applications using Safari Web Inspector

Debugging is one of the most frustrating aspects of software development of any kind – it is also one of the most essential. Finding a malfunction can be time consuming; therefore, it is important to have effective tools that can decrease your debugging time. For Titanium, most of my debugging consisted of log statements and alerts. While this method can be useful, it can also be a little time consuming to rebuild and to log a different variable, collection or model.

One of my coworkers saw me using this log for debugging and suggested an alternative: using Safari Web Inspector. I was very surprised at how easy it was to set up and how effective it can be throughout the process. This one line is all you need to add to your “tiapp.xml” file in your project:

`<use-jscore-framework>true</use-jscore-framework>`

under the <iOS> flag. Unfortunately, this method only works on an iOS simulator. Once you have updated your tiapp.xml, build your project and navigate to the page you would like to inspect. Next you will need to open Safari; if the develop tab isn’t visible you will need to follow a couple extra steps:

Select the Safari tab from that dropdown navigate to preferences then check “Show develop menu in bar.” After the Develop tab is visible you will open the Simulator option and then select JSContext.

This is where all the magic happens. The files where breakpoints can be inserted will be visible on the left panel of the screen. Breakpoints are very convenient for stepping through your code and seeing exactly what is happening. I suggest opening the right panel when the breakpoints are hit. This is where you will find local variables and can also add Watch Expressions. Watch Expressions is the place where you can add the variables that you would like to keep an eye on. You will be able to see and follow each variable through every step of your code.

The bottom console is also a very helpful aspect of this debugger. I use this for taking a look at any model or collection to inspect in detail what they contain. This has been a lifesaver for me. It makes it easy to investigate exactly what is going on with any unexpected behavior with your models or collections.

The safari web inspector has it’s problems and will, from time to time, crash the app – but overall this tool has helped me immensely debugging my titanium apps. It makes it so effortless to nail down exactly where the problem lies. As much as we all want to have flawless code without bugs, they will appear every once in awhile. However, this tool can save you from the frustration those bugs can cause. As I stated before, it is very easy to set up, so jump in and play around with it a bit. Have any questions or comments? Feel free to share your your tricks for debugging. Also, you can find our latest apps and check out our work here.

Editor: In case you need to know other ways we used to debug Titanium Apps, please also check Appcelerator Titanium iOS Debugging with XCode or Rapid Titanium WebView debugging with Chrome Developer Tools

 

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

Understanding and combating coder's block

It’s very hard to explain to non-coders how artistic coding really is. People who use software are constantly complaining about usability issues, but when they think about the code behind the software they think “it either works or it doesn’t.” That is not how coders think of coding, and the process of coding isn’t mostly about writing code that runs. Building software is mostly two things:

1. Staring at a blank screen with a goal in mind, such as “I need something that accomplishes x goal” and determining the best strategy to accomplish the goal

or

2. Looking at something that already accomplishes a goal and determining how to accomplish the goal better.

The more experienced you are as a programmer, the more of your time is spent on those two things and the less that is spent on actually writing code. And in this way, it is almost exactly like writing prose or poetry. Great writers are really great at going from nothing to something in a way that makes sense and then taking that something and distilling it into its most elegant and clear form. Great writing isn’t the writing that uses the most obscure wording, it’s writing that keeps a coherent structure and conveys its message effortlessly in the readers mind. When a writer can’t conceive of how to do one of those two things, it is called writer’s block.

And this is where coder’s block comes from.

Coders block is when you’re staring at a cluttered homepage for your company and stop being able to conceive of how to make it simpler. When you have a five click application that needs to be two. A database that is running too slow, but a faster structure simply aludes you. You stare at your screen, you’re willing to work, but there’s nothing you can do: you’ve got coder’s block.

Interestingly enough, the way I combat coder’s block is by writing, and the way I combat writer’s block is by coding. Despite their processes being so similar, their implementations live in different worlds and speak different languages. When I’ve been writing code, all of a sudden writing in my native tongue feels easier. When writing elegantly becomes too difficult, solving a purely technical problem that actually has a solution (debugging) feels like a breathe of fresh air.

And the point of all of this is…… crap, now I’ve got writer’s block, off to write some code!