Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

JavaScript Debugging

Using JavaScript is suppose to make the development easy, but without a debugger anything other than a simple hello world app turns into a nightmare especially when you have to deal with buggy and incomplete core libraries, which is the case with Titanium. For example, if you try to use any existing JS XML parsing and handling code in Titanium you'll be in for a wild ride. Will there be a debugger? And if so, when?

Right now it takes a day or even more to debug Titanium JavaScript code vs 30 minutes (1 hour at most) of native Objective-C debugging. It looks like aside from not having to deal with the Objective-C syntax (that's unfamiliar to most developers) there's no real benefit in using JavaScript and Titanium.

— asked May 20th 2010 by Kyle Quest
  • debugging
0 Comments

8 Answers

  • Thanks for the suggest to write bug free code. I don't know how I couldn't think of it myself… There's a few problems with this suggestion. The main one is that bugs are not always caused by the developer's code. A lot of times it's the platform and its bugs and incompatibilities. Take a look at DOM2 and then check out what Appcelerator has implemented and you'll know what I'm talking about. Titanium is definitely full of them and nobody can deny that… even Apple-style fan boys that declare anything that's not there isn't really needed.

    Plain and simple… print outs are not acceptable for any really complex software because it significantly increases the development time. One of the main values of Titanium was to provide a way for rapid application development. When hours turn into days that value is no longer there.

    There's nothing wrong with pointing out flaws and fair criticisms. If Appcelerator wants developers to adopt their development platform there needs to be a reason for this. Right now the only reason is that people don't have to deal with Objective-C. This is not enough. The cons of using Titanium simply outweigh the benefits. Given the new Iphone ToS restrictions it's really tough for anybody to justify the use of Titanium.

    A debugger is a "must have" feature to attract application developers especially when the official documentation is limited.

    — answered May 21st 2010 by Kyle Quest
    permalink
    0 Comments
  • If Appcelerator is to be used for designing useful applications that tend to be complex, it needs a debugger, period!

    Appcelerator also needs a mechanism for adding new classes (in C++ or Objective C). There is always going to be the need for a new API and the good people at Titanium will not have the time or desire to write it.

    — answered October 30th 2010 by Dominic Sotirescu
    permalink
    0 Comments
  • In my javascript I just create a trace function.

    And then you can easily see the output in the Titanium console.

    If you also want trace ability on the iphone/ipad/.etc then create a new trace window that gets opened by your custom trace function.

    In my app (which is only using the webview) I have this function

    
    var doTrace = true;
    
    trace : function(str)
    {
    
      if ( doTrace === false ) 
       return;
    
      // trace for titanium console
      Titanium.API.info(str); 
    
      // trace on the deploy target (iphone/ipad etc)
      iTrace++;
      $('#info-box').css({display: 'block'});
      $('#info-box').append(iTrace+': '+str+'<br />');
      var box = document.getElementById('info-box');
      box.scrollTop = box.scrollHeight;
    }
    

    As you can see #info-box is only made visible when I perform a trace statement. I've found this method to be quite fast at debugging and the app is a bit more complicated than hello world :)

    During dev time you can place trace statements wherever you need and then switch them on and off with the global var doTrace.

    Hope this helps!

    — answered May 21st 2010 by Justin Vincent
    permalink
    0 Comments
  • This is a nice little trick that doesn't really add anything new to the available debugging capabilities. It's just a print statement wrapper. No breakpoints, no ability to step through, no ability to inspect objects. The lack of a debugger in Titanium completely negates the value and any benefits one may have developing using web technologies. Actually it's not really web technologies anymore because using web views and CSS is the old way of doing things in Titanium. Titanium API is just an API that happens to be implemented in JavaScript. What's the value here???? This API doesn't provide everything you'd get from the native mobile platform API. This API does not result in cross platform applications (the platform API differences aren't even cleaning separated; yes, there are a few platform specific sub-APIs, but then the rest of the common API is littered with platform specific exceptions). There's no graphical UI/interface builder. There's no way to debug applications.

    — answered May 21st 2010 by Kyle Quest
    permalink
    0 Comments
  • Well, I wrote much of the debugger code on the AS/400 and I learned how to rely on traces. Yes, a debugger would be nice, but it isn't necessary. And the suggestion of writing bug-free code may sound funny, but I tend to write code that works the first time because of a lack of a debugger. I code slower since I run the code through my head instead of relying on a debugger, but it works.

    — answered May 21st 2010 by shawn gordhamer
    permalink
    0 Comments
  • You really should give the original poster a break. Everything point he made was valid. Telling someone that a debugger that can step through code is unnecessary is short sighted. And then saying he should simply "write bug free" code is asinine! I'm a fan of Titanium in theory (as I am a big JavaScript proponent) but without true debugger Titanium can hardly be considered a first class development platform.

    I'm sure that the people at Appcelerator know this to be true and are scratching their brains at trying to come up with a solution. Until that day comes, I will sludge my way through with hackaround pre-1990's debugging techniques.

    — answered September 26th 2010 by Donavon West
    permalink
    0 Comments
  • I hear what Kyle Q. is saying, but if you try and create a framework that looks and feels native on multiple platforms, you are going to get platform specific exceptions. I don't see a way around it. I think the future for this product looks very bright indeed. Great job Appcelerator team!

    As for no debugger Shawn G…. yeah, I use to do AS/400 coding also, but that style of debugging is much more productive when you aren't relying on so many external libraries and complexities as today. Is a debugger necessary, no, but for productivity, yes it is. Your keyboard could also have just 2 keys. One to cycle through every character and one to select the character you want. Are more keys necessary? No, but it sure helps with productivity. :) I agree with Kyle on the workflow issue no debugger creates. As you said, you code slower. The idea is to code faster, and deploy on multiple platforms with one code base. A debugger will certainly speed up the workflow along with other things.

    I look forward to a debugger.

    — answered October 25th 2010 by Steven Day
    permalink
    0 Comments
  • Why are you so angry ?
    Things are simple: if you don't like it, don't use it.

    It's very easy to criticize, but what about coming with solutions?
    What about building yourself a solution that "works" with UI builder and full debugger and so on?

    Then give it for free like the guys at Appcelerator are doing…

    Or even more simple.. why don't you write bug free code?

    — answered May 21st 2010 by Dan Tamas
    permalink
    0 Comments
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.