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.

2 thoughts on “PDA GUI for MV – Success

    • I think there is an alternative.You can use sockets. JD3 is an alternative. If you translate the BASIC code of JD3 (the socket instructions of D3) to QM and you use the JD3 classes for .Net, I think you can write a real mobile application with QM on PDA. I don´t know if it is a good alternative.Usually, we write small applications with D3, JD3 (.Net classes) and .NET (desktop and web applications). We are analyzing the use JD3 withQM.Saludos,Marcos Alonso Vega

    • I think that’s a good idea too, and I didn’t think about it. I do have extensive experience with sockets however and we both know it’s not easy to get socket comms working "just right". I’ve been thinking about opening some or all of the source for this project. File IO would be useful to anyone who knows BASIC but for some people socket IO might make the software unmaintainable for some people.

      The .NET code has a separate Data Access Layer from the GUI, and there is an IDAL interface which defines the requirements of any DAL. This allows us to easily substitute network access via HTTP and web services for the existing on-board File IO. So assuming people take interest in this project, we could actually have several DAL classes and people can choose whichever one for they want for specific purposes. We’ll see.

      Thanks for your comments to the blog, Marcos!

Leave a Reply