Swiping op een touch screen

Ons project had al een paar maanden een probleem met onze machines. Niet echt met de machines op zich, maar met het touch screen. Onze interface gedroeg zich namelijk anders als we met onze vinger swipeten als dan dat we het met onze muis deden, meer bepaald tijdens een drag en drop. Het probleem was dat als we van links naar rechts bewogen, dat we dan altijd op de vorige pagina terecht kwamen. Als we daarna dan andersom swipeten, dan kwamen we terug in de oorspronkelijke pagina.

Onze user interface is eigenlijk een web interface en we draaiden met chrome als browser. Dus het swipe gedrag was alsof we op de back en forward knop drukten in de browser. En dat was nu net niet de bedoeling.

Onze klanten mogen eigenlijk niet weten dat we met een webapplicatie werken, dat hebben zij trouwens geen nood aan in een fabriek. Dit is dus echt wel gedrag dat we niet willen.

Ik had al gekeken in de opties van Chrome zelf, maar nooit een oplossing gevonden. Toen vond ik een oplossing, chrome of chromium opstarten met een command line switch:

Deze oplossing vond ik op de pagina van Peter Beverloo. Hij heeft trouwens nog meer command line opties op zijn pagina gezet. Neem maar eens een kijkje op Peter Beverloo’s pagina.

Zo zie je dat ook een tester bugs kan oplossen, want niet alle bugs zitten in code.

License To Kill

During the setup of a framework with protractor tests, I had a problem. I ad it before, but at that time I did not find a solution. The intention of the framework was to run on our integration server. After each commit of a developer (or me), the tests should run. At this moment they can run after each commit, because it is not taking that long yet. Later it may happen that some tests should run at night or so.

But to perform the integration tests, a backend and some other application should run. Our backend is interacts via html with the user, but also interacts with hardware. The problem was not starting up all this, but tearing down. This because it is legacy code and shutting down is not implemented. This means that the process should be killed by jenkins.

But because our environment uses a lot of batch scripts, jenkins does not halt the backend if a test job is done. This means that I had to create a script to kill the backend after all tests has been running.

I did know how to do that on a unix like environment, but not in a windows environment. And now we are running all our code on windows. A long search later, I found that there is in windows also a command that can kill applications.

After this command was placed in a batch file, jenkins can run all tests without the fear that sometimes the backend is hanging after a test job.