Problem

Display-Messages/Text is nil/null. The message of the terminal can not properly parsed in the ECR. It could be that it worked well on the Prolin devices and does no longer on android devices. The main reason is that the Android devices are much faster. Therefore, its important that the notifications are processed properly. 

Solution

The display notification for cardholder is sent first:

1<?xml version="1.0" encoding="utf-8"?><vcs-device:displayNotification displayType="CARDHOLDER" xmlns:vcs-pos="http://www.vibbek.com/pos" xmlns:vcs-device="http://www.vibbek.com/device"<display><line/><line>Transaction> OK</line></display></vcs-device:displayNotification>

The length of the message is 271 bytes, and the length is correctly encoded in the previous TCP packet:

(271 is 0x010f hex)

Same applies to the display notification for attendant.

The length is 264 bytes (0x0108):

And the display notification follows:

Which is:

1<?xml version="1.0" encoding="utf-8"?><vcs-device:displayNotification displayType="ATTENDANT" xmlns:vcs-pos="http://www.vibbek.com/pos" xmlns:vcs-device="http://www.vibbek.com/device"><display><line>Verarbeitung OK</line></display></vcs-device:displayNotification>

Please note, that in the same packet, there is also printerNotification -  But this is perfectly normal for TCP, as this is stream protocol, so we can’t assume that the whole XML message will be in a single TCP packet, nor that a single TCP packet include only one XML message. Moreover, in theory it is possible, that TCP packet will include only ending part of one XML message, and the beginning of another. This should be handled in the application layer, and that’s why include the 4-byte header before each XML message.

The function receiving a message should be implemented as follows:

Of course, there should be timeouts and error handling added, but this is the basic algorithm of how it should be implemented.