Now the beauty of the iPhone SDK is that it uses XCode’s interface builder, and Cocoa / CocoaTouch support directly loading polished NIB at runtime.  NIB is of course NextStep Interface Builder, and though they actually use a .xib (XCode Interface Builder) file while you develop them, at runtime and pretty much everywhere else they’re called NIB files. (Because Cocoa *IS* NextStep)

So back to the topic at hand. I have always liked the way Visual Studio did interface building, as it took the coding out of creating a UI and let it be about what it should be, an art*. XCode offers the same experience but with a bit more of a learning curve. The real challenge though is that on the iPhone, you have a lot to live up to. There are a lot of very attractive apps out there. Creating a tool for sysadmins to receive and handle alerts doesn’t require the polish and pizzaz of lets say a Twitter client, but it can’t be ugly or clunky either.

So in Cocoa Touch we have the Navigation Controller (UINavigationController, which provides a bar at the top with text a button on the left and right to navigate through views) and the Tab Bar Controller (UITabBarController, which provides a bar across the bottom with any number of iconable tabs that represent different views) Of course you have the freedom to come up with whatever UI you want outside these, however these conform to Apple’s User Interface Guidelines (a fascinating read, and the iPad guidelines were an even cooler read) and match the look and feel of the iPhone, making it easier for users to navigate. In fact you can even combine the two types and create navigated views within a tab, or a set of tabs within a navigated view. The sky is the limit and its easy to do, which is whats the most fun about XCode and Cocoa Touch.

So I decided to go with the Tab Bar. We are dealing with alert handling here, I know from experience that there are only a finite number of tasks that are required after hours, so we can stuff those as tabs a long the bottom. On Ken’s advice I added a More… tab which contains lesser used but still useful utilities like short cuts to compose emails to common distribution lists @FM, a long with access to the two ticketing systems outside of our department.  Throw in a Core Animation page flip between tabs (the code for animation in Cocoa Touch is really quite impressive) and you have something that looks decent (I think) and is fairly functional.  On a slightly side note, I kept the animation to a quarter of a second, that way it looks flashy but doesn’t slow down work flow, thats important to me. I’ve likely disabled every animation OS X has to offer on my computers after all..

I’ll likely write a follow up discussing my experience with some of the other UI widgets at a later time, but I wanna touch briefly on the spinning selector as seen in my Tab Bar screen shot. The iPhone’s user experience is superior to any other touch phone. (Android, Pre, Storm, I’m looking at you guys) I was very reluctant to use a touch screen interface because they usually annoy me long after the cool factor wears off. Apple has gone to great lengths to design the user interface of their own apps to work really well with fingers. The spinning selector is a great example of that. On the desktop, we normally select a choice of one from many in a drop down box. This works great, but is a tad annoying on something like an Android phone. The spinning selector is more of a wheel you spin with your finger that has very intuitive acceleration and deceleration such that its very easy to use. Because Apple makes it so easy to deploy these widgets in your own applications, you are very unlikely to see kludgy desktop-esque UI on the iPhone, making the user experience of 3rd party apps all the more familiar and better. That and they theoretically could stop you from publishing apps that don’t conform to the user interface guidelines, though in practice they pretty much only ban apps for their own dirty anti-competitive purposes…

*Design is an art, and UI design is at the forefront of that these days. Just look at all Apple products. You may not like their design (lord knows I’ve stripped OSX so bare its just a tiny bar on the right, no desktop and the Finder process isn’t running most of the time), but its still intuitive and attractive. In the end Apple is a design company. A PC is just a PC until its in a sleek, durable unibody aluminum case, then its a Mac. BSD is just a server operating system until its got an attractive, intuitive user interface, then its OS X.

fmNotify will be (ok I’m being a tad presumptuous but I have faith :>) our internal notification service for emergency alerts. It utilizes Apple’s fantastic push notification service (APNS, APN or APS depending where you read it) and some clever UI to streamline alert handling. Basically alerts and phone registration is handled by PHP code running on a server(s, easily redundant using mySQL replication) inside our network, stored in an SQL database. This allows for  pretty extensible triggering of alerts, everything from Nagios, email via procmail, and our own internally developed software.

The real thing I wanted to talk about is how impressed I am in the APNS bits of the SDK. iPhone SDK 3.x is really where the iPhone hit its stride, and the push SDK is a big part of that. (Prior to 3.x it was a pretty disappointing device IMO and more than a fancy toy for teenagers than anything workable.) OS 3.x makes the device a powerful device for any industry. (Though MobileMail.app is still so woefully inferior to the Blackberry)

BUT I DIGRESS. Working with APNS is a coders dream. When your app is setup with Apple for push support, you get a cert that can be used to connect to the APNS cloud with. APNS requires a connection via TLS or SSL, which of course can be done easily with libopenssl in C or in this case PHP. From there all you need to do is send json blobs that contain: the device id of the handset, the alert text you want to display, the badge number to show on the app (if desired) and the sound to play (if desired). Beyond that you can include whatever other custom data you want, within 256bytes. This may seem like a rather limited amount of data to work with, but its really just to trigger your app to connect to you own servers, which can then pull down whatever data you want.

So while your app isn’t running and a notification comes in, a popup will occur with vibration/sound if desired, and a link to automatically launch your app.  While it is running an event is triggered within the app delegate and you can handle it however you want. Pretty awesome. Throw that all together with a nice GUI and you have a really streamlined alert / alert handling work flow!

So the app itself is pretty simple. Just a basic UI for seeing alerts / alert history, and then panels for dealing with common alerts.  The backend is basic PHP / mySQL / simple JSON / openssl integration to handle registration (including the device id and desired alert sound) for each phone, and directing of alerts to whoever is oncall. I really look forward to future projects using APNS, considering this took less than a day to throw together, the sky is the limit!