There was a nice post on Hacknot this week called “Debugging 101” that covers approaches to debugging; However, what I found most memorable was the reminder that “debugging” still carries a connotation of “failure”.
I’ve certainly met guys who think that debugging is something “junior programmers” do, and I always feel sorry for them. If you’re afraid you might code a bug then you’re prematurely censoring your creativity. Now I’m not saying that you let your cat fill in your method definitions for the sake of art (even though my cat is quite handy with the keyboard), but rather that when you tinker and build things no one has built before, you need to keep an open mind and accept that your first attempt might not work — and that’s fine! You’ll learn something. You have to expand into new territory if you’re going to learn something new, and when you’re in that new territory the odds are pretty high that you’ll goof something up on your first go.
Back to the topic at hand, I was a little disappointed that the article only covered old-school approaches to debugging (ie., nothing new.) I talk to a lot of mobile application developers as part of the day-job, and “better debugging tools” is one of the most frequent request I hear. My follow-up is generally, “what exactly would help you debug better?” — and sadly, the answer tends to be “uh… I’m not sure. I generally just put ‘print’statements into to code.”
So going beyond print statements and chatting up the wooden Indian, what would help you debug mobile applications?
C. Enrique Ortiz 11:38 am on April 20, 2006 Permalink |
I haven’t read “Debugging 101″ above, but for mobile, you want a test environment that behaves *exactly* as the handset itself – from the OS, to VM, to firmware (releases), with the ability to do on-device debugging – breakpoints, memory watches, multiple threads, and stack traces, to name a few.
ceo
C. Enrique Ortiz 12:17 pm on April 20, 2006 Permalink |
Oh, and forgot to mention, that the debugging environment must also provide support for printf and system outs!!! ;-)
ceo
Artem 12:19 pm on April 20, 2006 Permalink |
My request would be the ability to track how messages go to/from server and client. One of the most difficult to debug issues is a mysterious server crash after some sequence of client calls. Since the call goes through the system pipes and scheduling it is impossible to just step from client to the server code.
erik 1:42 pm on April 21, 2006 Permalink |
Enrique — Thanks for the comments! I started writing a response and it grew so long that I decided to make it a (coming soon) blog post instead ;-)
Artem — Cool site!
Can you give a more concrete example of the interaction you’re describing? Is this in the context of messaging applications, for example, or more like a midlet opening a connection to a server?
From an emulator, it should be possible to capture all the data flowing over the wire. For example, I use tcpflow quite frequently when debugging things like XML-RPC clients. The packet logging obviously doesn’t have to be built into the emulator when you’re running the tool on a PC. From the handset it’s naturally more difficult to intercept network data. In this case you may have put the logging on the server side and possibly write a small app that can replay the logs once you’ve found an error case.
The holy-grail of on-device-debugging might help here as well. If you can catch an exception in a debugger and directly inspect the device memory you might be able to do without packet logging all together.