Skip to content

Overview

Jump to bottom
Martin edited this page Feb 15, 2025 · 29 revisions

How To Use The Framework

There are some requirements that must be fulfilled to use this framework:

To create a jar file from source, you can use tools like the java compiler and an archive generator like 7zip, an IDE like Eclipse or IntelliJ Idea or a build tool.

Supported Device Classes

The following device classes are supported by JavaPOS-SPF 3.0.1:

Belt, BillAcceptor, BillDispenser, Biometrics, BumpBar, CashChanger, CashDrawer, CAT, CheckScanner, CoinAcceptor, CoinDispenser, DeviceMonitor, ElectronicJournal, ElectronicValueRW, FiscalPrinter, Gate, GraphicDisplay, HardTotals, ImageScanner, IndividualRecognition, ItemDispenser, Keylock, Lights, LineDisplay, MICR, MotionSensor, MSR, PINPad, PointCardRW, POSKeyboard, POSPower, POSPrinter, RemoteOrderDisplay, RFIDScanner, Scale, Scanner, SignatureCapture, SmartCardRW, SoundPlayer, ToneIndicator, VideoCapture and VoiceRecognition.

In other words: Currently, JavaPOS-SPF supports development for all device classes specified in UPOS 1.15 and device classes DeviceMonitor, GraphicDisplay, IndividualRecognition, SoundPlayer, SoundRecorder, VideoCapture and VoiceRecognition from the UPOS 1.16 draft.

Device classes Lights and POSPower are supported incluing the additions specified in the UPOS 1.16 draft.

Sample Service Objects

Some sample implementations, together with TCL scripts simulating a POS device, are available now. To use these device simulators, you can use any TCL interpreter version 8.5. Since you need some Tcl extensions for some of the interpreters, the recommended source of a tcl interpreter for Windows is BawtTcl:

https://www.bawt.tcl3d.org/download.html (look for Tcl-BI - Windows installer on this page).

If you like to use a different Tcl interpreter: The UDP sample implementations use the TCL UDP extension. You can download it separately from https://sourceforge.net/projects/tcludp/.

The sample implementation for the POSPower device class has been implemented using Java Native Access (JNA) and is designed for use in a Windows environment only. To use this sample, the corresponding JNA jar files must be present in the class path as well.

All sample implementations which support serial communication (COM port, via RS232 or USB to serial) need one of the SerialIO jar files and the corresponding jar files for serial IO or Java Native Access (JNA) as well. The name of the corresponding class, de.gmxhome.conrad.jSSC.JSSCSerial, de.gmxhome.conrad.jSerialComm.JSCSerial, de.gmxhome.conrad.JNAWindows.JnaSerial or de.gmxhome.conrad.JNALinux.JnaLinuxSerial, must be specified in jpos.xml in a property named SerialIOAdapterClass.

The sample implementations for device class GraphicDisplay, SoundPlayer, SoundRecorder and VideoCapture contained in SampleVideoAudioDevice.jar need the VLC media player to work as expected. You can download it from https://www.videolan.org/vlc/index.de.html.

JavaDoc

You can find the JavaDoc pages here.

Testing Service Objects

To test service objects, you can use any POS application that supports the use of JavaPOS service objects conforming to the UPOS standard, up to version 1.15. In addition, you can use JavaPOS test tools, e.g.

Unfortunately, both POSTest tools do not support all device classes listed above. In addition, the original POSTest2 cannot be used to test LineDisplay devices and both devices have problems with shareable devices and - for some device classes - with asynchronous IO.

However, most of these problems have been solved in my fork of POSTest2, but there remain some restrictions, e.g.:

  • Several tests cannot be performed due to plausibility checks that disallow testing of correct error handling.
  • Correct event handling cannot be tested while long-running synchronous operations are active. For example, the CashDrawer method WaitForDrawerClose blocks the complete GUI, inclusive event handling.

To solve these problems, I started to develop the test suite JavaPOS-SPF-Test with GUI, multi-threading and reduced plausibility checks. See https://github.com/mjpcger/JavaPOS-SPF-Test for more details. All devices supported by JavaPOS-SPF are supported by JavaPOS-SPF-Test as well.

Further Comments

Even if UPOS / JavaPOS is a great advantage compared with native, vendor specific solutions, there are some points that remain unclear or that should be explained repeatedly:

  • currency values will be stored always in a 64-bit long variable with 4 implicit digits. Even if a device supports less decimals, the format for currency is always the same: a long with implicit 4 decimals.
  • currency values will sometimes be passed from or to the application as string values. In such a case, some service objects simply pass the value with decimal point, sometimes trailing zeroes will be truncated, sometimes inclusive decimal point. Some service objects pass always the contents of the 64-bit long value as string value, which never contains a decimal point. For example, a value of 23, stored as 230000 within the currency variable, can be passed as "23.00", "23.0000", "23.", "23" or "230000". Keep in mind, that the first four representations in this example describe exactly the same value, the last representation can also be interpreted as 230000, which is not 23. For FiscalPrinter, wrapper classes (FiscalPrinterToDecimalWrapper and FiscalPrinterToIntegerWrapper) are available which can be used if application and device service use different string representations of currency values. It should always be possible to find out which representation application and service expect.

Clone this wiki locally