I finally decided to get my feet out of the mud and build something useful. I chose as my first significant iPhone app a client for the Victoria Virtual Tennis Club. This is a PHP/MySQL based web site which I developed to help this organization host Tennis matches in the Victoria B.C. area.

Like most desktop developers moving to mobile, I’m struggling to keep things simple on iOS and adopt the UI idioms users have come to expect and understand. I’m sure I’ll find ways to simply this app after I’ve had time to play with it.

This is a standard master-detail app which lists a calendar of upcoming VVTC events:

Taping on an event in the master screen takes you to a detail screen where you can see event details, a list of participants and then sign up for the event if you want to.

Behind the scenes, this involved adding a simple REST service to the VVTC web site to get the current calendar information, and to request signup. This data is returned as a JSON structure.

I decided to avoid the various iOS REST frameworks I found, and simply roll my own since I only have two URLs (get calendar, request signup). This decision may haunt me in the future, but for now things are working and I can understand what’s going on. The new NSJSONSerialization class worked flawlessly with the data returned by PHP’s json_encode function. Dealing with dates was a bit of an issue, but I finally settled on the ISO 6801 date format and that problem was solved.

Going forward, I want to add a Month view that mimics Apple’s Calendar application using the Kal project as an alternative to the list view I currently have.

I want to give full credit to the following resources that made this whole exercise possible within the 2 days I gave myself:

1. Matt Neuburg‘s new “Programming iOS 5” book. This book explained lots of things for me, but most importantly it allowed me to adopt ARC along with a lot of Objective-C 2 features in my iPhone app. After many years of doing manual memory management in Script Debugger, it took a lot to let go of the rains and trust this to the compiler. This exercise has kind of spoiled me for dealing with my old code.

   I read the first edition of Matt’s book cover-to-cover a few years ago and that gave me my basic understanding of the iOS SDK. A lot has changed over the years, and the new version of the book was great at reacquainting me with the iOS SDK.

2. Erica Sadun‘s “The iOS Developer’s Cookbook“. Lifting pieces of Erica’s code out of her examples saved me a bunch of time.

3. The QuickDialog project. I used this to build all the detail views in my app and it saved me a mountain of time.

4. There are many web sites offing directories of reusable iOS (and Mac OS) UI components, but I recently found Cocoa Controls. This site led me to stumble upon QuickDialog and a number of other useful things.

UPDATE: I am missing Cocoa Bindings under iOS. I know that iOS provides Key Value Observing, but Bindings are missing. How are others dealing with this omission?

A recent addition that stuck in my mind was the new Podcasts app which uses the metaphor of a reel-to-reel tape recorder as a background while playing podcasts.

At first I thought this was clever, but than I realized that (a) most iOS device users are too young to have any memory of these machines, and (b) Apple has gone to extreme lengths to create this fiction. The tape moves from one spinning reel to the other as a podcast plays, just as it did on the real machine. When you pause or play a podcast, the tape tensioner moves to take up the slack in the virtual tape traveling over the playback heads.

The programmer in me is impressed by this attention to detail, but as a customer I’m left wondering how much useful functionality was dropped from the product to make time for this kind of “play” in the UI.

I’ll add a few additional observations after having used my new machine for about a week:

• It is fast! I’ve not had a desktop Mac for many years so I cannot compare this MacBook Pro to a Mac Pro or iMac, but this is the first time I’ve gotten a new Mac laptop that was dramatically faster than my previous machine. The combination of solid-state disk, lots of RAM and a fast CPU make the machine very responsive. Building my Script Debugger 5 product from scratch went from ~4m30s down to ~1m15s.

• Like Marco, I’m running my display in scaled mode because the standard video mode does not provide enough space for my needs. In this mode, the GPU isn’t strong enough to keep up with some operations. Examples include swiping between spaces causes a noticeable lag and some scrolling operations are a little slow. But Xcode works just fine, as do all the other development tools I use.

• iPhoto and iMovie are revelations. All my images look so much better on the retina display. I shoot a lot of images of sculptures and finally these images are starting to carry the same impact on the retina display as they do when printed. The awful flatness of older displays is gone. We are finally beginning to get back some of the power of slide film.

  This change is more noticable on the retina MacBook Pro than it is on the retina iPad (which is very good). This may simply be a consequence of the MacBook’s display being bigger than the iPads.

• You are going to use more disk space. For example, iPhoto and iMovie will generate higher fidelity thumbnail images which are going to take more space on your disk. If you have a large iPhoto library, this could mean a few more GB lost to thumbnails.

• Surprisingly, Terminal really benefits from the retina display. Small font sizes are easily readable making it possible to show more lines and columns in a Terminal window.

• If you like to rip CDs in iTunes, you’ll need to buy Apple’s external USB CD/DVD drive as the Remote CD/DVD drive sharing system does not allow this kind of operation (You also cannot use HandBrake to rip DVDs). I get the DVD limitation because DVDs are copy protected, but CDs are not and its a drag to buy yet another accessory (you will probably have already bought the Gigabit Ethernat to Thunderbolt adapter).

• I have 50 year old eyes and eye strain seems to be reduced.

• I’m waiting to see if this display improves my ability to catch errors when proof reading. In the past I found I have to print out my copy to properly proof read it. We’ll see if a higher quality display improves legibility and comprehension.

• The machine runs much cooler than my old MacBook Pro. The silence of the thing is eery. I have to push the machine fairly hard (long Xcode compile) to get the fans to spin up.

• The heartbeat pulsating light on the front edge of the body is gone. As a result, there is no visible clue when the lid is closed that the machine is sleeping vs powered down. The battery level indicator lights are also gone so you have to wake the machine to see where your battery is at.

• Safari finally feels fast. I’ve always found Safari to be slow when loading PHP and Rails pages hosted on my own machine, but now it loads without any noticable delay.

Overall, I’m very happy with the machine.

New Machine: Mid-2012 2.7Ghz Core i7 Retina MacBook Pro, 8GB RAM

Old Machine: Mid-2010 2.66Ghz Core i7 MacBook Pro with Hi-Res Display, 8GB RAM

I am a self-funded Indie (lone) developer. I made a number of classic business blunders on the FaceSpan 5 project. I broke the golden rule: never (never!) rewrite a software product. I massively underestimated the effort required to complete the product. I set off without having sufficient resources to complete the project. Because I took so long to complete my work, the market moved on — AppleScript’s importance to the customers I intended to target declined. Some may argue that the market was never really there to provide a return for a product of this complexity. Finally, I didn’t pull the plug soon enough. Hindsight its great.

Not all was lost. Some of the code I developed for FaceSpan 5 found a home in Script Debugger 5.

A Little History

Many years previously I developed FaceSpan 3 under contract for its owner. As part of that effort I became impressed with FaceSpan’s power and simplicity. FaceSpan 3 was successful, for a development tool, and even received an Apple Design Award at that year’s Worldwide Developers Conference. Sadly, after my involvement with the product ended, FaceSpan fell into disrepair and did not make the leap to Mac OS X. FaceSpan’s developer finally produced FaceSpan 4 which was to little to late and not as successful as hoped for.

I acquired FaceSpan 4 in 2006 and, after a period where I tried to fix the most serious issues with the product, I concluded that FaceSpan 4′s dependance on AppleScript Studio was its core problem. FaceSpan 4 had great integration of a visual UI bilder and coder editor, but lacked a good runtime environment and debugging.

Work on FaceSpan 5 began in 2007 with the aim of freeing FaceSpan from AppleScript Studio and restoring the classic FaceSpan’s attractiveness. By the time I stopped FaceSpan’s development I believe I was well on my way to achieving my aims. Two great Mac developers helped me with the project:

• Adrian Ruigrok, who now works for Apple, developed much of the FaceSpan 5 IDE code.
• Matt Neuburg acted as a sounding board for my ideas and developed the initial FaceSpan 5 documentation.

The project turned out to be too ambitious given my resources. Additionally, FaceSpan revealed a number of AppleScript issues and problems in Apple’s Cocoa Scripting framework which I was ultimately unable to overcome.

What Is (Was) FaceSpan?

FaceSpan 5 was an integrate tool for building Cocoa applications using AppleScript. Many people saw similarities to Apple’s HyperCard. FaceSpan provided a visual UI builder, an AppleScript editor, an AppleScript debugger and a runtime environment designed to take the best advantage of AppleScript’s strengths and provide a collection services and UI widgets out of which applications can be built. Matt wrote this description of FaceSpan 5 back when the project was active.

The FaceSpan 5 runtime environment wrapped Apple’s Cocoa Frameworks in a sanitized and simplified AppleScript focused programming interface. This allowed one to build fully Cocoa-native applications using AppleScript without having to learn anything about Cocoa. The intent was for Cocoa to be an implementation detail rather than the programming interface.

We’ll never know if the FaceSpan 5 approach was actually better than the AppleScript Studio interface offered by Apple. My hope was that FaceSpan’s approach was actually simpler, and not simply a substitution of one complicated programming interface for another.

Since FaceSpan 5 was abandoned there have been several developments in the area of AppleScript GUI tools. Firstly, Apple transitioned from AppleScript Studio to AppleScriptObjC. Shane Stanley has released his ASObjC Runner which can display progress dialogs. And then there is the long lived Appearance OSAX from 24U Software.

The Last Build

When I stopped developing FaceSpan 5, a lot of people came out of the woodwork looking for a copy of the software. I was not willing to make the software available at that time, but I am now. I’m doing this now because I think it might be interesting for those of you who were/are curious about what I was working on to get a chance to play with the product.

Keep in mind that this build predates the release of Xcode 4 and there are some interesting similarities. Apple had to be developing parts of Xcode 4 during the same period so its fascinating to me how common ideas arrise in different places.

Before you download the software, please keep the following conditions in mind:

• This is Alpha-Stage software. This means that it is buggy and its not feature or UI complete. Expect it to crash and fail. If you stick to the examples included with the documentation, you should be okay.
• THE FACESPAN SOFTWARE IS PROVIDED AS-IS FOR EVALUATION PURPOSES ONLY. USE AT YOUR OWN RISK.
• PLEASE DO NOT FILE BUG REPORTS. I’m not going to produce another build.
• PLEASE DO NOT ASK ME TO OPEN SOURCE THE PROJECT. This product shares a lot of code with my Script Debugger product and I’m not willing to release the code.
• RTFM. Seriously, you are on your own.
• The software should run on Snow Leopard (10.6) or Lion (10.7). I have no idea if it will work on Mountain Lion (10.8) or beyond.

View Matt Neuburg’s Alpha Documentation. More FaceSpan 5 information and screencasts.

Download FaceSpan 5.0.

FaceSpan 5 Blog Posts.

To get you going, check out this post: Dock Icon Changer.

Have Fun!

For v2, I added the conversion to grayscale. I took this opportunity to add a Settings menu to the app’s Action Bar which toggles between Color and Grayscale display. Finally, I found that I needed to retain the Color/Grayscale setting in the app’s preferences so I added that as well.

You can download the source code for this application here:

PolaroidII.zip

I came across the Premium Pixels site which offers a series of attractive free UI design elements. I decided to start with their Pretty Polaroids example and try and implement it as an Adroid application.

This sample Android application allowed me to experiment with the android.graphics objects.

Here’s how the Premium Pixels UI mockup looks:

Here’s how my Android implementation of this UI turned out:

You can download the source code for this application here:

Polaroid.zip

Downlaod TimePicker.zip

This project is an attempt to implement David Cristian‘s Hour Picker UI design (which I found via UI Parade) as a Cocoa View. Here is how David’s UI mockup appears:

When I first saw this UI design I found it visually compelling, and it really seems like a nice solution to the problem of allowing the user to quickly pick periods of time in 1/2 hour increments. When I began turning it into a functional UI a number of issues concerning how users interact with the UI begin to surface:

1. This mockup shows only 6 hours. The UI needs to scroll in order to show the full 24-hour day.
2. I chose only to implement click and drag to select time ranges. I imagine that shift-clicking might be desirable. I didn’t attempt to handle keyboard input.
3. At first I though the 1/2 hour grid was self evident. However, when I began using the UI, I decided I needed duration feedback while dragging to know exactly how long the selected period is.

Here’s how my implementation looks while the user is dragging the mouse:

There are limitations to this UI:

1. Time can only be selected in 1/2 hour increments.
2. Time can only be selected within a single 24-hour day.
3. Auto-scrolling while dragging is problematic. It may be that auto-scrolling needs to slow down, or more rows need to be made visible in the scroll view.

Requirements

The project requires Xcode 4.2, and the Mac OS X 10.7 SDK.

Download

Release Notes

Among the changes in the Script Debugger 4.5.7 maintenance release is a fix for crashing bug when opening or creating documents on Mac OS X 10.7 (Lion).

A big thank you to all the folks who downloaded the various Script Debugger 4.5.7 Beta builds. I really appreciate all the great feedback and bug reports I received.