This week, I had the opportunity to go to a talk at the University of Washington about developing apps for the iPhone. At the moment, development is restricted to web apps, but there is an SDK that is supposed to come out in February which should open up more development avenues. For now, we are restricted to web apps, so the talk was about that. As a side note, it is possible to develop apps natively, but it is completely unsupported by Apple.

The day after the talk, Apple released most of the presentation materials on their iPhone dev site, so you can check it out there as well. You have to sign up for an online ADC account, but that is free (although their “security questions” policy is highly obnoxious).

So, on to the meat of the presentations… The talk was basically broken down into three sections. First was a discussion of the capabilities of the iPhone web browser. Next they discussed data (mostly video) capabilities on the iPhone. Finally, they concluded with a session on designing good looking apps for the iPhone.

The web browser built into the iPhone is based on Safari 3, which is currently in beta on Windows/Mac, but it will be fully released along with Leopard tomorrow. Safari is based on WebKit, which has an open source version. Three levels of web support were defined: Compatibility, Optimization and iPhone apps. Basically, the first step to making your web site work with the iPhone is making sure the regular version works with Safari 3 and the limits of the iPhone. Optimization involves making your site work better with the I/O methods of the iPhone, and iPhone apps use specific Javascript/CSS features of the iPhone.

The first part, compatibility, basically gives tips on how to keep your CSS and Javascript compatible with standards, rather than just making sure they work with the mainstream browsers. They mentioned things like using Javascript object detection instead of user agent strings. Generally, if your site works with Safari 3, you will probably be in good shape.

The second part is optimization. There are various tricks you can use to make sure your web site looks good on the iPhone. For example, the iPhone pretends to be a 980×1091 display and then shrinks the web page, so you can test that on the desktop. There are also some custom CSS things that set whether or not your web site should be zoomable, or what CSS file to use based on the characteristics of the browser (like screen size). The CSS media queries are a standard CSS thing, so they will work in other browsers as well.

Finally, if you are going to try to make a web site specifically for the iPhone, they have some additional recommendations. You should make use of AJAX, so the app is responsive and interactive, and try to emulate the layouts and styles they use in native iPhone apps. One of the more interesting things they mentioned was the use of the Canvas object, which is built into most web browsers (excluding IE), and allows drawing custom things on the fly on the screen.

In the data presentation, the basic flow of data to and from the iPhone was described, most of which is pretty obvious. Things like calendar data flowing to the phone via iTunes were described. They also went into some depth about optimizing video for the iPhone. There are some encoding settings built into Quicktime for the iPhone in Wifi and EDGE modes. You can encode your video for the various data rates, and create a “Quicktime reference movie” which links to the various copies of the video. The iPhone will choose the proper video when it is directed to a reference movie on the web.

The design presentation went over some concepts of how to design your app to match up with the iPhone’s native apps. Most of it was pretty basic stuff. They did iterate one important point, which is to keep in mind the goal of facilitating what your user wants to achieve. Getting wrapped up in the details can lead to feature creep and make the flow of the application confusing. I thought this was a good design concept in general which applies to all applications.

All in all, the talk was an interesting overview of the dev environment available today, and gave some background into some of the “vibe” of the iPhone. There were a couple cool things to pick up on, but a lot of noise as well. While the current environment does provide the tools to achieve quite a bit, I look forward to what might come in the February release of the new iPhone SDK.

Back at Trimble, I wanted to write some unit tests for our DAO stuff, so I came up with this crazy scheme to run a test SQL server on the local machine. I had all this custom code set up to prep the database for the test, then run the tests.

In Java, I am using a HypersonicSQL (is it even called that anymore?) in-memory database to do testing. It’s really fast since it doesn’t write to disk, and every time you run the tests, you have a fresh database. You just inject the HSQL config into the HibernateUtil class and run the tests.

I’ve been writing software as a job for a few years now, and I think there is one common theme that seems to recur. There is never enough time to get everything done. The proper solution to this problem is one or a combination of three basic ideas: bring in more resources, come to a compromise, or increase productivity. The first two alternatives are not very appealing because businesses generally want to offer a good product and not spend a lot of money building it. Increasing productivity, therefore, seems to always be a good goal to keep in mind.

When writing software, one of the things we are all taught to do is pay attention to performance. We analyze algorithms, figure out their big-O complexity in terms of computing and memory usage and pick the best one. I always hated that part of school with a passion. Perhaps that makes me biased. I agree, however, that you need to keep performance in mind.

For me, performance has always been just that. Something on my mind, but not usually directly applied. I prefer to pay attention to elegance and the architecture that supports the code. I think, in general, if you pay attention to the architecture and keep things simple, the performance works itself out. You do have to think about performance, but don’t let it compromise the elegance of your code. Once the application is deployed and/or load tested (depending on the flexibility of redeployment), you can fix any performance problems, and sacrifice elegance if it comes down to it.