The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Suggestions for developing PDA companion for a desktop app

We currently have a desktop app that uses a MS Access database for its data file.  This software is for managing inventory.  We are receiving requests for a PDA version, most of which are Windows requests instead of Palm.

I have seen 3rd party tools like Pendragon Forms, Satellite Forms, and HanDBase.  I have also seen examples using VB.Net 2005.

It seems like the most robust way to go is the Visual Studio 2005 / .Net Framework 2.0.  However, the problem comes with the synchronizing the PDA with an Access database.  SQL Server Mobile 2005 is designed to synchronize with SQL Server or MSDE, but I don't want to install MSDE just for a basic PDA application.

What are other developers using for developing PDA companions to desktop applicaitons?
REL Send private email
Wednesday, July 19, 2006
I was under the impression that a access conduit was available for windows mobile.  That would allow you to send, or receive data to the pda, and back to a access file. You still have to write the software on the pda side however.

And, the fact that visual studio has pda development tools really speaks volumes about the .net environment, and tools provided.

However it really depends on the current tools, and setup that you have now.  I used both Handibase, and also pendragon to develop applications on the pda to work with what I wrote on the desktop side (and, the desktop app was access based).

Further, it really depends on what you need. Often, people think they need all kinds of bi-direction sync software. Further, writing software can be time consuming if you want a lot of features pda side (and, you do NOT want a lot of features pda side since they are hard to use when you have any amount of complexity).

I been in the situation more then once when a company was about to contract me for hire to setup a palm based unit to save the TEDIOUS task of having to enter current inventory levels.

Amazing, but they purchased off the shelf palm units with a scanner (from symbol technologies). They would simply export the inventory file to spreadsheet format (actually a csv file). Note that the software that came with the symbol scanner included some bar code printing software. So, they would scan the product, enter the invnetory level, and move on to the next shelf (in fact, it was the shelves that had a bar code, not the actual product in the bins). They then would take the data from the palm based scanner, and simply upload it to the pc.

The people who supported the accounting package where able to write a import routine in less then a day to process that resulting csv (text file) that had been uploaded. So, really, on the palm programming side, they did NOT even have to hire me and simply used the built in software. There was actually NOTHING for me to do, or write for them in this case.

So, often, you really don’t need a full bi-directional sync of software that communicates between your database and the pda. You simply export a file with the bar codes and products. Most handheld scanners come with a good deal of software to scan, retrieve and display a SINGLE record. You then enter the inventory level. When done, you take the scanner back to the pc…upload the csv file. You then either import, or run a process to read this text file, and update the inventory data into your existing software.

Really, little, if any software on the pda side need be written in this case. So, if you keep a simplte approach in mind, then you can amazing results, and not have to write any software on the pda side.

By the way, if you are going the bar code route, then likey a smart scanner is better then a pda in this case. These units as mentioned often have built in software to scan a product number…and then allow you to enter a value – after all, this is NOT new idea!!!
Often these units are more rugged the pda’s  anyway – they can survive drops on a cement floor. I sure your boss will not be happy if they start dropping those expensive pda’s…as they can break quite easy in a work environment.

In my case, for handibase, I produced a list of customers and what bus/hotel they are departing on. When you have 20 buses leaving a location that represents about 800 people.  Often the people did not know what bus they are on, and what hotel they are going to. With 800 people running around on the ground being dropped off, they often don’t remember, or know what bus they are supposed to be on.  (and who they are staying with, and what hotel etc). So, I built a application to export the data from my reservation software to the pda. Thus, tour guides could look up any persons name (and get things like phone number etc). The tour guides could also tell you what bus number you are on. And, if you filtered the list by bus number, then you have a bus list!! In this application, I used handi base, and the whole above slice and dice of data was built into the database product already. The whole thing took me less then 3 hours of my time. I even exported a room “group” number. So, if you filterd by a group number while looking at a person, you would get the other people staying in their room!! This file was a flat file, but it sure seem like a realtona database in that you could view a bus list, look up peoles names, and also filter by that group number once you find a name to view who is in the room. All with a simple flat file!!

 Of couse, I ony in the above had to download the file to the pda…not sync the other way.

I also have a copy of pendragin, and have using tat for some appcaitones.

In ALL OF the above examples, VERY LITTLE development time (actually almost none) was spend writing software on the pda side. Yet, the resulting productivity, and use of the systems were very good.

So, really, if you keep things simple, then often a  solution can be built without haing to write any software on the pad side. If you do start wring software pda side, then you can start spending more tiem then it is worth.

That company that used the bar code software and the built in ability of the scanner had a working solution in LESS then a day of effort!!  They achieved their goal of not having to re-key in inventory levels from paper and clipboard system they previously used).

So, resist the temptation to have a lot of functionally on the pda side. It is not clear how much features you need on the pda side..but consider using a handheld scanner in place of a pda..

Here is a helpful link to symbol, and they make all kinds of units that would be better then a pda…especially if you plan to use a barcode..

Albert D. Kallal
Edmonton, Alberta Canada
Albert D. Kallal Send private email
Thursday, July 20, 2006
Wow Albert... thanks for the input.  I will definitely consider the "less is more" on the PDA side.

I am getting mixed feedback from our customers and need to come to a decision - some want data collection only while others want data collection and viewing of previous records/history.

While having my current commercial application in Access, I became spoiled on the stability of Access.  It seems like when you get into Visual Studio and Mobile, there are always 3 versions to consider... the previous version that has less features but is stable, the current version that just came out, and the beta of the next version coming out!

Thanks for the input and I will post what I ended up doing.

REL Send private email
Thursday, July 20, 2006
Shameless (but relevant) plug here :).

This is exactly what my ISV does.

Take a look specifically at the ODBC Link download which includes the PDA Application called TracerPlus and the PC syncing application.

Dan Send private email
Thursday, July 20, 2006
A few comments

* .NET compact framework rocks.  Its very easy to develop with.  My only major concern was that the emulator was very flakey for me.  That might not be true for others, however.

* .NET CF + Access blows.  You have 3 solutions, all reasonably unpalatable:

1. Use Pocket Access (a depracated technology) with the open source OpenNETCF dataset wrapper. (

2. Use a web service as an interface to the Access database.  This clearly has some problems depending on your environment.  Although, it has worked well for me in a few cases.

3. Upgrade your Access database to SQL server.  Although you will need to use webservices for this as well.

Some options to explore but based on my experience, you are in a reasonably unenviable position.

Good Luck!

(let us know what you decided on!)
Thursday, July 20, 2006
write your own little data sync tool using xml to marshall the data back and forth.  It will help you handle the data type differences AND allow you to abstract the data layer to work with upgraded database technologies on your desktop at a later time.  So basically, a piece on your pda to write it into xml, then a piece on your desktop to recieve the xml and insert it into your db.  I know of many commercial apps that do this.

Doing it this way would also allow you to easily revamp it to allow tih web based data sync'ing to a web server over an internet connection if you ever go that direction.
Dan Hirsch Send private email
Sunday, July 23, 2006
Symbol also has WIFI enabled scanners too.  Making it possible to talk directly to your database via a WIFI connection.  No need to sync up later.

We use Symbol hand held scanners to do just that to control inventory, receive shipments, and do something called zero-config of all our ISP equipment; all via WIFI.
Monday, July 24, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz