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.

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.

The first day of NSConference 2010 kicked off with two workshops – Concurrency Programming on Snow Leopard by Drew McCormack, and The World According to Gemmell, by the Legend himself, of which I was an attendee.

The session started with a discussion about a certain recently released Apple product which was very interesting and allowed us to present our thoughts on the device. We covered such areas as the human psychology behind it, the display of “real” objects as the interface and the much more emphasised touch interaction including two-handed UI, as well as getting “wanky” about the emotional connection with the device.

Andy had also created a great model of the device, that was the exact dimensions (although the back didn’t slope like the real thing) and half the weight of an actual iPad. This was really useful in the talk from Matt, when he was explaining such things as how people would hold the device.

We also discussed the changing seeds of user interfaces and the switch away from clutter-based interfaces, such as inspector panels which ‘can edit anything that has ever lived’.

Our workshop

A few weeks ago Matt sent an email round to all the workshop attendees asking whether we had any UX topics that we wanted to discuss that could form the basis of the workshop. This was a great structure and in the session we got through 7 or 8 discrete topics, from such topics as the evolution of your app and removing features to when the best time to release your 1.0 is.

Although Gemmell said that he had put the slides together quickly and a bit haphazardly (and Scotty had been fiddling around with the slide animations*), the slides were well arranged, and contained only a few – although thought-provoking – bullet points for each topic, and allowed us to really discuss the ins and outs and how one would go about dealing with these problems. The workshop dynamic really helped this section and the group discussion bit was great as we could all have our opinions heard and commented on, with Matt being the suspiciously-bearded ringleader of the event.

Workshop dynamic

Matt’s talk was arranged as a workshop and consisted of around 30 people. The tables had also been arranged into groups of about 5 or 6 and all of this combined made a great, much more personal dynamic for the session, because as Matt himself put it, we were all participants and it was our workshop, not just his.

It was a great social occasion to this end, and allowed for group collaboration which was a real strength of the workshop and made it a really enjoyable event.

Final thoughts

A brilliant first day to NSConference and a great thought experiment with lots of things to take away and think about. As I mentioned when speaking to Matt in one of the breaks, the Mac/iPhone/iPad platforms are so brilliant partially due to the fusion and interwoven nature of code and design, the latter of which is given a lot of thought in most instances, which made the workshop a very topical and interesting one indeed.

The Mac conference (Monday 1st Jan – Tuesday 2nd Jan) has a lot to live up to but a great start to what I’m sure will be a great conference.

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.

Project Breakpoints

Breakpoints are a great convenience method for debugging your code. However, if you have lots of breakpoints, how do you manage them all easily?

When you add a breakpoint it appears in the Breakpoints folder in the Groups & Files list under Project Breakpoints. From here, you can turn breakpoints on and off and remove them, and change the conditions or add/remove breakpoint actions easily (from the accompanying detail view shown above the Editor pane) without having to navigate to each breakpoint directly. This is a great convenience for batch methods, such as removing all breakpoints.

Groups of breakpoints can also be created, by right-clicking on any number of breakpoints and selecting Group from the context menu.

Breakpoints for a specific source file can also be easily shown using the breakpoints popup list button in the Editor window, which lists the breakpoints detailing the method they are set in, and the line number that they apply to. Clicking on a breakpoint in the list will navigate to the source file and highlight the row that that breakpoint is applied to.

Class Navigation

Class navigation is a convenience for exploring the class hierarchy for a given class. It presents itself as a popup menu in the Editor window, which lists the superclasses, the class itself and any categories present on the class. The class that the menu displays information about is flexible: if the text caret in the editor window is within a class interface (between @interface and @end) or a class implementation (between @implementation and @end), the class navigation popup menu will provide information about that class.

This is a useful tool, especially when subclassing an existing class. Since subclassing builds on the existing functionality and implementation of a class (or classes), it may often be necessary to access inherited instance variables or provide custom implementations for inherited methods. By simply clicking on the class name of a superclass in the class navigation menu, you are taken to the superclass interface, which details the instance variables and methods which you can extend in your subclass.

Code Folding and Focus Follows Selection

As any Objective-C programmer knows, it is not the most concise language in the world – it is far from it, and it is so with some reason. However, this can make the readability of your source files difficult, especially if you are working with a class that has lots of methods implemented.

Code Folding and Focus Follows Selection are two options from the View menu which help to increase the readability of code. Code Folding is a way of folding functions and other braced parts of code into stubs, which makes the code dramatically more easy to read, whilst still providing the first line of a function or code block to show what the folded code is a part of. It can be applied from the View > Code Folding menu, with menu items to fold the code block that the text caret is currently placed in, unfold all items in the current source file, fold/unfold all methods and functions, and fold/unfold all comment blocks.

Focus Follows Selection is another feature used to help readability. When this is turned on, Xcode will highlight the block of code that the text caret is placed in (be it a method/function or other parenthesised block such as an if statement) and dim the rest of the editing area, making it easier to see in which block you are working. This can be very useful for nested loops or where there is nesting of braced pieces of code. It is presented as a checkable menu item in the View > Code Folding menu

Smart Groups

Smart Groups are a way of organising your project files based on a filter. Selecting Project > New Smart Group from the menu and then either Simple Filter Smart Group or Simple Regular Expression Smart Group allows you to create a Smart Group based on a wildcard expression (for example, *.nib would match all files ending in .nib) or a regular expression. You can also select where Xcode starts looking for files in the project folder hierarchy by changing the value in the “Start From:” dropdown box. You can then also select whether the group applies to all projects created in Xcode, or just the project that you are currently working on.

This is an easy way to keep your project(s) organised for you, which can reduce clutter across the Groups & Files list. As with all folders in the hierarchy in the Groups & Files list, it is purely virtual – that is, any items placed in Smart Groups will have no effect on their physical location on disk.

There are two Smart Groups that are present with Xcode by default – “Implementation Files” and “NIB Files”, which contain the project’s implementation and NIB files respectively.

Splitting the Editor View

Often it is useful to edit more than one source file at the same time, in the same editor window. This can be achieved easily by clicking on the Split Editor View button. This will add an extra editor view to the current window, resizing the other editor view(s) to fit. Then, when files are selected from the source list they will be loaded into the currently active editor view. There is an editor bar for each editor view (containing the history list, and method list etc) which is applicable to that view. There is also a resizing separator between the editing views to allow you to resize them.

Editor views can then also be easily removed by clicking on the Close Editor view button on that pane, located under the split editor view button for that editor view. This will resize the other editor views accordingly.

Notably are the object “ownership” conventions which the guide outlines. Ownership over objects determines whether or not it is your responsibility to manage an object’s memory or not. Following this memory management etiquette allows your applications to work in conjunction with other objects and libraries and ensure they follow the accepted memory management procedures; they cover three main points about memory management for objects:

1. Object Creation and Ownership

You own any object you create.
You “create” an object using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc, newObject, or mutableCopy).

This is an important point for managing memory for objects in Cocoa; there is some ambiguity when using methods that return objects on whether you have to manage the memory for those returned objects, or whether this is done for you.

For example, take the NSString class. Several string creation methods exist, which seem to have counterparts, for example initWithCharacters:length: and stringWithCharacters:length:. But what’s the difference? Taking a look at the method declarations in more detail, you will see that initWithCharacters:length: has the method declaration:

- (id)initWithCharacters: (const unichar *)characters length: (NSUInteger)length;

As with all Objective-C methods, the minus sign denotes that the method is an instance method, and in this way you must instantiate an NSString object to call initWithCharacters:length: upon. How do you do this? By first calling alloc on NSString, which is a “method whose name begins with “alloc” or “new” or contains “copy””. As of this, if you create an NSString object using the initWithCharacters:length: method, you must memory manage that object yourself, since you take ownership of that object by creating it.

The method declaration of stringWithCharacters:length: is as so:

+ (id)stringWithCharacters: (const unichar *)chars length: (NSUInteger)length;

The plus sign denotes a class method of NSString this time, and so when calling this method, you do not need to first instantiate an NSString object, instead calling it on NSString directly. In this way, it tells you that you do not need to memory manage the NSString returned, and this will be done for you (since the NSString is returned, it will be autoreleased).

Naming conventions

Naming conventions for creation methods in the Cocoa classes often follow patterns; methods that start with “init” are often custom implementations of NSObject’s init method, and so are instance methods which have to be called on an allocated instance of that class, and have to be memory managed. Creation methods which do not start with “init” are conventionally class methods, and so return autoreleased objects that don’t have to be memory managed.

2. Releasing Created Objects

The second item of the object ownership policy is:

If you own an object, you are responsible for relinquishing ownership when you have finished with it.
You relinquish ownership of an object by sending it a release message or an autorelease message (autorelease is discussed in more detail in “Delayed Release”). In Cocoa terminology, relinquishing ownership of an object is typically referred to as “releasing” an object.

If you have created the object, as established by point #1, then it is your responsibility to release it. This is very important for the maintained stability of your application, because otherwise you will leak memory, which – especially for iPhone development – can affect the performance of your application. Even if it is a small amount of memory, which you may not perceive as being worth bothering about, it is good practice to make your application as efficient as possible.

3. Memory management for objects you don’t create

The third item of the object ownership policy is:

If you do not own an object, you must not release it.

This is important, because you can “overrelease” an object, since you did not retain it initially because you do not “own” it. This can cause the object to be deallocated prematurely, and can cause your application to crash if a message is then sent to the now redundant piece of memory.

Taking ownership of objects

According to point #1, if you do not create an object, then you should not memory manage it. However, what if you are returned an autoreleased object, but want to hold onto it? An autoreleased object will be released by the autorelease pool at the end of the current event, and so if you need to keep it for a longer period of time than this, then you will essentially have a bad pointer to memory that has been relinquished.

In this case, you must take ownership of the object that has been returned to you in a memory-managed state. To do so, simply call retain on the object. This will ensure that it is not deallocated, because you are explicitly specifying that you want to keep the object around until further notice. As long as other objects that have a hold on the object (if there are any) follow the memory management guidelines then the object will stick around for as long as you need it for:

- (void)someFunction:(int)aNumber
{
    // Assume that 'string' is an instance variable; returns an autoreleased NSString
    string = [NSString stringWithFormat:@"Some number: %d", aNumber]; //Retain the string to take ownership so it won't be released
    [string retain];
}

Even though you didn’t create the object, now that you have taken ownership of the object in question, you must also release the object when you are done with it (following point #1) since you now have some form of ownership over it (whether that be full or partial).

Core Foundation classes and memory management

The Core Foundation classes have a similar ownership policy, as stated in the Memory Management Guide for Core Foundation. This is similar to the Cocoa ownership policy:

Core Foundation functions have names that indicate when you own a returned object:

• Object-creation functions that have “Create” embedded in the name;
• Object-duplication functions that have “Copy” embedded in the name.

If you take ownership of a Core Foundation object, you must release it when you are finished with it using CFRelease.

As noted in the guide, if you are returned a Core Foundation object through a function other than one which has “Create” or “Copy” in the name, you do not take ownership of it, and do not need to memory manage it. However, similar to the Cocoa classes, you can take ownership of  a Core Foundation object by calling CFRetain on the object. Once again, do not forget to call CFRelease once you are done with the object.

Keyboard Shortcuts

There are a plethora of keyboard shortcuts in Xcode to perform common tasks associated with various aspects of the development tool. Here is a handy chart of all the Xcode keyboard shortcuts available (note that this chart was created by Colin Wheeler):

All-In-One View

In the Xcode preferences, the default layout is, oddly enough, the Default layout. This is better set to All-In-One, since it adds extra panes to the main window, such as the Page toolbar item, which allows you to switch between the Project and Debug modes with one click, in the same main window. Also, a tabbed menu is added above the editor window, with tabs for Detail, Project Find, SCM Results and Build, which make it easier to access different windows within your project, keeping them within the same workspace. To change the layout to All-In-One, open up the Xcode preferences (⌘+,) and in the General preferences, change the Layout preference to All-In-One.

The #pragma mark directive

The #pragma mark directive is very useful in organising implementation files, especially those with a large number of methods. It can be placed anywhere in the source files, and is used as a way of grouping common methods. It takes the form:

#pragma mark <Label>

Where <Label> is the name you want to associate. For example:


#pragma mark Drawing- (void)drawRect:(NSRect)rect {
// Drawing code here.
}//... other methods here, if necessary

and it allows you to group together methods in the Project Symbols list; with any method signature following the group name being listed underneath the group title you have assigned.

Clicking on any of the method names selects the method declaration in the file and scrolls down to that point; in this way it is easy to navigate around the implementation files, even if they contain a lot of code or methods.

Finding APIs in the documentation

When writing code in Xcode, it is not uncommon for you to need to take a look at the documentation for a particular symbol, be that method, class, or even data types, for example. You could do this by going to Help > Documentation and then typing in the name of the symbol into the search field, and then hitting return.

However, there is an easier way. In your source file, double-click on the word that you want to look up in the docs, whilst holding down the ⌥ (option) key. This will then open up the documentation window, filling the search field in with the word that you want to look up.

Finding declarations

It may also be the case that you want to look up the declarations for symbols, as defined in the headers. For example, you may wish to find the interface for NSObject or the typedef for NSUInteger. Again, this is easily accomplished. In your source file, double-click on the symbol that you want to find the declaration for, whilst holding down the ⌘ (command) key.

Bookmarking Code

Xcode allows you to add bookmarks to your project, not just of source files themselves, but even lines within the files. These bookmarks get added to the Bookmarks section in the Groups & Files pane. To add a bookmark, place the text caret on the line which you want to bookmark, and select Edit > Add to Bookmarks or (⌘+D); the name of the file the line originates from, and the line number will be displayed as the bookmark name, although this can be renamed by clicking on the bookmark name.

Go to Counterpart

Classes are one of the major additions to the Objective-C superset of C, and are used frequently in. There exists class interface and implementation files for any class, and it is frequent to switch between both, such as when declaring a method in the interface, then implementing it in the implementation. There is a button which makes switching between the two easier, titled Go to Counterpart; clicking on it will change the editor window to the implementation for that class, if working within the class interface file, or the interface if working within the implementation file.

Whether the counterpart is opened in the same editor window or another editor window is determined in the Xcode General preferences, with the “Open counterparts in same editor” checkbox.

Simple Housekeeping

When dealing with Xcode projects, the number of files present can quickly mount up, whether that be source code, resources, NIBs or any other files that your project uses. When adding files to the project, Xcode doesn’t add them to any particular directory in the Groups & Files list, so it is up to you to do this. Note that the directory structure in the Groups & Files list is purely virtual – any movement of files within the hierarchy has no physical effect on disk. To add groups to the list, simply right click in the window and select Add > New Group, and once added, groups can be dragged around like you would in a Finder window. Here is a summary of the various groups and files within the project subdirectory:

1. Classes: as it says on the tin, place class interface (.h) and implementation (.m) files in here. It may be useful to group class files based on their purpose, for example naming groups Controllers or Models, etc to make it easier to find the source files when you need them.
2. Other sources: this group is for source files that do not declare classes; main.m is here by default. Since most source files deal with classes, there are usually not so many files in here, unless you are creating a non-AppKit based application, such as a Foundation Tool.
3. Resources: where all the project resources are placed, be that NIBs, or images, for example, this is the place to keep it. It may be useful to group resources based on their function, especially NIBs since in larger projects the number of these can quickly mount up.
4. Frameworks: this is where the frameworks that your project uses are. Xcode adds the Cocoa, AppKit and Foundation frameworks for you when a project is created, but if you need to link against others, this is the place to put them. If a lot of frameworks are being linked to, it would be best to create extra subdirectories to organise the linked frameworks. Frameworks can be added by right clicking in the Groups & Files window and selecting Add > Existing Frameworks..
5. Products: these are the products of building the target(s). Normally there is only one product, your .app application file, so extra organisation of this subdirectory is not usually particularly necessary.

Debugging

A lot of time is often spent debugging your application. The interface can be made more straightforward in the Debugging pane of the Xcode preferences. There is a popup menu labelled On Start: this is how the workspace will change when debugging of your application begins. Its default is Do Nothing, however selecting Show Console, Show Debugger or Show Console and Debugger are useful so that when you begin to debug your application the workspace can update itself accordingly to make debugging a more straightforward process.

Start with Performance Tool..

The Xcode Tools do not encompass simply Xcode and Interface Builder; there are a few other other tools bundled with the package that are useful when testing projects, such as Instruments and Shark. Instead of having to build your application every time then manually loading it into the designated tool, it can be done from the Run menu. From Run > Start With Performance Tool, you can load your application into Shark, MallocDebug or one of the Instruments templates, such as Leaks.