On iPhone app inputs

This question statement often comes up.

We’re developing an iOS application, and of course, the user would have to input some personal information before he/she can start using the application. What kind of validations should be implement on the device? Which ones on the server?

Most people, especially when starting out on a new project, consider input validation to be a fairly trivial problem statement with fixed states. But, as the application matures, they fairly quickly realize that every input has its own set of error and valid states. The validation problem grows exponentially with the number of user inputs on the device, as every combination needs its own validation, more or less.

I firmly believe that validation should never be done on the client, unless that’s the only place you need to do it. If there’s even a single server side validation component in the project, the team is better off delegating it entirely to the servers. This makes life much more easier for the front end developers and also makes testing easier. If your application depends on a web service (as most iOS apps do), chances are that the web service would in the near future completely rewrite its required inputs specs and then you will find yourself in a situation where instead of adding new features to your iOS app, you are spending valuable time in trying to get all the client side validations in place. This, until the next time this repeats itself.

That said, there is also a need to think about whether that input is really required. Let’s not forget that iOS devices are mostly mobile gadgets where the users are generally in a hurry to complete a particular task. Even if it’s their first time using the application, forcing them to input personal data which is only partially required is detrimental to the entire user experience. It adds unnecessary validation.

Conversely, if you have an input component in your app, then you necessarily HAVE to validate it. If you’re not validating it, it’s not important, and hence, must be disposed off.

Lessons: Abide by the Apple Human Interface Guidelines, always. Don’t force your users to input more information than is logically necessary for the application to do its job. If you have to perform input validations, do them all at one place, and that place is the server where you have the necessary processing cycles.

Should you use Interface Builder?

Ever since I started out with iPhone development, I have seen a lot of debate online about the pros and cons of using the Interface Builder tool that comes as a part of the developer toolkit for Mac and iPhone development. For a lot of people, the tool comes across as basic, limited in scope, and sometimes entirely useless. For the developers at the other extreme, IB is an invincible tool without which there is no app development.

This Wednesday, I got the chance to debate just this with the CTO of an iPhone startup here in Washington, DC. While I am short on the person’s technical background, he did mention that his previous programming experience was doing website development using Flash and Dreamweaver.

(more…)

It’s been a while…

…and how times have changed. The last time I blogged, I was on a train, commuting to DC on a daily basis for a federal project that everyone was in just to rake in utilization hours (bonuses) and bide time. I was single. I had a roommate. And, I was careless.

Now for the exciting part. I am married, drive a hybrid, don’t have roommates, and no longer commute 2.5 hours to and from the client site to work on some of the most technologically backward and ill-designed projects ever. I am now a more serious iPhone and Mac developer, thanks to the commute time saved, and have actually gained enough experience to put out apps (albeit small ones for now) on the App store.

I have gained more understanding of how small business in America works. I have seen the economy take one of the worst nosedives in my lifetime, and seen desperate efforts to bring it back on track. I have seen people responsible for the mess make it big, and I have seen people suffer. I have been humbled. I have come out stronger.

For those wondering what I am up to now, I am still the good old me, although with the wisdom of two. I am still diffident, so much so that I sometimes sell myself short, but it doesn’t matter. The people who are smart enough to realize my strengths are the ones that mean something. I am now, however, spending a lot of time pursuing my passion – learning to become a diligent software engineer, working on mobile services, next generation entertainment and communication software, and of course ECM. You can teach a violinist how to use their long fingers to type fast, but you can’t teach them how to compose poetry with their keyboards. Being able to do just that is something I am proud of. Thank you, school!

I am back, and hope to make this blog mine once again. Thanks for being a reader.