Macs, Modularity and More

NSConference 2011 Day 1

This year’s NSConference UK kicks off in the same venue as last year, in the DeVere conference centre just outside of Reading. The organisation of the conference and breakout room is better than last year (previously, the blitz talks were occupying a space opposite the bar) but the hotel still seems to have failed in the basics like heated rooms or hot water.

Making apps that don’t suck

Mike Lee opened the conference with his “making apps that don’t suck” talk – a highly entertaining introduction to viewing the world in a different way. His advice was instead of concentrating on making things great, to make them suck less:

Instead of this

Do this

Steps to make things great

Steps to make things suck less

Assume we make great things

Wonder why we’re not rich yet

Profit!

Assume that we suck

Figure out why we suck

Figure out how to suck less

Trism got an outing as the worst iPhone UI ever, mostly for its over use of modal dialogs (aka NSFail)and splash screens “Showing a user a splash screen is like putting a mirror on your date’s forehead; it shows her who’s the important one”. However, it’s important to note that your mistakes are as obvious to others as theirs are to you, so always get someone else to review your app and listen to feedback. Sometimes, things aren’t always as clear as they seem, as in the non-handling landing pilot rules:

The Landing Pilot is the Non-Handling Pilot until the “decision altitude” call, when the Handling Non-Landing Pilot hands the handling to the Non-Handling Landing Pilot, unless the latter calls “go-around”, in which case the Handling Non-Landing Pilot, continues handling and the Non-Handling Landing Pilot continues non-handling until the next call of “land” or “go-around”, as appropriate.

In view of the recent confusion over these rules, it was deemed necessary to restate them clearly.

Getting feedback is important; since feedback is not a chance to prove yourself; it’s a chance to prove yourself. If you don’t have any complaints. go out and find some. Mike regaled us with a travel woe, this time courtesy of KLM, who went out and found feedback but made the situation worse by replying:

Mike: I hope the 100€ KLM gouged me for my luggage being 3kg overweight was worth the intense ill will I now have for them.

Too much implementation detail ruins the experience; never let them see you making it.

Stop making crap, the world has enough of that already.The crap market is full.

The harder something is to make, the harder it is to copy.

You are the only person you can change, and the only person who can change you.

To make great things, you must first refuse to make things that suck.

If you spend all your time looking at your competition, your product will look like your competitor’s ass.

Life is a privilege, and may be revoked at any time without warning.

Life is too short to waste time on things that suck.

Adding VoiceOver to Apps

Dave Addey gave an entertaining presentation on adding voiceover to iOS applications, and of the importance of doing so (2% of the user base has visual impairments). Every iPhone ships with both VoiceOver (which announces widgets as you move between them) and is relatively simple to add – his company’s UK Train Times app won the RNIB app of the month and mobile product of the year.

To demonstrate how it worked, he asked the audience to switch on voice over, by going to Settings - General - Accessibility - Voice Over. Immediately, the room was abuzz with muttering iPhones, which was an experience to hear in itself! The worst part was putting down ‘screen curtain’ (by double-tapping with three fingers) which completely turns off the screen (you can turn it back on again with the same process). That, and screen accessibility’s zoom feature are great things to know about when designing applications for voice over, and it’s not that hard to do.

Simulating location

Ortwin Gentz talked about how to simulate using Core Location from a Mac by conditional compilation/replacement of CLLocationManager with FTLocationManager (as part of the FTLocationSimulator framework). This wires up the callbacks that CL applies to allow your app to receive a stream of data to give different positions.

The neat approach of this is the use of Google Earth to trace out a route and then export it as a KML file which can generate the data stream for simulation purposes. The data is fed at a fixed rate of points per time rather than average speed, so the cursor will speed up and slow down if the KML points aren’t evenly distributed. But it’s a good test case to save driving (or biking) around to get data in place.

Crytographic Storage

Graham Lee gave a great intro to cryptographic storage on the iPhone. Although a password (or security code) locked phone will encrypt data stored, this is outside of an app’s control (or detection) – so being able to encrypt data on the fly is the only way to be sure that the data is safe. Graham talked about the AESCrypt library, available under an open source MIT license, and the file format for the encryption. He also walked through the source code for how it worked; but if you’re reading and writing data, you only really need to know about the encrypt_stream and decrypt_stream to be able to read/write encrypted data in your iPhone app.

Wrangling the Cocoa Text System

Ross Carter gave a blitz talk on the Cocoa text system, including how TextEdit can correctly deal with multiply accented characters which programs like Word and Adobe still find difficult. The key takeaway was that NSTextContainer doesn’t actually contain text, but rather defines a visual region in which text can be laid out. He also pointed out another gotcha where the layout isn’t guaranteed to be finished when the delegate message is fired; but rather, when the main thread’s run-loop has returned.

Digging into Instruments

Colin Wheeler talked about the power behind Instruments, or as he said “Garage band for developers”. The advantage of Instruments as opposed to previous tools (like Shark) is that all of the measurements are integrated into one timeline and can be aggregated/filtered as appropriate.

A few tricks he pointed out in using Instruments:

You can hide function calls by filtering system calls to just leave your application’s calls

You can charge a function to its calling parent (for example, when many functions are calling an XML parse function; instead of aggregating the XML call, push the cost back to its callers to find where the hot spots are)

You can start Instruments in a ‘headless’ mode – provided that Instruments is in the dock, whether running or not, it’s possible to gain measurement data – and it’s also possible to define a global quick-key to measure it

You can export dtrace-based Instruments to a .d script, which can then run on a customer’s machine (without developer tools installed) to collect a log, which can subsequently be opened in Instruments for viewing

Colin is working on a ‘zero debugging’ app which can collect DTrace information on a customer machine, and will make available subsequently, but not yet ready for prime-time.

Building a better business

Kevin Hoctor, of last year’s lickahoctor fame, talked about steps to running a business. Basically, cash is king, so finding a way to fund the version 1 of your app (and getting it out of the door) is a key step in starting to be success. He also pointed out that the successful people are the persistent ones, who keep trying even when faced with failure(s) in the past. There’s a lot more information on his blog so I’ll leave that as a reference.

Cappuccino

John Fox rounded off the day with a talk on Cappuccino, a JavaScript framework for building applications using a language Objective-J, to give an Objective-C like feel to JavaScript, for example:

Cappuccino looks like it has a lot of strengths, and like SproutCore makes it easy to develop web based applications using techniques which may be more useful to those more familiar with Objective-C.

Wrap up

One of the main reasons to come to a conference like NSConference, instead of viewing the videos afterwards or listening to the tweets, is to meet people and socialise. The dinner provided a means to do precisely that, although the pros turned up early on Sunday night to get an extra socialising session in. The only piece of advice I’ll offer is not to do so much socialising that you have a headache throughout the next day, which can really make things difficult …