PDA GUI for MV
How do we wire the GUI to MV?
After development of the GUI, the next step is to connect to a database. I’ve written a lot in various places about the value of separating the user interface from the rules and the DBMS. This is a perfect example of why we would do that. The PDA UI here should not be linked directly into a local QM database because that precludes use of a remote non-QM database over a wireless connection. The approach to development is to create a Data Access Layer (DAL) which has functions like Read, Save, and Delete. When the user selects these operations in the UI, the operation in the DAL is invoked – the operation is not invoked directly from the UI event handler! Using another database, and connectivity method, should be as simple as telling the GUI to use a different DAL.
With the local QM PDA database, there is no client library, no QMClient interface yet. I think the only connectivity method we have is to execute the qmpda command (just like the qm command in Windows or *nix) and pass it an account reference, the -quiet flag, and maybe the -stdout flag. I’m discussing this with Martin now. We can’t telnet into the QMPDA even from the localhost PDA itself, the underpinnings simply aren’t there. I’ll post more on this later. Even if we could, that would mean we’d need the DAL to implement a telnet client to loopback on the localhost for connectivity. I think that would create a painful and unncessary performance issue. Wrapping the command line is a bit more elegant and direct, and certainly more performant.
As far as remote MV servers, we "wire" into them by going "wireless". Most PDAs have some sort of networking capability. By using web services, or HTTP/REST, we should be able to connect to a middle-tier web server, and from there we connect into the MV DBMS. That middle tier can use mv.NET, UniObjects, or any other connectivity method one chooses.
Challenges
With PDA development there are a number of challenges that I’ve been struggling with over time. These include:
Which development tools do we use? Being a .NET developer I’ve chosen Visual Studio 2003 and the .NET Compact Framework 2.0, using C# as my language of choice. I’m going to shift soon to VS2008 but I don’t want to lose the ability to write CF2 code for my old PPC. Newer devices support a newer version of Windows Mobile OS and CF3.5. *sigh* There are sooo many details here – trying to understand this is an effort in itself.
How do we target specific devices? Unfortunately you may need to create separate forms for each unique device, since devices have different screen sizes and different features for data entry and navigation. This is a big topic that all PDA / Smart Client developers face.
Which technology do we target? This is also a big topic, with various releases of the Windows CE operating system supporting platforms like Pocket PC, Windows Mobile, and many others. The platform (and devices) that you target must be determined by your target audience – and as mentioned above, you may need different tools to support different target platforms. Let’s also not forget that there are non-Windows devices like Palm, BlackBerry, iPhone, and now Google Android has joined the pack. For now I’m only targeting the one device I have here, which is Pocket PC 2003 – a quite old and outdated environment, but of course still very usable.
Are there other tools besides Visual Studio? Sure, there are many commercial offerings for development for portable devices. The easier your development becomes, the more you need to pay for development tools – that’s the game. Visual Studio happens to be one tool that is capable of developing for a multitude of targets. If you buy a tool that only does PDA development, you’ll just have to buy something else later for other projects.
How do we deploy our code? This is yet another major topic. PDA deployment is done with CAB files. These are the same file types that are used to deploy browser plugins using Object or Embed tags. In short, you create your project as an executable, wrap that in a CAB, then create a Setup project to deploy the CAB to your PDA via Microsoft ActiveSync. It’s not an easy task – I think I’ve spent more time trying to get this area working properly than any other part of this project.
Summary
As always, I don’t do these things just for fun. I do this Research and Development as part of our business model as well. I’m hoping that there are some companies out there that are interested enough in creating a GUI for their apps that they will commission Nebula R&D to do some of the work for them. I am excited about the possibilities and anxious to help developers create new solutions which they can sell or distribute to end-users. To that end, inquiries for development services are welcome.
2 thoughts on “PDA GUI for MV”
Leave a Reply
You must be logged in to post a comment.
Hi
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.
Thanks
Peter McMurray
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.