But displaying lists in applications can be much more than trivial, certainly for applications on Mac OS X, especially when you have to deal with large quantities of data, and have to solve problems such as variable row heights or changes to this information.

Ever since using Tweetie, a Twitter client for Mac OS X, from a development point of view I was always curious as to how the list view for the Twitter timeline was implemented; hundreds of rows of tweets can be displayed in this control, and the performance hit appears to be minimal; scrolling is smooth, there doesn’t appear to be a huge memory footprint. So how is it done?

Lists in Tweetie

If you class-dump Tweetie, you can see three classes at work:

• ABScrollView: A subclass of NSScrollView. It’s not clear as to why there is this subclass but an ABColor object is used for the background (as opposed to an NSColor).
• ABTableView: A subclass of ABScrollView which is used as the list control.
• ABTableViewCell: The cell class used to display each row in ABTableView.

The interesting part of the class hierarchy is contained in ABTableView and ABTableViewCell. ABTableView is a subclass of ABScrollView (not NSTableView) and is a control which can display a list of ABTableViewCells. However the real misnomer here is the cell part, because ABTableViewCell is a subclass of NSView, and not NSCell.

So essentially what we have here is an implementation of something similar to NSCollectionView, which has a set of subviews which each represent a row and have their own place in the view hierarchy. But how, then, is the Tweetie list view so performant?

@interface ABTableView : ABScrollView
{
    ...
    NSMutableDictionary *reusableTableCells;
    ...
}

...
- (id)reusableCellsArrayForIdentifier:(id)arg1;
- (id)dequeueReusableCellWithIdentifier:(id)arg1;
...
@end

Reusing Cells

The answer seems to lie in a method declared on ABTableView, which is -dequeueReusableCellWithIdentifier:. For those of you who are iPhone developers, you will be familiar with a method on UITableView with exactly the same method signature.

For those who aren’t, I shall explain: certainly compared to simple NSCell instances, NSView instances are pretty expensive. In fact, NSCell is actually designed as a “mechanism for displaying text or images in an NSView without the overhead of a full NSView subclass”¹. In light of this, if we have 100, 1,000 – or even more – rows in a list, we don’t want the overhead of 1,000 instances of NSView, each used to represent a row. What’s more is that most of these cached views are wasted, since 1,000 rows cannot be displayed in the viewport at the same time. The iPhone takes advantage of this, and ensures that there are only enough view (in this case UIView) instances to cover the height of the table view; if the associated rows are scrolled off screen, then the views are removed from the view hierarchy.

Scrolling works much like laying down track for a train by picking up track from behind it; when a row is scrolled so that it is no longer visible, it is removed from the table view and “enqueued” (ie stored in an array); when a row that is not visible is scrolled so that it becomes visible, the data source should first check to see if there are any enqueued views, and if so it is then added to the view hierarchy and displayed.

What this means is that hundreds of rows can be displayed in one control without a large performance hit, and is one of the optimizations that makes the iPhone UI so responsive.

Lists in Echofon

After class-dumping, you can see that Echofon implements their list views in pretty much the same way as Tweetie, using two main classes:

• FastTableView: A subclass of NSScrollView which is the list control.
• FastTableCell: A subclass of NSView which represents a cell used for the table view.

Although not as explicit as the enquing/dequeuing in Tweetie’s list control, it would seem that FastTableView does a similar job as it has declared on it -popCellForRow:fromArray: and -popSpareCell.

Also to note is the use of NSControl and not NSView as the superclass of the table “cell” object, unlike with Tweetie. I would guess that this is for some of the additions that NSControl provides, perhaps the target/action mechanism.

Final word

When displaying large amounts of data in a list, as many applications do, often NSTableView is not enough. It is a pretty performant class, but when you start doing things with variable row heights, it isn’t really cut for the job. Nor is a class such as NSCollectionView; again it doesn’t implement variable row heights and lots of items can slow it down.

It seems that using view objects for each row, which have an established presence in the view hierarchy is the way to go, if you have the optimizations on top of this. For one you get the added convenience of using instances of NSView, and not simply working with NSCell.

As a final note, a quote I recall from Marcus Zarra’s book on Core Data says:

The lesson I took away from that story is to expect my users to put thousands of times as much data into my application as I would ever consider reasonable

When working with large quantities of data, it is these kinds of optimizations that make your app more responsive and provide a better experience to the user.

As developers, it is hard for us to detach ourselves from what we do and cater to the user. We live on the other side of the fence and are often restrained from making the right decisions because of the way we think, and usually need an objective opinion. We have the curse of knowledge by being so deeply focused in on our software, and what seems intuitive and easy for us is unlikely going to be the same for the people who use our creations.

Thinking from the user’s perspective

The amazing thing about a lot of usability and application design is that most decisions come down to simple thought of how your software is going to be used, and to anticipate and accommodate the user’s various needs. It’s about thinking “I shouldn’t put that text field there because the relation to that other form is confusing” or “I should relabel that button because the current label is misleading”.

As software developers, our main subjects are not computers (even though we do instruct them on what to do) but rather people. We have to be psychologists to some degree and accommodate their needs – our software of which is an end to a means.

The reality

As Matt stated on an earlier MDN show podcast, users want to spend as little time in an application as possible, so that they can get on with their lives. But because we have an affinity with the software we produce it is often hard to detach ourselves from the way we go about our business and think in this way.

Of course this doesn’t mean that we shouldn’t design and architect our applications in a maintainable way, and doesn’t mean that we should write crap code that looks like something the dog threw up. However bear in mind that the user doesn’t actually see any of this. To paraphrase Gemmell again, all the user sees of our applications is the interface.

At the end of the day, users couldn’t care less whether you have a PHP backend or the UI implemented using Rails; they have such a different perspective of what we create. What they care about is how your software solves their problem and how it makes their life easier by doing so.

Rentzsch on Core Audio: The API of Rock Stars

It was the second and final day of the NSConference 2010 Mac Developer Conference and most delegates were tired and a little hungover. But there was another great line up of speakers for the day, and it was another day of socialising and fun, as well as all that other learning stuff.

Perhaps the biggest things I took away from the Mac conference was taking a pragmatic approach to anything which became a recurring theme in a lot of the talks – like yesterday’s conference, extremes were presented such as Dave on not using singletons, but at the end of the day it’s a judgement call and you shouldn’t do or not do something ‘because Dave said it’, but rather because it’s either right or not right for what you want to do. There was also some recurring memes, such as The Matrix and kitties, which snuck their way into certain presenters’ talks, but most of all, I learnt that people can be (fairly) civil when discussing version control, and also that the GPL sucks.

Jeff LaMarche – Writing Super Superclasses

Jeff was still jetlagged and tired, and made several comments as such throughout his talk. However, despite this, his talk on the Objective-C runtime was very interesting and informative to listen to. He started the talk off with a cliché – ‘you can’t see the forest through the trees’ – and likened this to software development. As developers we are often too pedantic and only focus on the little things, but we also need to be able to step back and look at our projects as a whole on a larger scale.

He then went into the guts of his talk, talking about such things as dynamic method resolution and introspection at a lower level. He introduced Objective-C as different from other languages in terms of the patterns used and also touched on a criticism by others that it is missing things, however this is by design and not simply an oversight.

He then started talking about his SQLitePersistentObjects project which leverages the Objective-C runtime in several ways, and then demonstrated some of these features such as dynamic method resolution using IMPs and was well explained with the associated pros and cons of using certain runtime features. Like many of the other talks, he explained the limitations of using the runtime, for example Apple may not approve apps for the App store that use it, and also to be pragmatic about its use and not simply use it because you can.

Andy Finnell – Brushing up on OpenCL

I’ll be honest, after listening to Andy’s talk, I felt stupid. And I think there were other attendees around the room who were in a similar boat. He opened up with a demo, which was a great start to his talk, a demo which simulated the effect of watercolours on a canvas, and leveraged OpenCL to provide the graphics and calculate the drawing of the pigment and the interaction with the surface.

Although the maths and physics was way above me (and wasn’t helped by lack of sleep) it was still an informative and interesting talk, and I liked the structure of the presentation – cool demo at the beginning which made you interested then the rest of the time spent explaining how it all worked.

Andy also opened with a short intro on OpenCL and how it operated which was nice for those who hadn’t been at Drew’s Concurrency workshop on Sunday, however it would have been nice for this section to be expanded a bit, with less of a focus on the mechanics of the demo.

The presentation was also entertaining with accommodation for British spellings (“watercolo(u)r”) which is always a nice touch and other comical remarks and slides which helped a bit when it came to digesting the hardcore code samples. The coding side was also a nice contrast from the higher-level talks that were presented over both days of the Mac conference which also made it a useful and informative talk.

Dave Dribin – Version Control System Shoot Out

[Apologies for not having an accompanying photo]

Dave’s talk was all about version control and mostly a history or comparison of the different VCS’s out there. There was a feeling before the talk that it could go horribly wrong but Dave kept it pretty objective and didn’t particularly favour any of the VCS’s.

He presented the history of version control systems first, with SCCS, RCS, CVS, SVN and other systems that use similar acronyms, before moving onto distributed version control with Git, Mercurial and Bazaar, quoting Linus’s talk where he explained the naming for Git: ‘I’m an egotistical bastard and I name all my products after myself, first Linux and now Git’. With all the version control systems he presented the pros and cons, and only discredited Git slightly. Overall a pretty well rounded talk for the allotted time of about 35 mins.

Graham Lee – Code Signing

Graham had been given the opportunity to present at very short notice, and it was very well executed. It was astounding the quality and detail of his talk despite the little preparation time that he had, and he had a great presentation style which was very entertaining. He also included lots of puns and other fun comments, such as a reference to a hypothetical harmful piece of injected code which he called Malicious Monster and also referenced as Malicious Library. For those who didn’t attend, the reference to the Matrix had become kind of a meme by this point and even though Graham had prepared his presentation in about 24 hours he still managed to fit it in.

He also did a live demo which was very useful and demonstrated some of the code signing in action; he also anticipated our needs well by cutting a few minutes short in aid of food. Overall a brilliant, informative presentation.

Aaron Hillegass – The Many Faces of Data Persistence

Aaron’s talk was – as you probably guessed – focused on data persistence and the what the options are on Mac OS X. He started off by stating ‘The file is dead’ and explaining how his HDD is essentially a cache for data that is stored in the Cloud, which prompted him to comment ‘Long live the cache!’. He used the example of iWork on the iPad in that it uses a “Library” to store files which is essentially an abstraction for the filesystem and that this is the way forward.

He then went on to talk about archiving in Cocoa and Cocoa Touch, discussing Keyed vs Unkeyed archiving and the associated pros and cons. He also presented a timeline of events in terms of data persistence, from the early 90’s with NeXT right up until Core Data in 2005. He presented some nicely formatted object graphs of some of the Core Data things which was also useful.

He spent most of the second half of the presentation talking about his new data persistence project, BNRPersistence, which provides classes that wrap Tokyo Cabinet which is used to store the data, which received much applause from everyone when he announced that it was open-source, available on GitHub, and not licensed under the GPL. It was certainly an interesting project and he had some numbers for certain cases compared to Core Data and it performed much faster. But he was dealing with object graphs that had 1K and 1M objects and for “everyday” use with smaller objects it was unclear whether BNRPersistence would be better than Core Data because he didn’t have any figures on it.

What I liked about Aaron’s talk which I don’t think any of the other speakers did was that he was more engaging with everyone whilst he was talking – his style was like a lecture, but he periodically checked that we were all following everything, something which I guess comes from the teaching which he does, and was a nice touch.

Cocoa Rumble

The rest of the allotted time had been reserved for something different, in the form of a “Cocoa Rumble”. Earlier in the day, Scotty had announced that people could put their names in a hat to be chosen for this mystery event. Names were picked out of this hat and each person chosen was assigned a speaker from the conference.

The combined speakers and delegates were then split up into three groups and had to pick from the hat which now contained another set of slips of paper, which had written on them different “Core–” frameworks. The three chosen were Core Text, Core Audio and Core Image, and the teams had some time to prepare a presentation for why their framework was the “Core of the Year”. All presentations were very entertaining, with talks from Mike, Wolf and Graham and at the end, Core Image (presented by Graham) won for the compelling reasons that he had put into a table.

Whilst the teams were preparing, there was also a chance for the speakers and some of the delegates to provide tips, and there were some great tips from such people as Uli who provided a load of cool Xcode tips, Aaron on having the old Xcode documentation browsing behaviour, and Jeff on conditional build settings.

A nice fun end to the day, with something different and all in the community and social spirit.

Final thoughts

It was my last day of NSConference and what a brilliant conference it had been, with Matt Gemmell’s workshop on Sunday and the Mac developer conference too. It was great to socialise with loads of Mac developers who were all really friendly and I entered into some interesting discussions, and I took a great deal away from the conference which was something that Scotty laid out as one of the goals at the beginning.

I would like to thank Scotty, Tim, Dave, Rob, Simon and all the other people who made NSConference possible, because it was a great experience indeed, and to all the great people that I met there. Thanks also to Uli for setting up the NSConference Reflector.

It was the first day of the NSConference 2010 Mac developer conference and a great lineup was ahead.

In terms of the day generally, it was a brilliant experience. It was well organised and many thanks go to Scotty, Tim, Dave and all the other NSConference staff. The WiFi (although irritating that you had to keep filling out the signup form) worked quite well and you could get some pretty good speeds, which was good considering that the room was filled with over 100 developers, almost all of which I imagine had a Mac or iPhone for most of the day.

It was also a great social event, and the breaks were a nice chance to go around and talk to someone you’d never met before and have some interesting discussions. It was also nice to be in this tight community, separated from all the “normal” people who were also around at the venue.

In terms of the talks generally, I felt that they were all very well done and it was clear that they had put a lot of work into them. The presentations were very well laid out and simple, and not wordy and the speakers all obviously knew what they were talking about and had lots of interesting things to say. However one big thing that I felt could be improved on was the interaction with the audience – that is, many of the slides were in more of a lecture-style and although a couple made up for this with a Q&A at the end I thought this could be improved upon.

The Speakers

Scotty

Scotty kicked off the morning with a nice introduction to the conference, welcoming everyone and thanking us all for being here. He presented his recent case of being rushed into hospital for a “routine” operation as a metaphor for what we’re doing here, and he explained how even though he has little knowledge of the detailed ins and outs of the medical profession, he had a respect for them due to the reputation that the collective members have earned over the years. This was related to Mac development and our collective ‘responsibility to the platform’ and what we do, and the expectations of the Mac or iPhone platforms which is ultimately our responsibility. He also talked about how there is pioneering but also sharing of ideas in the medical profession and again linked this to our role in the Mac/iPhone/iPad community.

He also went on to talk about the community spirit, and emphasised that all the speakers had given up their own time (and money) to be here which because of this, and was a nice to start the day.

Mike Lee – Conference Keynote: Engineering Life

Mike’s presentation was evidently something slightly different and original to start the day but was a nice sideline to our ability to crank code, and was more thinking at a higher level about what we do, and perhaps being a bit more philosophical about it. He was relating what we do and our profession to life in general, and how we can ‘engineer life’. He defined problems as ‘reality we do not like’ which was a topical tie-in with software development since problem solving is one of the key aspects to what we do.

Mike also used several anecodes during his presentation which brought in a realistic sense rather than something purely theoretical, reality which is often missed when talking about software and software development, with purely theoretical statements. He also likened the Universe to a computer in that both are simply entities which are constantly changing state.

The next part of the talk became perhaps a little morbid with discussion on ‘Death 101′ with the conclusion that ‘death sucks’ but you can’t really do anything about it and you’ll be dead in the ground so won’t care about it anyway. However he also likened this to fear and how you can engineer your way around fear and tackle it head-on rather than let it get the better of you. He also talked about having a legacy and a part of you that lives on when you die by accomplishing something that you are remembered for, which can perhaps give you a kind of immortality.

He finished on the note of ‘be the hero’, and overall the talk was an interesting and somewhat unusual. I heard later on that there was about a 50/50 split on people who liked/disliked the presentation but I thought it was an interesting, though-provoking topic and good to be a part of.

Wolf Rentzsch – Spelunking OS X

Wolf started with the statement that he had ‘90 slides in 60 minutes’ and it was pretty fast-paced, although for the most part fine to follow. He dug into Mac OS X under the hood and ways you can access this information and interact with it, introducing such tools as otx, otool and class-dump.

The low-level nature of his talk was a great contrast to Mike’s previous talk which was a demonstration of the breadth of talks within NSConference and was more of a code and tool-based talk. He introduced hexadecimal editors such as HexFiend, which ‘are your friend’, then went on to deal with different sections with prying into OS X internals such as static analysis with strings and files, and code injection.

The great part of presenting these tools was the accompanying screenshots of a terminal and the associated output, and also examples of useful commands and how they could be used, which was probably the killer feature of the presentation for me. He also had a clear presentation style and after talking to him later at the bar was a nice, bubbly person to talk to and obviously knows his stuff.

As a suggestion for improvement it would have been nice to see a live demo of some of the tools in action – he had some screenshots of probing applications such as TextEdit, but a live demo of the tools live would have been a nice addition.

Dave Dribin – Clean Code

I think that Dave’s presentation was perhaps my favourite of the day and talked about different ways of writing clean code and bad ways that can introduce “code smell” and ways to get around this and I agree that it is an important part of being a programmer.

He used the analogy of the iPhone as a way into the presentation; with the divide between internal and external quality – the external beauty is the interface that is seen by the user but the internals are the code that we write and sits behind the scenes. With an application it’s the difference between a beautiful interface and the underlying implementation of that in code.

The presentation was filled with quite a lot of tips, such as guidelines on naming classes and common principles such as DRY (Don’t Repeat Yourself) and OAOO (Once and Only Once) with the example of using enumerations or constants for dictionary keys instead of repeating strings throughout your code.

The Q&A was also useful and for most of the other talks there wasn’t time so it was a nice feature to be able to ask questions about the content discussed.

Drew McCormack – Data Presentation in Mac Apps

Drew lead into the presentation by talking about his scientific background and explaining how different data can be displayed and visualised in different ways. His presentation was also nice because it was one of the ones that wasn’t directly related to churning code and was more about the UI and talking about the various controls – standard or custom – and where they are best used.

I liked the format of looking at these different controls – he presented images of each and then talked about the advantages and disadvantages of each. This was particularly useful when comparing controls, such as the NSTableView and the NSCollectionView, and his slides were perhaps the best of the day and contained very little text on them, just visual cues such as images and the likes.

To this end I learnt a lot about how different views are implemented – he explained using Tweetie (Mac) as an example that it uses an NSTableView to display its list of data, and also Versions implements some of its custom controls using HTML, CSS and Javascript with WebKit.

Near the end he did talk about non-standard controls and focused on drawing graphs with CorePlot. However he spent quite a long time talking about this, which although interesting it would have been nicer if he’d demonstrated a few more, different controls.

Marcus Zarra – Core Animation

Marcus started his talk by explaining how Core Animation wasn’t just for designers, and used himself as an example of a non-designer, but that it could still be used to enhance or help create sleek interfaces. However he also warned that Core Animation can easily be overused and turn a simple, clean UI into something horrible and even very unintuitive. He also explained how Core Animation, although its interface is quite simple, it is also very powerful.

He gave a few examples of using Core Animation, and then gave a live demo of an application that was doing lots of complex animations using Core Animation and how smooth and seamless they all were. It was evident that he had spent a lot of time on the project and he explained how the rotating gears displayed were constructed as paths which was a nice touch to the talk, to get a real demo application.

However even though he had an hour slot, he only used about 35 minutes talking and left the rest of the time for questions, which was quite a nice idea since it was more engaging with everyone rather than simply a lecture. However, it would have been nice for him to use more of his allotted time to show some more Core Animation examples.

Whilst providing an interface to the defaults system, the NSUserDefaults class can also be used to access command line arguments that were passed when the executable was launched, which have already been parsed and are accessed in the same way that other defaults are. This can be a great convenience when dealing with applications that accept command line arguments, such as command line tools.

Defaults domains

Defaults are organised into domains, each of which are assigned a name and are used to separate defaults intended for different purposes. Domains can either be persistent or volatile – persistent domains persist their defaults to disk and remain if the application is terminated and relaunched. Volatile domains only exist from the point at which they are created to when the user defaults object is deallocated.

The standard defaults domains – listed in order of precedence – are:

1. NSArgumentDomain – this is a volatile domain that contains any command line arguments that were passed when the application was executed.
2. The application-specific domain – the persistent domain that is based on the application’s bundle identifier. At current the defaults for this domain are stored in a .plist file at ~Library/Preferences/<ApplicationIdentifier>.plist
3. NSGlobalDomain – a global defaults domain that is intended for use by all applications running under the user that the domain applies to.
4. Languages Domain – these are volatile domains used for language-specific defaults based on languages set in the NSGlobalDomain under the AppleLanguages key.
5. NSRegistrationDomain – a volatile domain that allows “factory settings” to be set by the application. This provides a fallback so that the application can always rely on NSUserDefaults to return a value for certain defaults, even if they have not yet been overridden and saved in the defaults database in the application-specific or global domain (this is useful on first launch, for example).

The order of precedence is important – when you request a value for a given key, the defaults domains are searched in this order. The first key that is found that matches the requested key is used. This means that, for example, if a key is present in the application-specific domain and also in the global domain, the value set in the application-specific domain will always be found first and used.

Parsing command line arguments with the NSArgumentDomain

The NSArgumentDomain is a particularly useful domain for applications that use command line arguments. The domain is volatile, and when created the defaults dictionary is populated with any command line arguments that were passed when the application was executed.

Command line arguments that can be parsed and used by the NSArgumentDomain must take the format:

-name value

The argument is stored as a default with key of name and value of value.

At this point accessing values passed in on the command line is the same process for accessing any other defaults. For example running an application as such:

MyApplication -aString "Hello, World" -anInteger 10

Allows the command line arguments to be retrieved as such:

NSUserDefaults *standardDefaults = [NSUserDefaults standardUserDefaults];

NSString *aString = [standardDefaults stringForKey:@"aString"];
NSInteger anInteger = [standardDefaults integerForKey:@"anInteger"];

NSLog (@"aString argument: %@\nanInteger argument: %d", aString, anInteger);

With the following output:

aString argument: Hello, World
anInteger argument: 10

The importance of domain precedence

The NSArgumentDomain has the highest precedence when a key is searched for in the user defaults, and as such defaults set in different domains with the same keys as the command line arguments will be temporarily overridden. For example, if the application is invoked from the command line as follows:

MyApplication -myKey "Foo"

but myKey also exists in the application-specific defaults domain with a value of “Bar”, then calling:

[[NSUserDefaults standardUserDefaults] valueForKey:@"myKey"];

will return “Foo”. The default set in the application-specific domain is not overwritten, but the default in the NSArgumentDomain is encountered first as it has the highest precedence.

But for us Cocoa developers, they aren’t that easy to implement. You can easily create an NSOutlineView and set its highlight mode to “Source List” but none of the other Source List features come built in out of the box, such as the ability to display badges or icons for items.

PXSourceList

I created PXSourceList to help address this issue. It is a reusable control (within the context of Source Lists) compatible with Mac OS X 10.5 and higher. It makes implementing Source Lists in your applications easier by adding the following main features:

• Automatic Group highlighting of top-level items – the text for Group items appears in a dark blue colour and is normally displayed as capitalized.
• Support for Badges – these are dark blue capsules displayed to the right of certain items that display a number.
• The option to display an Icon for each row – a small image that provides extra visual information for each row.
• Right-clicking support to display context menus.

Getting the control

The source is available to download from GitHub.

More Information

More information about PXSourceList is available from the project page.

There is also documentation available – a link to this can be found on the main project page or from the page on GitHib.

If you have any other questions then feel free to get in touch and I’ll be happy to help.

Some developers try and fight Interface Builder, and would rather code up the interfaces rather than let Interface Builder do most of the work for them. Of course, there are instances where this may be useful, but in the grand scheme of things IB is a tool which has lots of useful features that makes interface design a much easier process.

Layout and alignment

Interface Builder provides blue guides to aid positioning of objects, in accordance with the Apple Human Interface Guidelines. However, if you want a tighter grain of control over the layout, there are other guides which help you with this.

Pressing option with an interface object selected causes red arrows to be displayed on the four sides of the object, with labels displaying the number of pixels from the frame of the object to the edges of the container.

With the option key still held down, placing the cursor over another interface object will show you the spacing between the frame of the selected object and the frame of the object you have the cursor over. This can be useful in times when making sure objects have equal alignments with neighbouring objects, or within the window itself.

There are also the Align Vertical Center in Container and Align Horizontal Center in Container options from the Layout > Alignment menu which are useful in centering objects within their container (and which I personally think should also have keyboard shortcuts associated with them).

Option-drag to duplicate objects

It really does what it says on the tin. To duplicate objects just hold down the option key then drag an object. A clone of the object will be created which you can then move to the desired location.

Decompose and Simulate Interface

These are two useful options that are accessible from the File menu.

The first is Decompose Interface. An advantage of using NIBs is that they can be loaded lazily – that is, only when the contained objects are actually needed by the application. This can reduce the memory footprint and loading times, which is particularly useful when developing iPhone applications due to the somewhat limited system resources available.

Therefore a common design pattern for Cocoa/Cocoa-Touch applications is to share different objects – be that menus, windows, view controllers and such – across multiple nibs – not necessarily one per nib, but perhaps two or three that are needed for a particular part of the application and have to be loaded together. What the Decompose Interface action does is split objects in the current nib into separate nibs, which can then be saved and then loaded lazily by the application in this way.

The other action, Simulate Interface, is a convenience when designing an interface; instead of having to go back to Xcode and Build and Run to see what the interface looks like, you can do it straight from Interface Builder, which will simulate the current window and its contents.

However, note that if you use any custom views, any custom visual or behavioural attributes will not be implemented by the simulator – it does not build your application, just simulates the available objects used by your interfaces from the Library.

Size to Fit

Size to Fit is an option available from the Layout menu (or ⌘=) which resizes a view to a size just large enough to fit its contents.

This is useful after changing the contents of an element to then resize it to just the right size to fit its contents.

Precise selection of Views in the view hierarchy

This is another really useful feature of Interface Builder; when making a selection, hold down shift and then right-click on an element. A menu will pop up, which lists the views in the view hierarchy for that element, from the enclosing Window (or other appropriate top-level container) to the interface object that you have clicked on. For example, when clicking on an NSButton, the menu lists Window, Content View, Push Button and Button Cell.

Where I’ve found this to be particularly useful is with Table Views; the particular part of the table that you want to select very much depends on what you want to do; if you are binding to a column for instance, you will want to select the table column; if you are resizing the headers, you will want to select the header view; if you want to change the row height, you want to select the Table View itself, and so forth.

Selection of these individual components is rather difficult and annoying, and you often have to time your clicks appropriately to select the part of the Table View that you want. However, shift-right-clicking on the Table View means that you can select the appropriate item – be that the table column, the cell for a column or the Table View itself – by selecting the appropriate item from the popup menu.

Smart Groups

Smart Groups can be created in Interface Builder much like smart groups in applications such as the Finder or iTunes. These are listed in the Library window, along with the other object groupings.

Smart Groups provide a means of filtering objects based on a predicate (or filter) based on such properties as object label, the most recently used objects, or the kind of class an object is. This last property can be especially useful. For example, if you want a Smart Group that lists all NSView objects or subclasses, you can set the predicate to:

<Is A Kind Of> NSView

And the group will contain all NSView classes or subclasses.

Smart Groups can be created by clicking on the actions button at the bottom of the Library window and selecting New Smart Group.

Font Menu

Another useful menu is the Font menu, which allows you to set the font and font attributes of items in your interface. This can be useful when setting fonts of controls or cells, such as changing the font size, weight or colour of a cell in an NSTableView, for example, which saves you having to do it with code.

Info Panel

The Info panel provides useful information about the nib that you are currently editing and its contained objects. It allows you to specify a deployment and development target, and shows any errors that your interface may have when deploying to that target.

For example, placing an NSCollectionView instance in a window and selecting a deployment target of Mac OS X 10.4 will show an error that the NSCollectionView class is not supported on versions of OS X prior to 10.5.

The Info panel can also show useful information about layout, for example if a window lies partially hidden off the screen which means that it will be partially hidden from view when unarchived and displayed.

Reinventing the wheel

I think that in most cases this is true, but I was hesitant to start this post by screaming to never, ever, under any circumstances whatsoever reinvent the wheel, because I think that sometimes it can be necessary or at least justified.

I wrote last week about programmers who make their lives difficult for themselves by doing things the “wrong” way, essentially due to their ignorance or inexperience with whatever they’re doing. For this class of programmers, the saying “Don’t reinvent the wheel” probably sticks.

But there are some situations where it can be beneficial to reinvent the wheel, so long as you know why you’re doing it and it’s for the right reasons:

1. The current options out there don’t suit your needs. Sometimes you want to re-implement something that is already out there, because it doesn’t do what you want to do, which compromises some core functionality of what you want to achieve. By implementing this yourself it will make your software better in some way and will be a worthwhile use of your time.
2. You want a lighter version of what’s already out there. You feel that the options out there are too bloated for what you want (often because they are generic) so rolling your own is a way of making your software more efficient. Stack Overflow user Ólafur Waage actually did this with his blog, Cyborg Zombie Ninja Pirate (CZNP) which he explained and justified in his first post:
   

   I am sick and tired of large bloated CMS or blog systems. Wordpress I’m looking at you.

   I’ve been a fan of the idea that people who are smarter than you should do their smart work for you. And I tried my best to apply that to the current blogging systems out there. So I said enough is enough. I’ll make my own.

   Which is something (ironically) I agree with. By doing so it meant that he had a more efficient and more favourable option than what was already out there.

3. As a learning experience. Although not perhaps for use in actual products, sometimes I will implement something that is readily available in order to learn from it, perhaps for a side-project or something which isn’t constrained by time or resources. Although it often won’t make my life easier, it will help broaden my knowledge on a particular area, which I think is an important supplement to software development.

It’s very easy to feel the need to re-implement something that’s already out there, but make sure that if you do it’s for the right reasons and the end result will have made your extra efforts worthwhile.

Most of the time, Cocoa fulfills the promise: Common things are easy, and uncommon things are possible. If you find yourself writing many lines of code to do something rather ordinary, you are probably on the wrong track.

And I don’t think that this is unique to development with Cocoa – a lot of libraries these days promote ease-of-use for the developer.

However, it seems that a lot of programmers love to make their lives more difficult, by not thinking about what they’re doing to solve a problem, and go in blind to find something that works – perhaps as trial and error because they are not familiar with the area they are developing for  – but which makes more work in the long-run by being harder to maintain.

The other day I was browsing the website of European cinema chain Odeon to look up times for a film. I was appalled to see that the “Book Now” form in the right-hand column of the page was implemented using Flash.

I wondered what on Earth was going through the developer’s mind when he (or she, but I’ll keep it simple) decided to implement a bog-standard HTML form by going for something Flash-based. All the features of the form could be easily implemented in HTML and Javascript (there were no fancy effects) – and if the argument there was along the lines of “Yes, but what if Javascript is turned off?” then surely Flash would be a no-go too?

What made it even more annoying was that in his haste to make his life more difficult, he forgot to implement scrolling of the combo box options using the mouse wheel, which when I went to scroll the list caused scrolling of the page instead. So, basically, what the developer has done here is:

• Provided a less than adequate visual appearance (at least compared to what would otherwise be there with an HTML form) which doesn’t look like a “native” combo box.
• Implemented different behaviour than would otherwise be implemented if using an HTML form, thus causing confusion and annoyance.
• Re-implemented something that could be done easily in HTML, with about 3 times as much effort.

If he had just stuck to HTML, CSS and Javascript then there would be a cleaner experience for the user, and one less dependency in the project. It just seems like such a redundant decision.

I often talk about this when people ask about subclassing in Objective-C/Cocoa for the Mac or iPhone. Unlike some other libraries, the Cocoa frameworks promote extension through interaction with the classes, rather than subclassing them, which is often a last-resort. In giving such advice, I often start with something like this:

Firstly, before you subclass an object, you should ask yourself “do I need to do this?”

The general idea here is that people will often go out of their way to make life harder for themselves, in order to change some functionality of a class that could otherwise be done through interaction with the class in one line of code, simply because they do not know of a simpler way, or do not dedicate a bit of their time to find out a more efficient method.

I think that a key skill in any programmer’s life is when you develop a certain intuition for what seems to be right or wrong –  you come up with a solution to your problem which looks too verbose or complex for what you’re trying to achieve, and this sets alarm bells ringing. However, before this is the case (and even when you do develop this skill), it’s important to think about what you’re doing; if you are approaching the problem, do some light research into it and ensure that what you are doing is one of the best, most efficient and painless ways to do it.

Make sure that what you’re doing is for the right reasons, and not simply doing it to make it work.

Of course, they were handing out the usual conference crap, but the nice thing was that this was “crap” that I actually wanted and so hoarded various bits and pieces:

1. Red Gate bag and t-shirt
2. Brochure on FogBugz 7
3. 2 x FogBugz notepads (You can never have too many) and pen
4. DevDays badge and wristband (wristband == free drinks after)
5. A bunch of Stack Overflow trilogy stickers, as well as a Coding Horror sticker
6. A (free!) shrinkwrapped copy of Fog Creek’s Aardvark’d

I was also lucky enough to meet up with and talk to Jeff and Joel, who both signed my MacBook (after Joel proclaiming “I can’t sign a Mac!” and making up by drawing a Windows logo on it)

Speakers

There was an 8 speaker line-up (with Joel speaking twice, or three times including SO Careers) which provided introductory talks on Yahoo! Developer Tools, Principles for System Security, FogBugz, ASP.NET MVC, jQuery, Python and Stack Overflow, as well as an opening keynote from Joel.

The day also started with a funny video put together by Jeff and Joel (which I hope is put up by Joel and Jeff at some point), that included some of the Many Memes of Meta.

(Clicking on the thumbnails of the speakers will show the full sized version)

Joel Spolsky: Opening Keynote

After the intro video, Joel welcomed everyone and  started talking about the dilemma between simplicity and power. His talk was energetic and entertaining, and moved at a good pace. He also had slides, may of which were full of pictures and some which only had one sentence on them (no walls of text) which also made watching more of a pleasure, and emphasised the key parts.

He opened up the talk with some contextual examples of the choice between simplicity and power, referring to a misleading dialog box presented by Outlook, which helped provide an introduction into what he was talking about.

Although not sporting his Union Jack hat (as at London), his talk was littered with English-English words such as “jam” (not “jelly”), an example using Great British Pounds, the pronunciation of “beta” as “beeta” and not “bayta”, and a correction of amazon.com to amazon.co.uk, as well as various other witty or funny comments.

Christian Heilmann: Yahoo! Developer Tools

Christian talked about the Yahoo! Developer Tools, such as the YUI Library, YQL and Yahoo! Placemaker. He covered a broad range of the tools in the allotted hour, and although this was sometimes “bitty” as he demonstrated parts the tools could do, it worked well for what he was trying to cover, and showed the diverse nature of the Yahoo! Developer Tools.

He also showed a lot of practical examples, including his GeoMaker tool which converts websites into maps using the Yahoo! technologies (and has an API providing such output as JSON, HTML and LOLCAT), all of which helped with what he was talking about. He also dealt well with a few technical issues well (like the YUI grid layout working slowly) and made a bit of a joke about it

Since he was giving practical examples and talking around them, and not just reeling off a rehearsed speech it also felt like there was better communication and engagement with the audience, rather than just being stuck behind a glass screen. He also made a small digression at one point of “Everybody who doesn’t do open-source should be smacked” and his presentation was generally entertaining.

Frank Stajano: Seven principles for systems security (PDF)

Frank Stajano is a senior lecturer at Cambridge University, and he talked about systems security. Although what he was talking about was very interesting, I felt that it was more academic than the other talks, and not as “fun” at times.

He did relate to the BBC’s The Real Hustle to help explain what he was talking about, and showed video clips of staged cons from the show, which were used to illustrate some of his principles (such as deception and the likes) but overall I felt that the presentation was a bit more static, the slides quite wordy and not as energetic as some of the other presentations. I’m sure well suited to his PhD students but perhaps not as fitting at DevDays.

Joel Spolsky: FogBugz

Another entertaining presentation from Joel, showing off some of the new features of FogBugz 7 and its integration with Fog Creek’s new hosted distributed version control system, Kiln. I thought that it was a good demo because he went through a series of steps to demonstrate the features – creating a new bug case, assigning tasks, reviewing estimated shipping dates, scheduling and making a code review, the stages all followed on from one another which made it easier to follow and was nicer than having the stages as unrelated previews.

Again, he brought his good presentation skills into it and made it entertaining.

Steven Sanderson: ASP.NET MVC

This was one of my favourite, if not overall favourite presentations. Not coming from a .NET background myself, I felt that it was a really well presented introduction presentation. Steven started off by asking for a show of hands of who had used ASP.NET MVC, but then went on to explain what ASP.NET MVC and the MVC design pattern are, before diving into any code, which gave some background for those (like me) who weren’t familiar with the framework.

He then did a demonstration of various parts of the MVC framework, and coded along the way (although copied and pasted longer code fragments that he had pre-prepared as we “didn’t want to see [him] type”).

His explanations were clear and easy to follow, and his slides were full of images and of a good length. Like Joel’s demo of FogBugz, it was nice that Steven’s MVC demo was like a “journey”, and not just simply unrelated samples of code. He basically started from scratch and created a simple website demonstrating such features as URL routing (rewriting), form auto-generation (and customisation) and uploading content to the server. He stated at the beginning that he’d be going through really quickly, but I found it very comprehensible and easy to follow.

Remy Sharp: jQuery (Download slides)

Remy’s presentation started with an Overview of what he was going to talk about, which I thought was a great way to open, and none of the other presentations had done so explicitly. This created a sense of direction in his presentation, and you could see where it was going.

He started off by demonstrating some of the library features of jQuery, such as the Core functions, Effects, AJAX and Selectors and so on. His slide layout was simple (white background, black text, red text to highlight important parts) which also helped with his presentation, and arrows and red text were used to highlight key points as he explained them.

He also went on to show a live demo of creating a tag cloud from the lists which he was tagged in on Twitter, which he did on-the-fly and was very well done – he came across a few minor problems but fixed them quickly, and went into the afternoon break to finish.

Michael Foord: Python

Michael’s talk was very interesting and almost entirely practical.

He started off by introducing what Python and IronPython were (after getting a show of hands of who had used either before) before providing a live demonstration of Peter Norvig’s Spelling Corrector which Norvig wrote on a plane flight home in less than a page of code; what it does is demonstrate a (much simplified) version of how Google provides spelling correction for searches (i.e. Did you mean x?) and it is written in Python.

Michael explained how the code worked, and fed it into the IronPython interpreter, whilst also demonstrating some features of Python/IronPython such as dictionaries and collection manipulation.

Although the nature of his presentation was such (because he was typing in the code as he explained it) he remained seated for almost the entire presentation which felt a bit static. Also since most of the presentation was an example he didn’t go into more generic features of Python, which I felt would have made a better introductory presentation.

Michael also showed his book, IronPython In Action which is published by Manning.

Jeff Atwood: Stack Overflow

Jeff’s talk was very funny and entertaining, and referred to many different aspects of Stack Overflow, such as one of the team’s motto “Failure is always an option”, as well as a blog post created by someone who had a bad experience with Stack Overflow, Crap Overflow.

His presentation was full of images (no walls of text) and made it easier to follow and more fun. He was also explaining his passion for what he does as well as the love of Stack Overflow for its users. He also explained one of Stack Overflow’s main goals, to leave a “trail of breadcrumbs” for others to see, and also how Stack Overflow can make better writers out of people who ask or answer questions. In short, a well explained, interesting presentation.

I recorded Jeff’s speech and some questions afterwards, and the 20-minute video can be found online.

Taking away

I definitely learnt some new stuff whilst at DevDays – I think I’ll try out jQuery in more detail, and perhaps do something with ASP.NET MVC which looks like a great framework.

I believe that the team have plans to do another set of conferences, perhaps next year, and I’d definitely recommend any developers to go, as a great way to learn about something new, and also to meet and socialise with other devs.