PDA GUI for MV – Success

Good progress was made today. I now have a working GUI on my old PocketPC, operating on data in QM running locally on the PDA itself. If you don’t read anything else, just know that this can be done for any of you, and by many of you, with or without live or scheduled syncs to main servers. I may add a video here later if time permits.

• The DBMS and client are both on the PDA – this is not networked to a remote server.
• This is not using a terminal emulator or browser – this is a full application.
• This solution was written with Visual Studio .NET, the same toolkit I use for most other projects. No extra components were required for connectivity, no special toolkits for mobile device development – there was no cost other than time for doing this special development.

Let’s not discuss why we should or shouldn’t have the DBMS on the device – not yet anyway. For this discussion the current configuration has the DBMS on the device. Let’s also not get into which is better, thick or thin client. There is no "better". Different users want different types of solutions. I can get into some of that discussion later, but for now let’s just discuss "how" to make it work a certain way, not why.

Communications between the GUI and QM PDA

As mentioned in a prior blog, I was having a hard time linking into QM because there is no QMClient API and no Telnet interface in the QM PDA implementation. So how do we plug in? Well, I decided to "order off the menu". Rather than trying to interface directly into the environment I chose to use file IO as the data exchange mechanism:

• The UI application writes a structured message into the local file system, to a directory which was created from QM as a DIRECTORY file.
• QM is polling that path, sleeping for 1 second before it checks to see if there is anything new to process.
• When it finds data to be processed, it reads it in, processes it, then writes structured output to another directory.
• The GUI app is now polling that output directory, looking for very specific data that confirms that QM is done processing and that it’s OK to start reading the results.

We can do that sort of asynchronous processing with any MV environment. We can do it with a web interface, indirectly linking Apache to an MV DBMS. Or for example, we can create a Linux desktop application that works against a localhost DBMS. Many developers do this for many applications.

But many developers also regard that as being a very primitive sort of communications mechanism. Well, I agree, but what are the alternatives here? Not only is file IO not elegant, but it could be very slow as well – depending on how it’s coded. In this case there is one user on portable device. We don’t need to be too concerned about scalability, users waiting in a queue for transactions to be processed, record locks, or other issues associated with multi-user environments – especially in a disconnected topology. So leaving elegance at the door I forged ahead.

You’ll notice that I said all messages need to be well structured. In recent blogs I wrote about the differences between data transport mechanisms and the data structures that are put on the wire. A transport needs to move any sort of data across the wire reliably. The data structures are recognized by the client and server processes, packed and parsed on both sides, and the raw data extracted out of the structures is used for whatever purpose required on both sides. For this little exercise I created a functional but volatile protocol for reading and writing data items.