Traits of software development for portable barcode and RFID readers
We create software for Portable Data Terminals (PDTs). Even more – we know how to do this better than anyone else!
Throughout 10 years of working experience we have solved dozens of tasks related to the usage of this specialized devices. PDTs are usually used in businesses related to manufacturing, warehousing or automated identification of products and supplies. Perhaps, only startups or small businesses can operate without using portable data terminals. But sooner or later owners of such businesses realize that keeping record on paper doesn’t work. This article will be helpful for those considering their business automation by means of such equipment.
What are PDTs?
People usually understand this combination of words as a specialized mobile device equipped with either a laser barcode scanner or a RFID reader, Wi-Fi and GSM adapters and other specialized hardware. PDTs are also known as Mobile Data Terminals (MDTs) or Mobile Digital Computers (MDCs) or Wireless Barcode Scanners or handheld computers. They often have certain protection rate, so they become weatherproof and attrition-resistant in order to be suitable for the use in a wide temperature range and corrosion environment. Historically, the most popular operating system for them is Windows Mobile/CE. Only recently Android versions have also come up. Basically, this is a full scale handheld computer, which can communicate with ERP system on a real time basis and complete a wide range of different tasks.
The main purpose of PDTs is automatic identification of products by means of barcode reading and data collection. Moreover they can also perform a function of intellectual processing as there is a full-scale operating system installed on the computer.
There are many appliances of this equipment such as warehouse inventory accounting, stock taking in stores, ticket verification, and so on. Usually each business has their own specific requirements for the software installed on PDT as well as their own business process. Most significantly, scanning a barcode with a laser or a RFID reader is distinguished by high speed and accuracy. That is why these devices have no alternative in businesses related to processing a great amount of inventory.
There are a lot of examples of how this equipment is used. Here they are:
Stock-taking in a shopping area or a warehouse, reception and shipment of any inventory stocks, data collection on assembly lines, automation of sales representatives and merchandisers, ticket scanning in trains, accounting of attendants of public events. In other words, such equipment is indispensable in every field where quick identification and data collection is required. A simple example of a use case is an accounting system for medical gowns, which we created for The Scripps Research Institute recently.
What software is used for PDT?
It is clear that device manufacturers can’t predict all their use cases. That is why a brand new PDT that you have just purchased will only have a standard set of programs for configuration and diagnostics. All the manufacturers of PDTs supply their own SDK which is used by third party software developers to work with the specific device’s hardware. In some cases PDTs can be supplied with preinstalled “out-of-the-box” software packages, but mostly they are appropriate only for basic scenarios like collection of barcodes. For mature ongoing businesses it is usually necessary to modify such software or to develop a new one.
Not many businesses can afford the in house development, because it is quite costly to hire on a permanent basis developers, who have such a specific expertise and skills. Mostly this kind of software is developed by local system integrator companies that constantly deal with customers who need such software. iQueSoft can also develop software for PDTs. For development we use Visual Studio, C#, .NET Compact Framework, SQL Server CE.
What kinds of PDT do exist?
There are about ten manufacturers of devices of this class. The most widely known ones are Motorola (Symbol), Honeywell (Metrologic), Bluebird (Pidion), Psion Teklogix, Cassio, Intermec, CipherLab. They produce models compliant with the IP 54 standard (protection against dust and moisture) which are capable of working at extremely low temperatures, from -20°С up to 60°С. A 650 nm laser makes the scanner beam visible even in daylight, and their rugged case may withstand a 1.2 meter fall onto a concrete floor. The list of on-board equipment may also include USB, IrDa, Bluetooth, Wi-Fi, GPRS, RS232 adapters, laser or optical barcode readers, RFID, magnetic tape and other type of readers.
PDTs can be connected to portable printers via Ethernet, Bluetooth or physical cable, and they can generate labels and documents. Portable and networked printers make this capability convenient for printing barcode or product labels at the point of use, as well as invoices, manifests, and a variety of other reports.
Special considerations for software development
Despite the availability of manufacturer SDKs and support for most popular development tools, software development for PDTs presents specific challenges which must be taken into account in advance. For example, it is crucial to make user interfaces as simple as possible because in most cases terminals are used by people who are not experts in computers. Since the screen size is rather small, reading on the screen becomes a problem when large amounts of data needs to be displayed; for this reason, the information has to be prioritized and presented piece by piece.
Writing a universal software that would work the same way on different device models is a challenging task because the SDKs may vary, as well a procedures of automatic installation and configuration are device specific; furthermore, operating systems vary as well, albeit not very significantly.
There are significant differences in software developed for offline and online modes. Offline mode – is when software can work without access to a network. Online – most often mean, that software require a constant connection to the server or ERP system in order to operate. In the case of offline use, one has to deal with the system’s limitations on the size of RAM and ROM memory storage. In our experience, there have been cases when customers stored databases containing millions of records on the device, and handling this required employing a variety of tricks. In the online scenario, all data is stored on the server, but the user isn’t able to synchronize data when there is no internet or WiFi connection.
If the software supports both modes, rather nontrivial approaches are used in order to make the transition between the online and offline modes transparent to the user. When the connection becomes available, the data that have been saved in offline mode have to be asynchronously uploaded to the server. This makes data validation on the server more complex. Special rules and measures should be considered to rollback failed transactions.