PDA GUI for MV

A lot of people talk about PDA applications, and almost everyone has some sort of portable intelligent device these days, but there aren’t many in the MV market. I think we can change that.

Nathan Rector is a leading authority on PDA development in the MV market, but despite his articles and Spectrum seminars on the topic it doesn’t look like many MV developers have picked up the gauntlet to create user interfaces for portable devices into their MV business applications. That’s a shame. There are many applications where people could make use of access into their MV system without being at their desktop.

I’ve been doing some PDA development recently and it looks like it will be relatively easy to start cranking out GUIs for MV apps. Well… There’s nothing "easy" about this, but compared to starting from knowing absolutely nothing about the topic, yes, it’s "relatively" a straight-forward process once you know the steps. This would be for apps where the PDA is simply a client to a remote/traditional server running an MV app, and for applications completely hosted on the PDA.

Through the generosity of Ladybridge Software and Martin Phillips, who provided a free personal developer license of the QM DBMS for the PDA platform, I’ve recently installed QM to an old Pocket PC 2003 (ViewSonic v37). QM is running perfectly and I’m confident this is an excellent platform on which to build. Mind you, it’s the only MV DBMS available for portable devices.

I also have a little prototype GUI that works well, though it’s not yet connected into QM. All of the hooks are in place and now I just need to finish that last part. Screenshots of the GUI are below. These were taken from a desktop-based emulator running my application but I assure you that I have installed it to the real PDA where it is also running as expected. You’ll see that there are Delete and Save buttons. The challenge is to make sure that when the user enters an ID or presses the buttons that data is read from the DBMS and written to the DBMS properly.

Think of each screen as being a page of a PDF document that you navigate from top to bottom. With only so much real-estate on the screen, data entry needs to be broken into pages like this. There is a lot of extra space on the screens in this prototype simply because I didn’t want to go through the exercise of creating 30 fields just to provide more eye candy. A real UI will have more fields and group them into pages as it seems logical for the specific application.

Navigation from one screen to the next was implemented using a rocker switch on the side of the device, represented by "+" and "-" buttons on the left side of this particular device. I’ve also added a "Navigate" menu which allows the user to jump directly to any entry page.

Note that the Delete button is available on the first screen but not on the second (or subsequent) screens, while the Save button is on all screens. This was an intentional design decision, the idea being that the user should be allowed to save the record after making any change but deleting the record should only be done from one location. The Clear button only clears the data in the current screen. That was another design decision, and while some people may disagree, let’s remember that this is just a prototype and not a real app – so if you don’t like the behaviour, let’s change it.

The point is that this is a functional user interface and MV developers can start to make those decisions about how they want their screens to work. The only real difference between this and a character interface is that the controls are graphical and there is less real-estate on the screen.