Kiosk software guidance

点点圈 提交于 2019-11-30 14:18:30

Speaking as someone who has actually implemented a Flash application targeted for a kiosk environment, I would highly recommend against using it for the following reasons:

  1. The memory management is not good enough to leave an application running unattended for days/weeks at a time. It will leak memory and you will eventually have to restart it. Just Google for 'Flash memory leak' to get an idea of how many issues there are with it. They've supposedly improved memory management in the most recent versions, but to be honest, Flash is mostly targeted at the browser where users will close the Flash tab/window after interacting with it for a few minutes, so they haven't spent very much time optimizing its memory usage.

  2. The error handling isn't robust enough to deal with an extended running environment. If your app throws an error for any reason, the player will basically stop completely until you restart it. Writing to error logs is also more difficult than it should be due to (3).

  3. You are sandboxed in a Flash environment and can't directly access things like card readers or other external devices, or write to the system. Using AIR might help you get access to the file system, but not much beyond that. If you want to access external devices you'll have to write a proxy that sits on the client and sends the relevant data to Flash via a socket. If you do decide to use sockets to communicate with your Flash client, be prepared to pull your hair out deciphering Flash player's security policies.

Basically Flash was built for an entirely different environment than a kiosk, and therefore is not very well suited to the task. I would also recommend avoiding using a web based interface, because of the same difficulties associated with accessing hardware devices. Oh and for the love of god don't run Flash on Linux. The Linux Flash player is 234234 miles behind the Windows version and will give you a massive headache.

As far as communicating with the card reader, generally you interface with a card reader over USB, and the card reader can be placed into 'keyboard wedge' mode or HID mode. In keyboard mode the card reader will read a card swipe and output a plain text string containing the swipe contents as if it were a keyboard, and you need to parse that string to get the data out you want. HID mode is a little cleaner and you interact with it by reading swipes off of the USB device.

Of the options you listed, your best option (unfortunately) is probably writing some kind of Java or .NET app that can stand to run in a 24/7 environment. If you need to access printers or other hardware devices (to automatically print a receipt for example), then Java and .NET have very good support for the OPOS standard, which is the standard interface for talking to receipt printers. As far as Linux vs Windows, I've seen both used successfully.

BTW if your application is processing credit card data, don't forget about PCI compliance :).

Use a Web based application and write the UI in HTML5.

As for the software on the kiosk, I recommend Webconverger. Disclaimer: I'm the founder of this open source project.

You should get an independent payment device and match up the receipts manually.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!