PDA GUI for MV – Success

What other challenges are there with this project?

Basic GUI stuff is out of the way. The interface to the MV DBMS is done. What’s interesting is that none of this relies on .NET, so now that the server interface is complete and a prototype GUI has been created, any GUI can be refitted in it’s place. That means we can use Java or even start a local web server and create a browser UI that connects to localhost for data. But that’s an extension of what’s already there. Another extension would be a separate client going through the same interface, maybe one that autosyncs data between the local QM environment and a remote one whenever the systems are within range via wireless or ActiveSync connections. All of this is now within reach.

There are things I haven’t even discussed but they’re just details. For example – the GUI needs to start an instance of QMPDA to make sure it’s running and ready to respond when required. I need to make sure I properly terminate QMPDA as well. There is a thin mechanism for getting error messages up to the UI but the code doesn’t do a lot of error handling. For general purpose development, each form follows a consistent structure, and they are linked together like pages of a book, but the forms aren’t perfect in the way that they flow from one to another. This is all just grunt coding stuff.

The big deal in taking this further would be with deployment. Coding a project like this requires one assembly (a .exe file) for the GUI itself, one assembly that assists with installation, one assembly that bundles the other two into CAB files for deployment, and then there is the project that creates the MSI and Setup files for the whole package. It sounds complex – and it is – but it’s quite manageable once the solution is created and development is underway.

The problem is that deployment package is different for every version of Windows CE, every version of the Compact Framework that needs to be supported, and for every CPU that’s supported for various mobile devices. The CPUs for example include ARM, MIPS, X86 and a dozen related variants. I have a lot of sympathy for developers who need to target "everything". The reality with this sort of development is that a product will be created that will support a popular subset of hardware/software permutations and the more esoteric ones will be provided as demand dictates.

Where to from here?

Frankly I don’t need to do anything more. I’ve accomplished my goal which is just to make this work. Martin Phillips took the effort to make QM work on a portable device – hats off to Martin and many thanks for creating a unique product for our market! But to my knowledge the people using QM PDA are still left using character interfaces in a GUI-oriented world.

I took the next step and now we have GUI for QM PDA. Is it free? Well, you can take these articles and run with them, so sure it is. I’ll probably open source this whole thing at some point but you have to remember that this was intended to be a prototype and not production code. Is there a tidy toolkit that you can download or buy and sell to your clients? No, and I’m afraid there probably never will be. The idea here is that we can create whatever we want, but we can’t buy things like this ready-made.

At this point I’ll dabble with this only occasionally, maybe refine the UI to make it look a little cooler for demos, but I need to get on to other things that generate income. I don’t have a lot of faith that people will jump onboard the mobile revolution because of this effort but I sure hope MV developers out there remember that it’s all possible – and remember that a lot of people pay a lot of money to get their apps where they want them. So I strongly encourage developers to talk to users, consider new markets for mobile users with existing apps, and give me a call if you think there’s something we can build together.