Bob is a part-time geek and full-time president of Servoy USA. He can be contacted at [email protected].
Along with about 13 million of my closest friends, I recently bought an iPhone. Whether you love or hate the iPhone doesn't really matter. What matters is Apple (and now Google) have created mobile devices that are actually compelling. They're more than just phones—they're mini-computers in your pocket.
Because people are seeing them more as mobile communication devices rather than just phones, it also raises expectations as to how you interact with data—especially the data you also interact with on nonmobile devices.
The bottom line is that more and more users will ask for access to their data applications (or at least subsets of them) while they're on-the-go. And that, fellow developers, means you will be asked to create mobile applications like these sooner rather than later.
For this project, I focused on the iPhone for several reasons:
- It has a decent, nearly full-featured browser (but no Java Applet support or Flash yet).
- The screen resolution is fixed; no need to code for different screen sizes.
- I wanted to quickly create some iPhone applications that I could use for myself.
Moreover, I wanted to create an application that would, itself, build iPhone applications. Basically, a metadata repository that either IT folks or even (gasp!) end users could use to build specialty iPhone apps without having to wait for "coders" (who are always knee-deep in "urgent" projects) to get around to building it.
The application had to be fast, flexible, and somewhat sexy. And once deployed, it had to run anywhere on anything, OS- and database-wise. The last thing I wanted is to create this framework and have it limited to only a certain subset of users on a certain subset of hardware that was capable of running on only a subset of database engines.
While everyone has their favorite tool for creating applications, for this project I was open to anything and everything.
For instance, in describing how he took some example HTML code and modified it for the prototype app he was writing, Tom Thompson presented one approach in "Porting JavaScript Applications to the iPhone" (DDJ, November 2008; www.ddj.com/mobile/211200910).
While that's a great approach if you only need a few applications or some really custom stuff, I was hoping for something where I could easily create lots of different iPhone applications from different database servers running on different databases and platforms. And, more importantly, I didn't want to have to handcode all the inevitable change and enhancement requests down the line.
The other thing that I wanted (if possible) was to create something that would already support AJAX with little or no code, but that also had a small client-side JavaScript library due to the iPhone's limited capabilities. Because of the iPhone's limited screen real estate, I wasn't going to spend time trying to build something that had a multiple document interface.
After talking with other developers and having a thorough Google session, I defaulted to my personal development tool of choice—Servoy (www.servoy.com). In some ways, this choice is understandable because Servoy is the company I work for.
Nonetheless, Servoy meets all of the project requirements. Moreover, because I can script it in JavaScript or straight Java (or both), I wouldn't have to do the down-and-dirty coding of database connections, data binding, connection pooling, or any of the other stuff I would have to in other environments. Additionally, Servoy automatically translates all the forms into HTML with AJAX built-in without any code. Consequently, I could develop a native client "builder" application and the actual iPhone deployment application from a single code base, in a single IDE (Eclipse).
