The Pharm2Phork Mobile Client Project was set up to provide a means for mobile devices to act as peers in the network. Support for these devices has been broken down into a few categories based on the devices capabilities and/or resources.

The main categories supported are:

  • PPC 2002/2003 devices.
  • Windows CE 4.x devices.
  • Linux devices
  • Mobile Phones.

But these types of devices may also be used.

  • MMC Devices.
  • Pagers
  • Vending Machines
  • Sensors

It is suggested that you first read the Full Client literature in order to get the full picture of what the system is designed to achieve.

This project was actually created to address two issues.

The first was to aid in the collection of data by enabling scanners, RFID readers, or any other device, to access the peer group whenever a network connection was available. This also included the use of PDA type devices such as the TDS Recon.

The second was to support users of devices where no programming language interface or direct network access existed, to send and receive messages to and from the system. This was accomplished through the use of SMS gateway and peer group surrogate combinations. The group can send and receive messages via SMS including binary data such as tag reads or confirmation messages. Relay peers have been provisioned to provide for the storage of messages while devices are off-line and then complete delivery when the target device is next available.

There were several other considerations taken into account during the initial design stages as well. With media enabled devices, photographs, sound, video and other forms of data would likely be used for documentation and we needed to provide support for them. The general idea, was that in the context of Pharm2Phork, we knew that many of our potential users would be using intermittently connected devices, many of which had no direct access to network resources, often behind strict firewalls, or lacking the capabilities to execute externally supplied software.

One scenario for use is the occasional contributor of data such as an infrequently used transporter. The system generates an event and sends an email message to the company or driver. When the load has been collected, the driver sends a reply to your message and the event is updated and stored.

Another scenarios involves a more sophisticated device that lacks the required program to provide the necessary services, such as where tag or barcode reads need to be collected. In this case you can send a small, pre configured program to the device via MMS. The recipient opens the file, automatically installing the program and the data can be collected and transmitted back to your system. The program is then, if desired, easily uninstalled completing the transaction. Wizards have been made available in the full client to configure these small programs and to define the actions to be taken when sending and receiving data.

In the next few Pages we will describe the options available in each configuration. Most of this is dependent on the capabilities of the actual device but may also, in some cases, be a bit different due to restrictions placed on the device by service providers. It is worth keeping in mind, that there are still many heavily constrained devices in use, especially in the areas where many of our activities are concentrated, due to economic and technical issues. Even in rural Western European and Norh American communities we often see services and devices which are heavily constrained and thus we need to provide support allowing these devices to participate whenever possible.