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.
2 thoughts on “PDA GUI for MV”
I am keen on seeing the QM PDA development unfortunately the first couple of clients I have in mind only need a couple of licences so I alone cannot justify Martin’s efforts.
Firstly any PDA development has to be able to stand alone even in Sydney there are significant areas without wifi coverage and the forests of Tasmania are definitely off the wifi map. Both of these places are areas where the simple invoice recording systems I plan are needed, and the business rules being contained in the PDA are essential.
The connection method is of particular interest. My initial thought was why not use the existing browser technology as this fits in with larger developments and there are mini PDA web servers available.
MY next step was Windows forms using Visual Studio 2008 and the wifi developer. In this case the use of the QM EXECUTE command is not an issue as there is only one user.
Then Winnix announced that the terminal emulator works on QM PDA and whilst this is not a GUI it does bridge a gap nicely to get the product out there. However I see in the blog that Telnet is not available so how does Winnix connect? This may clarify some of my other issues on CDP.
You’ve hit on many key topics, Peter. Thanks for your comments.
QMPDA doesn’t have a telnet server and no QMClient. There isn’t any "remote" way to connect into it. So you can’t browse into it or use Winnix. I need to write this bit of connectivity myself.
My current approach, as you suggest, is to use a command-line like:
qmpda -quiet -aPDA.ACCT
From there I can push/pull data with a custom API as described in recent CDP threads and blog entries. (You see, there are practical applications for all of this rhetoric…)
Due to limitations in the feature set of the PDA, this isn’t as easy as with a full version of Windows. I need to manually work out issues interacting with a command-line process – things that are handled automatically in a PC. I’ll discuss this with Martin over the next couple weeks. I’m only about 50% confident in my ability to do this part alone.
It’s possible that a more modern PDA would not have the limitations, I need to research that. I could also commission someone to finish that specific connectivity segment for the older devices. But with no funding whatsoever, this is all way on the bottom of the priority list, and I’m not inclined to pay someone to do development unless someone tells me they have end-users waiting to pay for the results.
So we’re very close to seeing all of this work in harmony – nevertheless it may still not get done. As we’ve discussed in CDP, business requirements need to drive the technical decisions.