News

Notes from the PocketPC Front

• By Mike Gunderloy
• March 8, 2004

I just finished a couple of weeks of PocketPC development for a client (including a lovely pair of near-all-nighters over the weekend, which is why this story is a bit late getting posted). I had so much fun doing this that I thought I'd share a few lessons learned. This wasn't the first time I'd worked with the .NET Compact Framework (.NET CF), but it was the largest project I've pulled off with this tool (and it got larger as the customer discovered new requirements en route to the final product; I'm sure you can sympathize with that experience).

Microsoft has gone to fairly great lengths to promote the point of view that using the .NET Compact Framework to do PocketPC development is just like using .NET to do desktop development. Well, yes, but...

The IDE is the same, and that's nice. You can indeed write .NET CF applications in Visual Studio .NET 2003, and by and large it works. There are rather more rough edges to this than there are with desktop applications though. Two that I hit repeatedly:

• Every once in a while, for no reason I could ever determine, the IDE would stop recognizing forms as forms, and instead insist that they were simply class files. They'd show with the class file icon in Solution Explorer, and could only be opened in code view. Eventually, I discovered that Debug, Rebuild All would cure this.
• After a while, the debugger lost its ability to push new versions to the device. The Output Window would show all the files downloading, it would insist "Launching Application" and then...nothing. The cure to this one proved to be resetting the device, though I wasted considerable time rebooting my development box before discovering that.

There's a more subtle, but ultimately more devastating, difference as well. Testing a CF application just plain takes longer, because of the delay for pushing the bits over to the device. So when you hit F5 to have a test, there's this agonizing pause before your code starts running. More than once I found myself forgetting which code I was planning to test (this got worse during the aforementioned near-all-nighters, of course). Big applause, though, in that debugging really does work; I had no trouble using the IDE to step through code running on the device. Be nice if someone ported some unit testing tools.

It's nice to have the same Framework on both the desktop and on the device. Or rather, it would be nice, if it ever happened. In reality, the CF is a small subset of the desktop FCL. If you're new to .NET CF development, expect to spend considerable time trying to figure out clever workarounds for classes and methods that you suddenly discover didn't make the transition. It's almost as much fun as writing VB4 code. The OpenNETCF.org Web site can help quite a bit here, though I was unable to get their latest all-encompassing SDK integrated with my project due to time constraints. But the forums there contain a wealth of information.

The data access story in the .NET CF is pretty rickety. For compatability with older applications, both on the PocketPC and on the desktop, this application had to use Pocket Access (.cdb) files. This was a huge problem, as the .NET CF includes no support for these files at all. In The Hand produces a glue component to let the .NET CF use ADOCE (and at a very reasonable price). It works, but on larger sets of data the performance is agonizing. Retrieving 4,000 rows out of a 20,000 row table left me staring at the wait cursor for a rather long time. (I also had a flaming argument with the customer about the wisdom of displaying a grid with 4,000 rows on a device the size of the PocketPC, but that's another story). I can understand that Microsoft wants to target scarce development resources, but really, SQL Server synchronization is not a good answer for many applications.

I was also astounded to discover (at the very last minute) that printing support is utterly absent from the .NET CF. Given the connectivity of most PocketPCs these days (able to hit printers via IR, or Bluetooth, or wireless), this is just plain silly. Best bet: The HP Mobile Printing SDK, which you can sign up for without paying them any money.

So, after a couple of weeks mired in the .NET CF, what's the verdict? Well, I've worked with other tools for the PocketPC, and this is definitely the best that I've used so far. But the next time I have a PocketPC application to develop, I'm going to budget some extra time and use it to evaluate some of the competing platforms more seriously. In particular, AppForge Crossfire and iAnywhere's M-Business Anywhere (both of which I've experimented with) seem likely to have their own set of strengths and weaknesses. It's definitely not a one-horse race.