Currently I’m working with Windows Mobile based barcode scanning devices. With .NET 2.0, actually developing real-world applications for the mobile devices using .NET has become a viable alternative.
.NET 2.0 combines sufficient speed at runtime (though you have to often test for possible performance regressions) with a very powerful development library (really usable – as compared to .NET 1.0 on smart devices) and unbeatable development time.
All in all, I’m quite happy with this.
There’s one problem though: The debugger.
When debugging, I have two alternatives and both suck:
-
Use the debugger to connect to the real hardware. This is actually quite fast and works flawlessly, but whenever I need to forcibly terminate the application (for example when an exception happened or when I’m pressing the Stop-Button in the debugger), the hardware crashes somewhere in the driver for the barcode scanner.
Parts of the application stay in memory and are completely unkillable. The screen freezes
To get out of this, I have to soft-reset the machine and wait half a century for it to boot up again.
-
Use the emulator. This has the advantage of not crashing, but it’s so slow.
From the moment of starting the application in VS until the screen of the application is loaded in the emulator, nearly three minutes pass. That slow.
So programming for mobile devices mainly contains of waiting. Waiting for reboots or waiting for the emulator. This is wearing me down.
Usually, I change some 10 lines or so and then run the application to test what I’ve just written. That’s how I work and it works very well because I get immediate feedback and it helps me to write code what’s working in the first place.
Unfortunately, with these prohibitive long startup times, I’m forced to write more and more code in one batch which means even more time wasted with debugging.
*sigh*
gnegg 