Rewriting the application always takes much longer time then you think. The POS was ready for the new season but the admin part was missing and was only implemented during the first month. On the other hand, the new architecture splits the deliverable code to the kiosk and admin packages so admin updates do not affect kiosks and the kiosk part is smaller.
Query speed differences
I thought there wouldn't be big difference when running SQL queries on my local SQL 2014 comparing to Azure - and if so, that Azure would be faster. But I was wrong. For some reason, the same query via Entity Framework took couple of seconds on local database but couple of minutes in Azure. I had no idea how to debug it and find the reason so I rewrote the query into pure SQL which works fine.
Slow Android browser
When I was testing the application on tablet, I saw it is very slow. After you touch a button, you had to wait a little bit to be your next touch recognized. Annoying. So I tried all available browsers for Android and the best one is Opera. It hast the largest screen estate and it is really fast - see the picture.
When my neighbor checked the sales one morning, he was very surprised. There were sales for 450 000,- Kč in one kiosk. Quite a lot when a small ice cream costs 14,- Kč! It turned out that the touch layer on the tablet went crazy and generated touch events on the lower part of the display. The kiosk signed in a cashier at 3:15 by itself and created one transaction every two seconds on average. Interesting bug - on the other hand, it was nice load test :-).
Shift duplicate checkKiosks send all errors to the server and I check them from time to time. Early after launch, there was an error that shift cannot be saved because it already exists in database. It turned out I forgot duplicate error handling for new shifts. If the shift was correctly stored in the database but the server response got lost, kiosk tried to send the shift again and again.