4 challenges with POS application development
Creating applications for point of sale terminals and installing these across your network of terminals is a challenging task.
This article focuses on four challenges that developers of this type of applications face: programming in C, creating different code for every type of terminal, run this code to its respective compiler and getting the application onto the POS terminal.
Programming in C
Forget Visual Basic, Java, Ruby and other programming languages. POS development is done in C. Most of time in a basic version of C without the support of the many libraries that are available to make it easier to use IO, mallocs and other functions. Understanding and coding in C requires a lot of experience.
A code example like the one below:
tableMem[y][x / 8] |= tablePixel[x % 8];
It has nothing intuitive to it. (For those interested: it is a bitwise operations with memory)
Writing a driver to control a LCD display or keyboard is difficult but still relatively simple compared with the code necessary to control smartcard readers, printers and wireless cards.
Programming in C is hard work, it is time consuming and requires a lot of expertise. And this isn't cheap. Good programmers are hard to find and expensive.
Operational System
Every terminal has a different operating system, even different models of the same brand can have a different OS running. This means that every model requires a different version of the application.
Consider the code below, used to display a simple text:
VeriFone Verix
display_at(0, 0, "Hello World", CLR_EOL);
Verifone Nurit
GrphText_Write(0,0,"Hello World",FONT_7X5,strlen("Hello World"),false,false);
Sagem
hmiADDisplayText(handle, 0, 0, "Hello World");
Notice how different the code is for each of the models. And this is just to perform a simple function like displaying some text. When you consider the more complex elements of a POS terminal like a printer, Ethernet card or smart card reader the code quickly gets complex.
And this process has to be repeated for every model, each requiring a different approach to the programming.
Compiler
Every application for each terminal has a different code. To compile this code and turn it into a working application you need a specific compiler for the terminal.
And this isn't a Java compiler which you can download for free of the internet. In order to get the SDK you have to be a recognized partner of the terminal vendor. And you probably have to pay for the compiler inside the SDK. And these compliers are expensive. An ARM7 compiler used to create software for VeriFone Verix for example, costs around 15.000 dollars.
And this only compiles your application for VeriFone terminals. For Sagem terminals, you will need a different compiler.
Updating
If you have managed to code your specific application for each terminal you still have to get the application on the POS terminal.
After each compilation of your code, you have to upload the application to each of your terminals. Manually. With a network of 10 terminals this isn't problematic. But when you have 2000 terminals spread across the country it is a problem.
Comments