Visual Studio 2008 – A Device Explorer For Efficient Debugging
Posted by Dan Vanderboom on December 13, 2007
Being a developer of mobile devices and a seeker of efficiency, I am plagued by an inconvenient design in Visual Studio. I program against multiple devices. I switch from one to the next, from a Symbol MC50, to an MC70, to an MC9090, and sometimes to headless units and kiosks. During heavy testing phases, I slam out some code and deploy it to one device, hand it off to our testing department, only to grab the next available device, start working on that one, and continue rotating in this kind of crazy fashion.
The problem is, I have to keep changing the IP address that I’m connecting the debugger to. This is done by going to Tools—Options—Device Tools—Device, then sometimes scroll to find the right device on the right platform, highlight it, select Options, make sure TCP Connect Transport is selected (it usually is), press the Configure button, ensure Use specific IP address is selected, type in the new IP address, and then click OK three times in three different windows. Then on the device I have to enable it for wireless debugging by running two separate programs (conmanclient and cmaccept), and also go to Tools—Connect to device…
Here’s what that looks like:
There’s only one conclusion I can draw from going through this grueling process, and many other, similar experiences: the compact framework or IDE teams don’t think much of their mobile developers. (Either that or I’m the only guy developing against more than one device.)
Okay, so I’m being a little melodramatic. But really, imagine going through that process many times every day. Some days it could be several dozens of times. Testing in an emulator is all well and good, but when your mobile devices have things in them like integrated barcode scanners and RFID readers, sometimes there’s no substitute for testing on the real thing. An emulator can’t do everything.
I have a real simple idea, and I know it’s going to sound crazy. When I choose to “connect to device”, why not just prompt me then and there what I want to connect to? Let me edit an IP address right there! Why make me go through a million mouse clicks, and dig through layer after layer of user interface dialogs and configuration screens? Help, help, I’m drowning in inefficiency!
The same concept goes for a great little application called Pocket Controller, made by Soti. If you’re a mobile developer and you don’t already use Pocket Controller (or its big brother Mobi Control), go to their website immediately and download it! Pocket Controller is the best $36 you’ll ever spend for mobile development. When we sell our systems, we sell a copy of it bundled in with ours. It enables us to perform remote installations and troubleshooting, and allows our customers to provide remote support.
That being said, the ultimate device connectivity interface would be a Device Explorer. I’m talking about a tool window in Visual Studio that would display a list of registered mobile devices, optionally display information like Windows Mobile version and flavor, and indicate with some icon or color change which ones were currently reachable. This tool window would allow you to right-click or otherwise select one, and debug-deploy to that device just like that. Perhaps some debugging agent would need to be installed on the mobile device to allow this, but this would be greatly worthwhile. The device-side debugging agent could be some kind of TCP server, and could run the conmanclient and cmaccept executables necessary to accept a debugging session, without having to launch these from the device manually. This would be the ideal experience, I think.
I design user interfaces with simplicity and efficiency in mind. The users of my software typically work in warehouses, delivery vehicles, laboratories, hospitals, etc., and they repeat the same tracking activities many times a day. I work very hard to eliminate any useless steps, because a single extra click repeated a hundred times is a waste of time; and it’s aggravating that the tools I use to create sthis software is itself very inefficient in many ways. I still love it, but it’s a definitely a love-hate relationship. I know I could save two to three hours a day with the potential I see for improvements like this one. I’ll be writing about many more in the near future. Some of them may become Visual Studio extension products before too long. If you run into any of these yourself and come up with some good ideas, I’d love to hear about them. I’m curious to know how much demand there is for certain kinds of enhancements.