Demonstration Area iPad Touch Unreliability

We have an iPad installed in a demonstration area at our company that allows us to control a few items in that area for, as you may have guessed, demonstration purposes.  The interface we use for this purpose is an HTML web page that makes various AJAX calls depending on the button you press.  The screens were of a very simple design but for some reason this iPad just didn’t seem to be working right.  The registering of the button press was hit and miss.  This was our demonstration area and this thing needed to be rock solid so I had to dive into it and figure out what was going wrong.

The first thing I checked was the code.  It’s simple HTML using anchor tags styled to look like iOS buttons.  We used anchor tags because they could be styled the way we wanted them to be.  The web page is built as an iOS home screen web app and so uses JavaScript to call the web resources for each button.  We chose the “click” event of the anchor tag to fire the URL calls.  This is pretty standard for web applications.  The code seemed to be written right and we confirmed there were no HTML validation errors or JavaScript errors.

One thing that added to the confusion was we had CSS changing the style of the button when the link became active to indicate to the user that they were pressing the button.  This CSS was obviously working because the button was changing colors.  The confusing part is then that it was registering that the link was becoming active, just not firing the click event.

Next, I had our IT department swap out the iPad with a 2nd generation iPad which had all the iOS updates thinking perhaps it was a Safari or hardware issue.  This turned out to not be the case.

So the next thing I did was to swap out the click event for the mousedown event, thinking that since the CSS was firing, then the mousedown event would fire.  I was wrong.  It still didn’t work properly.  I did some digging into Apple’s documentation to find out that the mouseover, mousemove, mousedown, mouseup and click events all happen after the user lifts their finger from the screen (source).   Turns out that they provide you with a few new events to work with user interaction on the screen in the touch environment: touchstart, touchend, touchmove and touchcancel (as well as a few others).

After discovering that, I switched the code to fire on the touchstart event and the screen worked perfect!  Well… almost.  The way we have the screen laid out, there are several sets of buttons arranged in a horizontal row.  And if I were to press and hold one of these buttons, the button would fire as expected, but a few seconds after that, the other buttons would fire in succession and then loop back around firing all the buttons again.  Now I was thoroughly confused.

To add to the confusion, there was only one single iPad displaying this behavior: the one installed in the demo area.  I took my development iPad down to the demonstration area and attempted to reproduce the behavior in the environment with my iPad but couldn’t.  Finally I decided to unplug and remove the installed (trouble) iPad and try with mine in the mount.  I unplugged the installed iPad and decided for the sake of troubleshooting to try it once more while unplugged.  Guess what.  It worked perfect and displayed no weird behavior.  Plugged it back in and sure enough it started flaking out again.  Removed it from the mount while still plugged in and it worked fine again.  Turns out a combination of being plugged in and in the mount was the ingredients for the perfect storm.

After consulting with a coworker to ensure I wasn’t insane (in hindsight it all makes sense, but while I was troubleshooting, it did not).  Turns out it’s a grounding issue.  I’m no expert in capacitive screens, but from what I gather, the simple of it is that the iPad was built to be held.  So when you run it in a mount that is not grounded and have it running plugged in, because it doesn’t have a grounding reference, the capacitive screen could register ‘extra interaction’ with the screen.

As simple check I put it back in the mount plugged in and executed the test again, but this time, I touched the back of the iPad at the same time and it worked perfect.  No extra interaction registered.  Now, the next step is to attach some sort of grounding wire to the iPad and see if we can keep it working reliably without having to touch the back of it.

Again, the take-away of this post is that if you’re using an iPad as a touchscreen in some sort of display (not meant to be held), you may need to consider grounding the iPad to ensure it stays working correctly.

CRUDE: CRUD+Execute Operations

If you’re a developer, you undoubtedly know what the CRUD operations are: Create, Read, Update and Delete.  These are the basic operations of persistent storage.  They are also the basic operations you should adhere to when developing an MVC web application or web site.  It will help you keep your MVC structure simple and clean.  Developing with ASP.NET MVC3, Visual Studio has built in templates that stub in the CRUD operations for you.

However, these operations don’t always meet the need for the controller action.  Sometimes you need to actually execute a command.  Perhaps you’ve built an web frontend to a server and you’re providing the user with a way to shutdown or restart the server through said frontend.  Or maybe you need to transmit a message over a communication network.  In other words, perform an operation that doesn’t really interact with persistent storage or is a complex series of steps to complete that operation.

I was surprised when I did a Google search for “create read update delete execute”, the only results I found about it on the first page were definitions for the CRUDE acronym.  The rest were about CRUD.  I understand that these operations are typically referencing persistent storage, but with the popularity of MVC over the past few years, I’m surprised we haven’t seen more people extending these for operations to include Execute.

The take away is, when you’re building your MVC controller, try to stick to the CRUD operations, and when you have to move beyond them, ask yourself if you’re organizing your controllers and actions incorrectly and then ask yourself if the operation actually falls under the “execute” umbrella.  It may help you structure your controller actions better.