iPhone Web App in Ruby on Rails

This app has been made before, but not by me, not for the iPhone via the web. It's basically an overgrown score pad for fencing referees. When done by hand, a ref has to have a stop watch, a piece of paper, and a writing device, and he's not supposed to use a clip board because he has to make hand gestures to indicate the action and who is awarded the point.

My former fencer, Josh, came to me talking about an idea he and Ed had to incorporate iPhones and iPod Touches with scoring boxes and the bout committee. Up till then, I had been reading Rails for .NET Developers, and I had been hungry for a project to try out my new found knowledge.

In all honesty, there's no need for any server-side scripting in this app...yet. Once it ties into data from the BC, then it'll make more sense - so for the moment it really could just be straight HTML, CSS, and JavaScript.

What I like about this little app, this one page view into the status of a fencing bout, is that I finally did all of the suggested best practices that I had been avoiding. I used table-less design, so the presentation is all in the CSS, and not inline in the HTML. I did the same kind of thing with my behavior. All of the onclick event handlers are assigned in a script block using Prototype's Event.observe method. From there I even separated the code into separate blocks, one for dealing with the score, one for the timer, one for priority, one for swapping, and one for resetting. Once I started to make that kind of separation, my dependencies were clear as a bell, and easily refactored.

The resulting HTML, CSS, and JavaScript are all chunks of code I feel comfortable with. I feel like this is maintainable client-side code - code that I could easily have someone else work on with little explanation. I have never felt that way about client-side code before. I have known that the nagging feeling about client side code was the same feeling that others had to be experiencing, but I didn't know it could be addressed in the current state of the web.

Sadly, this only takes care of my code. It will not stop other people from writing bad code. Event the widely accepted method in the iPhone community for detecting if the browser is in portrait or landscape mode had a lot of room for improvement. Originally it was polling ever half second, when it could be tied into the resize event. Then I also removed the check to see if the width was a magic number of 320, and instead just did a test to see if the screen width was less than the screen height. Now if Apple comes out with a new phone with higher resolution, I'm all gravy baby.

Developing for the iPhone also made me think about the UI a lot more. In other apps like this, you'll see separate buttons for starting and stopping the timer. You won't see buttons like that on my app because I realized that a user might be ok just tapping on the timer itself to make it change state. The font color changes to reflect that the clock is ticking. A similar idea is employed with the score. Taping on the score itself adds one to the count. I wanted to use double-tap to decrement the score, but sadly the double-tap is reserved by the system for other functionality. At the end of my development, I found documentation on making objects wiggle to indicate that they are draggable, access to the multi-touch events which are handy for rotating, scaling, and just interacting with all kinds of things on the screen, and also a little lock-slider clone.