“I have this great idea for a game, but I’m new to iOS development and this goes way over my head. So I’m wondering if you could help with the development or know anyone else who can? Of course, we’ll split the profits.”

Since this isn’t the first time I’ve received such a request, I thought I’d put up my answer here.

It’s not easy getting started, that’s for sure. It can take a long time to go from noob to someone who can make quality apps. Also, not everyone is cut out to be a programmer.

Having a great idea is only the beginning, but the money is in the execution. If you don’t know how to execute, then you might need to take another approach to get the app made.

Even if you can pull off the programming part, that is not enough to make your app a success. You also need to get it to the right people, in the right place, at the right time. That also takes certain skills.

Sell your idea to find your team

Here’s what I would do: To find someone to work on this with you (for a part of the profits rather than work-for-hire), you’ll have to convince them of the potential of your idea. The best way to do that is to make a short demo video. Appsterdam’s Mike Lee wrote a good blog post about that.

With that video you can set up a project on Kickstarter or a similar site, that allows you to raise money from small-time investors and at the same time attract attention from developers and even potential customers. With that money you can hire a professional programmer, designer, and anyone else you need.

Let’s say you raise only $5,000. That by itself won’t be enough to pay for the development of the app, but it will serve as a decent down payment for the people you will hire. With some up-front cash and a convincing demo video, professional developers might be more willing to work for profit sharing.

In other words, if you don’t have the programming or design chops to make the app by yourself, you will have to play the role of a producer (like a movie producer) instead of a programmer, and gather a team of people who are willing to work with you.

Most of these people — if they are any good — aren’t interested in working for profit if you’re not also bringing something to the table. Asking someone to work on your project for a share of the (hypothetical) profits is asking them to invest their time and talent into your idea — and by extension, your leadership — at their expense, based on nothing but a promise of a fat payday. You’d better be ready to deliver on that promise!

But what if someone steals my idea?

You’re putting your great idea out there for the world to see in order to attract investors and talent, so what’s to stop others from simply copying it?

Here’s the thing: it is incredibly hard to make a hit game or app. If your idea is something anyone can build in a handful of days that is guaranteed to sell itself without any effort, then keep it to yourself. These are one in a million ideas and chances are yours isn’t one of them.

Your idea will take many months of dedicated effort to turn into something real and many more to find its way to customers. No one will steal it because no one else will care about it as much as you do or is willing to put in that kind of effort.

It’s not the idea that is worth money, it’s the execution of the idea. Most of the hit games on the App Store are not 100% original ideas — for example, Angry Birds and Tiny Wings are both based on other games — just very well executed versions of those existing ideas.

The idea isn’t really yours to keep

Now personally, I believe that you have to let go of the notion that you can “own” an idea. An idea by itself is nothing. That’s why you can’t really “steal” ideas. On the other hard, you can certainly own the execution of the idea, and that is protected by copyright laws and by the fact that’s it’s just a lot of hard work.

The only way you will ever profit from your idea, is to make sure you are the one with the best version of that idea.

If your idea is truly good but you put out a very basic, average implementation of the game that you programmed and designed yourself, chances are that hardly anyone will care about it. But it might inspire some other developer and a few months later some other team makes a lot of money from your idea but done better. You will have blown your opportunity.

So if you want to be the one with the hit app, you need to be the one making the most amazing version of it. And that requires programming help if you’re not a very good programmer, design help if you’re not a good designer, and marketing help if you’re not a very good business person.

So start working on that video!

Illustration by Oscar S.R. / miutopia (from openclipart.org)

- (BOOL)application:(UIApplication *)application
    didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    DataModel *dataModel = [[DataModel alloc] init];
    self.rootViewController.dataModel = dataModel;
    . . .
}

The app delegate creates the data model object and passes it to the root view controller.

The class may be called something different than DataModel, but that’s essentially what it is, the data model for the app. In a Core Data app, this could be an instance of NSManagedObjectContext.

At some point, the root view controller opens another screen, and it passes along the DataModel object to this new view controller:

- (void)tableView:(UITableView *)tableView
    didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    SecondViewController *controller = [[SecondViewController alloc]
        initWithNibNamed:@"SecondViewController" bundle:nil];
    . . .
    controller.dataModel = self.dataModel;
    . . .
    [self presentViewController:controller animated:YES completion:nil];
}

Invariably, someone asks: “Why not simply ask the AppDelegate for that data model object?”

They propose code such as this:

// Somewhere in SecondViewController.m:
- (void)someMethodThatNeedsTheDataModel
{
    DataModel *dataModel = ((AppDelegate *)[UIApplication
        sharedApplication].delegate).dataModel;
    . . .
}

That looks a bit ugly, but you can always “work around” that with a macro:

// In your Prefix.pch file:
#define MY_APP_DELEGATE ((AppDelegate *)[UIApplication sharedApplication].delegate)
 
// In SecondViewController.m:
- (void)someMethodThatNeedsTheDataModel
{
    DataModel *dataModel = MY_APP_DELEGATE.dataModel;
    . . .
}

The DataModel object is now a property on the AppDelegate class, and you can “just” ask for it whenever you want. Easy right?

I don’t know who came up with this idea, but it seems widespread, especially among beginners. It’s also a quick fix with harmful consequences.

So what is the difference?

My preferred approach requires you to pass the DataModel object (or objects) from each view controller to the next, or at least to those that need it. That seems like more work, but it has an important advantage: your view controllers only depend on the objects that they directly need.

It is a good object-oriented design principle to limit the dependencies between your objects. The looser your objects are coupled, the better.

This is what the principle looks like in a picture:

However, when all your view controllers depend on the app delegate, the diagram looks like this:

The problem is this: As your app grows, it will have a lot of classes that have many interconnections between them. The greater the number of connections, the harder it is to understand what is going on in your code, and the harder it is to make changes. If you’re not careful, your code will become a big mess — and we all know where bugs love to hide.

By using the app delegate this way, you’re adding even more complexity to the web of connections. Each view controller now has to reach out to AppDelegate to get the data it needs to do its job.

You’re also giving AppDelegate too much to do. Before you know it, it has become this humongous class that is responsible for just about anything in your program.

Passing around objects all the time seems like a chore, but it’s the cleaner design. Consider each view controller in your app an island that can function independently of all the other view controllers, given the data model objects it needs for its calculations.

What should the app delegate do?

The app delegate performs an important function in your app but is not intended to be some magic singleton that holds all your data.

It is the place where you receive notifications that concern the application as a whole: the app is launched, the app is about to go into the background, the app has returned from the background, and so on. You should restrict the role of the app delegate to just handling those notifications.

The app delegate is where your app initializes itself — it creates the window and loads the initial view controller, it creates the data model objects or Core Data store — and then it passes control to that initial view controller. Beyond that, the app delegate should just handle the application-wide notifications and do nothing else.

So if you feel tempted to write,

[UIApplication sharedApplication].delegate

anywhere in your code, then it’s time to rethink your class design.

In this tutorial you’ll build StoreSearch, an app that lets you search the iTunes store for songs, movies, books and software. You’ll learn about making your mobile apps talk to web services, iPad programming, internationalization… and lots more!

You can get the iOS Apprentice at the Ray Wenderlich store.

If you pay peanuts, you get monkeys

Every day I get inquiries from potential clients, much more work than I could possibly handle. Some of these inquiries are quite unrealistic, but the 150 Euro per hour price tag is quite effective in scaring off the dreamers with a hundred bucks and an idea. (It’s also basic economics: If you can’t keep up with the demand, raise your prices.)

My hourly rate may seem high but one thing I learned over the past year is that I’m a really good developer and that I’m worth it. Asking for big money obviously drives away a lot of potential clients, but the clients that I do get are serious about what they want, their projects are interesting, and they understand what it takes to make a quality product.

As any creative professional can tell you: “The more you pay me, the more you can expect of me, and the harder I will work to make the end result really wonderful.”

Inspired by this excellent rant, I also decided to take on only the really hard projects, the ones that are too hard for other developers. Simple apps are boring — I need challenges that allow me to make the most out of my skills!

How to find work

I received an email today from a fellow freelance developer who found himself in the same spot I was in a year ago:

“I was wondering if you had any more luck finding work via internet resources since your post was written? I figured I’d look around at a couple of the big freelancing sites and see what I can find, but I think it’d be so much better if it was more personal.”

There are two things I did that made all the difference. First off, I started blogging. There’s always a need for good information about any topic in your field, so if you write quality posts you’ll build up a name for yourself and people will come to regard you as an expert.

With a blog full of quality material, you’re no longer some anonymous developer but someone who has already demonstrated his skills. It makes it easier for clients to trust that you can actually deliver.

Putting some of your own code on Github is another way to pull that off. I have created some open source components that people find useful, and that gets my name out there too.

The biggest thing I did, however, was to write for www.raywenderlich.com. That is a popular site with tons of great tutorials and my contributions seem to be appreciated. I also wrote a 750-page ebook called The iOS Apprentice that is sold through Ray’s site, and contributed to the ebook iOS 5 By Tutorials.

A lot of this is hard, unpaid work, but it pays itself back in building up your reputation. I’m probably not as well known in iOS circles as Matt Gemmell or Marco Arment, but I’m working on it.

Not what you know, but who you know

The second thing is to get in touch with other developers. Networking is a great way to get referrals for jobs. Many developers have too much on their plate so they’d be happy to pass on work to other developers they know and trust. Some will also subcontract out certain parts of their projects.

There are many ways to network. You can get in touch with other developers that are local to you through groups such as CocoaHeads and meetings such as NSCoder Night. If no such group exists in your area, you might consider setting one up yourself.

You don’t have to restrict yourself to just meeting iOS developers, of course. Mobile developers, web developers, designers, start-up founders, these are all useful people to get to know.

Face-to-face networking is probably best, but on the internet there are plenty of places to get in touch with other developers as well: forums, blogs, IRC, Facebook, LinkedIn, you name it. Hanging out with your peers has never been easier…

The transparency in a PNG file comes from the so-called “alpha channel”. For every pixel not only red, green and blue values are stored but also an “alpha” value that determines how transparent that pixel is. A value of 255 means this pixel is fully opaque, 0 is fully transparent, and anything in between will mix the pixel’s RGB values with the underlying color.

This is probably an old trick, but by saving a JPEG image not as one but as two image files you can still have transparent images. The first image is the regular JPEG with as much compression as you can get away with, the second image is the alpha channel. This is a grayscale image with black representing fully transparent, white fully opaque, and gray everything in between.

We can combine these two images at runtime to make the image transparent again. Because of the JPEG compression we lose a little bit of clarity but if you tweak the compression settings you can usually get away with it.

I wrote a simple category on UIImage that lets you do this.

Preparing your images

1) Export your image from Photoshop as a PNG with transparency.

2) Export the image again as a JPEG, using suitable compression settings. The background should have a solid color, typically white or black but any color will do.

3) Save the alpha channel to a separate JPEG or PNG image. I couldn’t find an easy way to do this from Photoshop, but the ImageMagick tool can do it without problems.

If you have ImageMagick installed, open a Terminal and go to the folder that contains the exported PNG image. Then type:

convert -alpha Extract -type optimize -strip -quality 60 +dither \
    Source.png Alpha.jpg

This extracts the alpha channel from the PNG image and saves it as a JPEG file. You can tweak the level of compression with the -quality parameter. If you specify “Alpha.png” instead of “Alpha.jpg”, ImageMagick saves the alpha channel as a grayscale PNG-8 file. You should use whichever one makes the smallest file size.

Combining the images

1) Add the two JPEG images (the non-transparent source image and the alpha channel) to the app.

2) At some point, call the mh_combineWithAlphaImage:backgroundColor: method to combine these two images into a new, transparent, image.

3) Depending on your app you may want to do this only once and then store the transparent image as a PNG in your app’s Caches folder.

That’s it, quite easy.

Some notes

The alpha image does not have to be a JPEG, it can also be a PNG file. If it is a JPEG then it can have different quality/compression settings from the main image.

The current implementation works well but is not as fast as it could be. It also uses more memory than is strictly necessary. I might rewrite this at some point to use the Accelerate framework or Core Image.

Not all images compress better as JPEG. You should use JPEG only where it makes sense.

Check out the source code at Github.

Bird image by Sias van Schalkwyk

Especially for iPad apps that is great, because all of that screen space means you probably want to divide it up amongst more than one view controller.

Today I was messing around with these new container APIs and built my own tab bar controller. It works just like a regular UITabBarController, except the tabs look quite different and the pages slide in and out of the screen with a nice animation.

If you want to learn more about how to do this, then check out the source code or get the iOS 5 by Tutorials ebook. It has a full chapter on these new view controller containment APIs, plus twenty or so other chapters on more iOS 5 goodness!

As you can see, the light blue color makes the bar button hard to see and its label hard to read. Changing the background color of the button is really easy on iOS 5 because its UIBarButtonItem also has a .tintColor property. But if you still need to support iOS 4 then you’re out of luck.

In that case, the only solution is to put a UIButton inside the UIBarButtonItem and give it a background image that looks like a regular bar button. It’s a roundabout way of doing things but it works.

Previously, I would draw these bar button-lookalike images myself in Photoshop. By setting the appropriate layer styles on a rounded rectangle vector object you can make a decent approximation of what a real bar button item looks like.

This time, however, I wanted to take advantage of the actual images that UIKit itself uses to compose the UIBarButtonItem when you change the tintColor of the underlying toolbar or navigation bar.

To pull this off, you can download UIKit Artwork Extractor. Compile the app and run it on the Simulator (or on your device). It will extract all the images that are built into the various iPhone and iPad frameworks and save them to a folder on your computer.

After you have extracted the images, go into the “Shared” subfolder and look for:

• UITintedButtonHighlight.png
• UITintedButtonMask.png
• UITintedButtonShadow.png

You can combine these three images with a fill color to produce a tinted UIBarButtonItem background image, like this:

The actual layers pane should look like this:

The “Fill color” layer is simply a rectangle filled with the tint color that you want the button to have. As you can see, both the fill layer and the “shadow” layer are clipped against the red “mask” layer. If you don’t do that, the button won’t have a transparent background in the corners.

To export the image, merge all the visible layers (but not the background!) and save the image as PNG. This gives you a 11×30 pixels stretchable image.

You can use the following category to create the fake bar button items in your code. It requires that the image named “BarButton.png” is added to your project.

@implementation UIBarButtonItem (FakeButtons)
 
- (id)initWithTitle:(NSString *)title width:(CGFloat)width target:(id)target action:(SEL)action
{
	UIButton *button = [UIButton buttonWithType:UIButtonTypeCustom];
	[button setTitle:title forState:UIControlStateNormal];
	[button addTarget:target action:action forControlEvents:UIControlEventTouchUpInside];
	button.titleLabel.font = [UIFont boldSystemFontOfSize:12];
	button.titleLabel.shadowColor = [UIColor colorWithWhite:0 alpha:0.5];
	button.titleLabel.shadowOffset = CGSizeMake(0, -1);
	button.frame = CGRectMake(0, 0, width, 30);
 
	UIImage *image = [[UIImage imageNamed:@"BarButton"] stretchableImageWithLeftCapWidth:5 topCapHeight:0];
	[button setBackgroundImage:image forState:UIControlStateNormal];
 
	return (self = [self initWithCustomView:button]);
}
 
@end

In the “Shared” folder you will also find images for the UINavigationController back button (named UITintedBackButtonXXX.png), but be advised that bar button items with a custom view won’t work on UINavigationItem’s backBarButtonItem property. You’ll have to put your custom back button on leftBarButtonItem instead.

Tip: If you also want to have Retina-sized images, run Artwork Extractor on a Retina device or on the Simulator in Retina mode. It’s very enlightening to look through the rest of the extracted artwork as well.

Together with the other members of the RayWenderlich.com Tutorial Team I’ve been hard at work these past weeks putting together an ebook that goes in-depth on many of the new technologies in iOS 5.

I contributed four chapters on Automatic Reference Counting (ARC) and Storyboards, and the book is packed with other cool stuff as well.

Some of the topics covered: iCloud, OpenGL ES 2.0 with GLKit, Newsstand, UIKit customization, using the new integrated Twitter, Turn Based Gaming with Game Center, Core Image, and much more!

Because we had to rush a bit to get it out in time, the book is currently available as a beta version. It’s already 600 pages and there are many more goodies coming. If you get the book now, you’ll receive the new chapters as they become available.

I’m really excited about this ebook. It’s a goldmine of information and I can’t wait to read it myself! Check it out at www.raywenderlich.com.

The iOS Apprentice is available too!

Speaking of ebooks, I’m happy to announce that as of today the next two parts of my beginner course The iOS Apprentice are available as well.

This course is a series of epic-length tutorials that take you from zero to writing real apps for the iPhone and iPad. It’s aimed at complete beginners and people who have experience with other languages (PHP, Java, C#) but who are new to the platform.

If you’re confused about what a delegate or a view controller is, or if the strange syntax of Objective-C scares you, then you need to get this ebook!

You can read the first part for free when you sign up for Ray’s Monthly Newsletter at www.raywenderlich.com, so check it out and let me know what you think. If you liked the first part, you’re going to love the rest of The iOS Apprentice.

Is instantaneous, it doesn’t make me wait.

Remembers things for me.

Draws intelligent conclusions based on my past behavior and correctly predicts what I want to do next.

Allows me to make mistakes and experiment.

Is predictable, it should not confuse me by doing something I did not expect.

Is dependable, it does not lose or corrupt my data.

Is polite, it doesn’t interrupt me.

Gets out of my way.

Puts my needs first, not those of the computer or the developer (or publisher/brand/investor/sponsor).

Is an extension of me, not another burden to carry.

Makes my life easier, not more frustrating.

Is smart, it does not require me to hold its hand all the time.

Should shape itself to my perception of reality.

(We have a long way to go still!)

I get a fair amount of email from beginning programmers and they usually ask the same questions. They’ve read a book or tutorial about the basics but now they’re stuck. It’s easy enough to create a simple screen with a few buttons, to show a list of items in a table view, to use the photo picker, to download something from the internet… but how do you fit all of that together? These are also the questions I keep seeing on forums and message boards. So I decided to write an ebook with the answers.

This ebook contains five epic-length tutorials, each of which takes you from scratch to a complete, fully-functional iPhone or iPad app, with step-by-step instructions and a ton of illustrations. There’s a big difference between building a simple sample project that focuses just on a single topic, and creating a real app that has many different features — the kind of app that you actually see in the App Store. The iOS Apprentice shows you how to do the latter.

This is what Bull’s Eye looks like, the game from the first chapter:

You can see this game in action for yourself because as of today the first chapter of the ebook is available for free!

If you’re thinking of getting started with iOS development but you have no idea where to start, then get this ebook! No knowledge of programming is assumed, so if you’ve never written a line of code before in your life, you’re in good hands.

It is my aim that by the end of these 5 tutorials you’ll be ready to turn your own ideas into real apps. This isn’t some 20-page fluff ebook, but over 500 pages and more than 500 illustrations of hands-on practical advice.

I’m currently writing the final chapters. I expect the ebook to be done by the time iOS 5.0 comes out (early fall). Of course, the tutorials make good use of the new features from iOS 5 such as Automatic Reference Counting and Storyboards.

If this sounds like something you’d be interested in, then here’s how you can get the entire first chapter for free right now:

Go to www.raywenderlich.com and sign up for Ray’s Monthly Newsletter. Ray has an excellent site with many free iOS development tutorials, and he has agreed to sell The iOS Apprentice from his website, which makes me very happy.

After signing up for his newsletter — which is a very useful resource in its own right! — you’ll receive the download link for the first chapter (23 MB).

Enjoy the free chapter and let me know how you’re getting on! In the mean time, I have a few more pages to write…

Splash screens make your app appear to start up slower. When the user launches an app, he expects to be able to interact with it immediately. If you show a splash screen first, he has to make a context switch from what he expected to see (the actual app) to your logo and back again when the app is done loading and its real interface finally appears.

Instead, if you do what Apple recommends in the HIG—show an empty version of your UI, without any content—then the perceived app startup time is actually shorter and users are happier as a result. Anything you can do to make your users happier is something you should do.

All iPhone and iPad apps contain a launch image, Default.png, that is shown when the app is being loaded by the operating system. Unfortunately the temptation is big to put a logo in this image. Don’t, as that is not what it’s there for.

Here is the launch image of an app I recently completed for a client. Boring, but effective.

Splash screens are about you, not about the user. You probably like your logo very much and I’m sure it is pretty, but here is something you need to realize: the user doesn’t particularly care about you or your logo. You, on the other hand, should care very much about the user.

Most people just want to get on with things and if your app helps them do so, great! But if the app gets in their way, it only takes three taps to uninstall.

If your app is a novelty app designed to promote your brand, then remember that unless the app delivers some kind of value, people won’t be using it for very long and they won’t get much exposure to your message. Focus on the value, not on the brand.

Forego the splash screen and find a better way to integrate your branding in the app’s user interface. Give people a good experience to associate with your brand, rather than shoving it into their faces.

The launch image is rarely shown anymore. Now that almost everyone has OS 4 with multitasking on their iPhone, apps resume where they left off the next time they are opened. This means the load image, i.e. your splash screen, is only shown for a brief instant the very first time the app is used.

The launch image also appears if your app is re-launched after it was truly terminated, which occasionally happens when there is not enough free memory to keep all suspended apps around. Most of the time, however, when the app loads the user sees a snapshot of where he last left off.

Showing your splash screen only now and then makes for a very inconsistent experience. Putting a logo in the launch image might have worked on the slower models when there was no multitasking yet, but no more.

Don’t get too clever! If your app launches really quickly—and it should!—then the load image is only visible for a second or so, especially on the fast iPhone 4. Hardly long enough to make an impression.

To “solve” this problem, some apps use a timer that keeps the splash screen visible for a few seconds more before it fades into the main interface. How silly is that? You are not doing the user any favors by purposely slowing down the launching of the app.

Let me say it again: the app is not about you, your brand or your logo, it is about the user and the goal he wants to accomplish.

If your app is a game, then it makes sense to show a “Loading…” screen but for any other apps, do the right thing and put a blank version of your UI in the default load image.

• not getting the app you want,
• paying more than you budgeted,
• not getting your deliverables on time.

There is a reason why software takes a long time to develop, is expensive to make, and often isn’t very good: programming computers is hard!

It’s easy enough to learn the basics of programming. There are only a handful of building blocks and by themselves they are easy to understand. However, knowing how to combine them into a larger application is the real trick and that takes many years to master.

If you’ve never programmed before, or never went beyond the trivial programs you had to write in school, the difficulty of the task may be hard to appreciate. In this article, I’ll try to give some insight into why writing software takes so much effort and why it fails so often, and some tips on how to avoid disappointment.

Software is complex

I see a lot of job postings where clients say: “I’m looking to have a simple app developed”. Great, I have nothing against simple apps but you should realize there is no such thing as a simple program.

The app itself may only have a few screens and be a breeze to use, but the underlying program code definitely won’t be simple. A program consists of many small parts that all have to work together in an intricate fashion. As they grow in number it becomes very difficult to keep track of all these parts and to see how they all fit together.

The human brain simply cannot handle this level of complexity. It is impossible to hold the entirety of a program in your head at once. In fact, it is common to make a change to one part of the program and — without realizing it — break something else in another part.

Good software developers use tools and techniques that help them structure their programs in ways that minimize these issues. This is where hiring an experienced developer pays off. But even for a veteran, complexity remains a significant obstacle.

Software is brittle

Computers do exactly what you tell them to, no more, no less. This means the developer needs to be very specific in the commands he gives the computer, or he’ll get different results than he was expecting (i.e. bugs). Programming is a very delicate and time-consuming art.

All the parts in a program are tightly connected. As I said, a change to one part has consequences for the other parts. A program is like a house of cards; take out the wrong card and the house collapses.

Because everything fits together exactly, a change to one piece means that other pieces may have to be modified too. Of course, those additional changes have an impact of their own.

A change that may appear small – “just move this button to the next screen” – can create ripples that have a huge impact on the underlying code. Large chunks of the code may need to be rewritten to accommodate your changes.

You as the client don’t see this but it is work that needs to happen and you will be paying for it, in time and in money (or bugs).

All change has a cost

The cost of making changes increases over time. Early on in the project, the codebase is still small and changes do not yet have much impact, so they are relatively cheap. If you’re unsure about certain features of your app, this is the best time for experimentation.

However, as time goes on, the codebase grows and grows and with it complexity increases. The code becomes more and more tightly interwoven. A big change in functionality will require large portions of the code to be rewritten.

At this point, even a small change can have adverse effects. The programmer may decide that properly restructuring the code to facilitate this small change it is not worth his time (a deadline may be looming) or the money you’re paying him, so instead he will devise a clever workaround.

Unfortunately, clever workarounds will only make the code more complex and harder to understand. If enough of these workarounds accumulate, the code will become unmaintainable and you will be forced to start all over with a complete rewrite.

So what can you do?

Educate yourself

The more you can do ahead of time, before development starts, the better. Get an iPhone or iPad and play with the popular apps. Read the HIG. Devour Tapworthy. Get the Happy Tapper e-book.

You don’t need to become a developer or UI designer yourself, but at least get some idea of what goes into building an app. This will make it easier for you to talk to and understand your developer.

Decide exactly what app you want before you hire a developer. The better you know what you want, and can explain what you want, the less room there is for misinterpretations and the less need there is for changes while programming is underway.

Write down your wishes. Be specific and complete. A good developer will work with you to round out this specification, but the more you can do by yourself in advance, the more money (and frustration!) you save.

Iterate, iterate, iterate

Even though I just said that you should make your mind up on exactly what you want before programming begins, in practice you will find that things that look good on paper do not always work so well when you actually try them on the phone.

It’s simply impossible to do everything right from the start. Revisions are inevitable. The trick is to prepare for this fact and to be flexible enough to handle these changes.

There is nothing more aggravating for a developer than spending several months on an app only to have the client say: “Yeah, that’s not really how we wanted it,” even though the developer built exactly what was agreed upon.

Avoid this by working in short iterations. Split up the project into milestones that each last no more than a few weeks. After each milestone is complete, re-evaluate the project — are you still getting what you want? – and change course if necessary.

Be available for feedback

In the course of writing the program, the programmer needs make a lot of decisions. Most of the time these concern implementation details that you could care less about, but things always come up that will impact the way the app functions. In other words, they expose design issues.

You need to be prepared to come up with solutions to these problems or the programmer will have to make those decisions for you and you may end up with something you did not want. Reversing such a decision is costly for you and frustrating for the developer.

Having an app developed requires constant interaction between the both of you. You can’t simply hand off a stack of specs and expect the developer to re-emerge a month later from his cave with a finished app in his hand. That’s not how it works!

You will need to put in as least as much effort as the developer. This does not mean you need to micro-manage, but you should be available to deal with design issues. It’s your app, after all.

There is more to it than programming

Of course, the programming is only one part of the app development process. Designing the user interaction experience is at least as important and just as difficult. Designing an attractive visual experience is not small feat either.

Some developers can also handle these design tasks but just because someone is a good programmer, doesn’t mean they are also good interaction designers or graphics artists. Chances are you need to hire an UI designer and a graphics artist in addition to a developer, but that’s a topic for another article.

I hope this article gave you some insight into the difficulties of software development. It’s hard because it’s complex and us humans are operating at the limits of our capacity for dealing with this kind of complexity.

Be prepared and increase your chances of success!

My first tutorial is now up on his site: Apple Push Notification Services Tutorial: Part 1/2. Because it’s very long we split it up into two parts.

Part 1 introduces the Apple Push Notification Service (APNS), explains how to make the required SSL certificate and provisioning profile, and shows how to send push notifications to a very simple app.

Part 2, which should be published next week, takes it a step further and creates a chat app that uses push notifications to deliver the messages.

I hope you like the tutorial! If you have any questions about push or the tutorial, then let me know in Ray’s forums.

Version 7: Refinements

In this chapter we’ll make some refinements to the code and implement missing features.

First, I will show you a little trick. Did you know you can create objects of any kind using Interface Builder, not just views? We can use that to our advantage and save on some code in the application delegate. In the last chapter we added several new properties in order to be able to hook up the DataModel object to both our view controllers. Well, we can do all of that inside Interface Builder without having to write any code!

Let’s strip out the soon-to-be-unnecessary stuff from SmoothieAppDelegate.h:

//@class DataModel;
//@class SmoothiesViewController;
//@class FavoritesViewController;
 
@interface SmoothiesAppDelegate : NSObject 
{
}
 
@property (nonatomic, retain) IBOutlet UIWindow* window;
@property (nonatomic, retain) IBOutlet UITabBarController* tabBarController;
//@property (nonatomic, retain) IBOutlet SmoothiesViewController* smoothiesViewController;
//@property (nonatomic, retain) IBOutlet FavoritesViewController* favoritesViewController;
 
//@property (nonatomic, retain) DataModel* dataModel;
 
@end

That’s right, we’re changing it back to what it was before. Likewise for SmoothieAppDelegate.m.

Now open up MainWindow.xib and drag an Object from the library into the Objects list. We are putting it at the top level; it is not a subview of our Tab Bar Controller. Then we change its class name to DataModel. That’s it, a new DataModel instance will now be created when the main window’s nib is loaded.

We connect this DataModel object to the outlets of both SmoothiesViewController and FavoritesViewController. This will only work if we declare those properties as IBOutlets, otherwise Interface Builder will not recognize them.

// in SmoothiesViewController.h and FavoritesViewController.h:
@property (nonatomic, assign) IBOutlet DataModel* dataModel;

The nib looks like this:

Figure 7.1. The DataModel object is now part of the nib.

You may be wondering which object now owns the DataModel instance. After all, both SmoothiesViewController and FavoritesViewController have an “assign” property, not “retain”, and we don’t retain the object anywhere else.

We’re relying on the fact that when a nib is loaded, all its objects are automatically instantiated and retained. Because the main window will be around as long as the app is running, so will the objects from this nib. So in effect, the File’s Owner of the MainWindow.nib, UIApplication, is now the owner of DataModel.

Interface Builder is essentially just a tool that allows you to create and configure objects and then freeze them. When the nib is loaded into the app, the objects are “unfrozen” and become alive again. It saves a bunch of typing, so I like to use it for this purpose as much as possible, even with objects that aren’t really part of the user interface.

Improving the Favorites screen

There are a fewer other things in our app that bug me. The Favorites screen always reloads the contents of its table when its view is about to appear. I’d like to get rid of this code:

- (void)viewWillAppear:(BOOL)animated
{
	[super viewWillAppear:animated];
	[self.tableView reloadData];
}

It works, but it’s not very subtle. Instead, I’d like to reload the table only when something has actually changed. Currently that is when the user marks or unmarks a recipe as a favorite from the Recipe Details screen.

So we have to find some way to make the Recipe Details screen communicate with the FavoritesViewController. There are several ways to do this. We could give the RecipeDetailsViewController a reference to the FavoritesViewController, but that introduces a tight coupling between two classes that aren’t really related to each other. So let’s find a better way.

We could make a delegate like this:

@protocol RecipeDetailsDelegate 
- (void)addedToFavorites:(Recipe*)recipe;
- (void)removedFromFavorites:(Recipe*)recipe;
@end

FavoritesViewController could implement this delegate. Now RecipeDetailsViewController invokes the addedToFavorites or removedFromFavorites methods on that delegate whenever the user taps the “Favorite” button for a recipe.

This is a better approach because the Recipe Details screen no longer directly needs to know about the FavoritesViewController, just that it has “some” delegate, but the FavoritesViewController still needs to know about the Recipe Details screen because it implements its delegate protocol. So this is not an ideal solution either.

Maybe you’re thinking we could make a DataModelDelegate instead. Because the data model is ultimately responsible for adding and removing the favorites, it could notify a delegate about about these changes. Possible, but what if we have more than one screen that needs to be notified when a recipe is added to the favorites? DataModel would then need to keep a list of delegate objects and notify them all.

There is a way to completely decouple the sending of notifications when something changes and listening for such notifications, and that is to use NSNotificationCenter.

Add the following to DataModel.h:

extern NSString* const FavoritesChangedNotification;

This lets any users of the DataModel class know there is now a global string constant named FavoritesChangedNotification. They don’t care what the actual value of the string is, just that they can subscribe to a notification with this identifier.

In DataModel.m, we add the actual definition:

NSString* const FavoritesChangedNotification = @"Smoothies-FavoritesChanged";

We will send this notification whenever a recipe is added or removed:

// in DataModel.m:
- (void)addToFavorites:(Recipe*)recipe
{
	[self.favorites addObject:recipe.name];
	[[NSUserDefaults standardUserDefaults] setObject:self.favorites forKey:@"Favorites"];
	[[NSUserDefaults standardUserDefaults] synchronize];
 
	// Let any listeners know the list of favorites has changed
	[[NSNotificationCenter defaultCenter] postNotificationName:FavoritesChangedNotification object:self];
}
 
- (void)removeFromFavorites:(Recipe*)recipe
{
	[self.favorites removeObject:recipe.name];
	[[NSUserDefaults standardUserDefaults] setObject:self.favorites forKey:@"Favorites"];
	[[NSUserDefaults standardUserDefaults] synchronize];
 
	// Let any listeners know the list of favorites has changed
	[[NSNotificationCenter defaultCenter] postNotificationName:FavoritesChangedNotification object:self];
}

Because this is only a simple app, this notification doesn’t provide much more information than “the list of favorites has changed”. We don’t say how it has changed, i.e. what was added or removed. This simple notification is sufficient for our purposes, but for a more complex app you may want to send more detailed information along with your notifications. There is a version of postNotification that allows you to add an NSDictionary with any additional data you want.

Now, whenever the user taps the Favorite button in the Recipe Details screen, the DataModel sends out a notification. It doesn’t care who receives that notification. It just broadcasts a message that says: “Something happened to my list of favorites. Do with it what you want. Or not. It’s up to you.”

Of course, this won’t do us much good if we’re not listening for this message, so add the following to FavoritesViewController.m:

- (void)viewDidLoad
{
	...
 
	// Start listening for notifications
	[[NSNotificationCenter defaultCenter] addObserver:self
		selector:@selector(favoritesChanged:)
		name:FavoritesChangedNotification
		object:nil];
}
 
- (void)viewDidUnload
{
	[super viewDidUnload];
 
	// Stop listening for notifications
	[[NSNotificationCenter defaultCenter] removeObserver:self
		name:FavoritesChangedNotification
		object:nil];
}
 
- (void)dealloc
{
	// Stop listening for notifications
	[[NSNotificationCenter defaultCenter] removeObserver:self
		name:FavoritesChangedNotification
		object:nil];
 
	[super dealloc];
}

As soon as our view is loaded, we tell the NSNotificationCenter that we are interested in the FavoriteChangedNotification message and that it should call our favoritesChanged: method whenever such a notification is received.

Because we are good citizens, we also tell the NSNotificationCenter when we no longer wish to receive those notifications. Otherwise it might send a notification to a deallocated object and that will crash the app. (Although in our app the FavoritesViewController is never actually deallocated; it sticks around for as long as the app runs.)

That leaves us to implement the favoritesChanged method. It is really simple:

// in FavoritesViewController.m:
- (void)favoritesChanged:(NSNotification*)notification
{
	[self.tableView reloadData];
}

When you run the app and mark a recipe as favorite, then the Favorites list should immediately update to reflect this change.

A bug!

The changes we’ve made so far have actually introduced a bug into our app. What happens when you delete a smoothie that is also a favorite? Previously, the Favorites screen would always reload its contents when you switched to it, so any deleted smoothies would simply no longer show up. Now, however, we only refresh the Favorites screen when a recipe is “favorited” or “unfavorited”, but not when it is removed.

The solution is to also remove the recipe from the list of favorites, which will send a FavoritesChangedNotification and neatly solve the problem for us.

// in DataModel.m
- (void)removeRecipeAtIndex:(int)index
{
	// Also remove the recipe from the list of favorites
	Recipe* recipe = [self recipeAtIndex:index];
	[self removeFromFavorites:recipe];
 
	[self.recipes removeObjectAtIndex:index];
}

Sorting the favorites

There is one more tweak I would like to make. So far the favorites screen has listed the smoothies in the order that you clicked on their “Favorite” button. For some apps that might make sense, but for our app it’s nicer if we sort them alphabetically.

Since we store the names of the recipes in the favorites array, we can simply sort this array before we store it in NSUserDefaults. Change DataModel‘s addToFavorites to:

// in DataModel.m:
- (void)addToFavorites:(Recipe*)recipe
{
	[self.favorites addObject:recipe.name];
 
	// Sort the list by recipe name
	[self.favorites sortUsingSelector:@selector(localizedCaseInsensitiveCompare:)];
 
	[[NSUserDefaults standardUserDefaults] setObject:self.favorites forKey:@"Favorites"];
	[[NSUserDefaults standardUserDefaults] synchronize];
 
	// Let any listeners know the list of favorites has changed
	[[NSNotificationCenter defaultCenter] postNotificationName:FavoritesChangedNotification object:self];
}

Every time a recipe is added, we sort the list with sortUsingSelector. This takes a selector as its argument, which is a method on the NSString class because our list of favorites contains string objects. That’s all we have to do to sort the list.

We’ve seen how you can use notifications to communicate between controllers. Notifications are great for when you want to keep the different parts of your code completely isolated from each other (a good practice to strive for). Sometimes, however, a tighter coupling using delegates is unavoidable and we’ll see how that works in the next chapter.

Download the source code for version 7

Version 8: Adding and editing recipes

This chapter introduces the last piece of functionality that I want to add to this app: the ability to add new recipes and edit existing ones. We will use a single view controller for both tasks, EditRecipeViewController. Adding a new recipe and editing an existing recipe are so similar that we only have to write the code once.

Let’s build the screen in Interface Builder:

Figure 8.1. The EditRecipeViewController.xib design.

This screen has a navigation bar with two buttons: Cancel and Save. These buttons are hooked up to actions that will dismiss the screen. More about these later.

I only added a text field for the name and a button that lets you choose a photo, but no entry box for the instructions. The reason for this is that I wanted to keep this tutorial focused on how this new view controller interacts with the rest of our classes, not turn it into a tutorial on how to actually build these screens.

The problem is that we would place the text view for the instructions at the bottom of the screen. When you tap into this text view, the keyboard slides on top of it and then you can no longer see what you’re typing. There are several ways to solve this issue, but that’s the topic for another tutorial. So for now I’ve kept it simple and simply left out this text view.

In Interface Builder, the title of the navigation bar is “Add Recipe”. When we’re editing an existing recipe, we’ll change that to “Edit Recipe”, but we do that in code. That is one of the very few differences between adding new recipes and editing existing ones, and it’s not worth building a totally new class for. From now on, I’ll simply refer to this screen as the Edit Recipe screen, whether we’re adding a new recipe or editing an existing one.

To allow the user to add new recipes, I have added a “+” button to the navigation bar of the Smoothies screen, and hooked it up to the addRecipe action:

// in SmoothiesViewController.m:
- (IBAction)addRecipe
{
	EditRecipeViewController* controller = [[EditRecipeViewController alloc] init];
	[self presentModalViewController:controller animated:YES];
	[controller release];
}

Here we create the controller and then present it modally so it will cover the whole screen. As long as the user is interacting with this screen, the rest of the app is inaccessible. The user must press Cancel or Save to close this modal screen and return to the app.

We do something similar in the RecipeDetailsViewController. Its navigation bar now has an Edit button that is hooked up to an IBAction that opens the Edit Recipe screen. (Open RecipeDetailsViewController.xib to see how I added this Edit button.)

I won’t explain everything that EditRecipeViewController does. Suffice it to say that it opens a UIImagePickerController that lets you choose a photo from the phone’s photo library, and that it presents a keyboard that lets you type a name for the recipe.

Our own delegate

The interesting question is, how can we get the new recipe into our list of smoothies? The answer: using a delegate. The Edit Recipe screen works totally by itself. It is not dependent on any other part of our program, and that is done on purpose.

As I have explained several times before in this tutorial, it is good design to structure each of your classes so they can work in isolation. This keeps the implementation details of that class limited to itself, which avoids your code from becoming a tangled up mess.

No one else should care about how Edit Recipe does its job. We give it some data to work on, and we either get notified through the delegate that the user made changes and tapped Save, or tapped Cancel.

The delegate protocol for EditRecipeViewController looks like this:

// in EditRecipeViewController.h:
@protocol EditRecipeDelegate 
- (void)editRecipeDidSave:(EditRecipeViewController*)controller;
@optional
- (void)editRecipeDidCancel:(EditRecipeViewController*)controller;
@end

When the user taps Save, we call the delegate’s editRecipeDidSave: method. When the user taps Cancel, we call the delegate’s editRecipeDidCancel: method. This last method is optional, which means the delegate does not have to implement it. This is all EditRecipeViewController knows about the outside world; there is some object that is its delegate, and it will call that delegate to inform it about changes.

When we’re adding a new recipe, the delegate is SmoothiesViewController, because that is the screen that we launch the Edit Recipe screen from. The addRecipe action now looks like this:

// in SmoothiesViewController.m:
- (IBAction)addRecipe
{
	EditRecipeViewController* controller = [[EditRecipeViewController alloc] init];
	controller.delegate = self;
	[self presentModalViewController:controller animated:YES];
	[controller release];
}

The line controller.delegate = self; is new. It lets the EditRecipeViewController know that we’re now going to want to receive the “didSave” and (optionally) “didCancel” messages.

When we’re editing an existing recipe, the delegate will be the RecipeDetailsViewController. So here we have two completely different controllers, but because they both adhere to the EditRecipeDelegate protocol the Edit Recipe screen can talk to them both, without having to know anything else about them.

Data in and out

The other part of the puzzle is getting data into and out of EditRecipeViewController. To achieve this, I have added two properties to this class:

// in EditRecipeViewController.h:
@property (nonatomic, copy) NSString* name;
@property (nonatomic, copy) NSString* instructions;
@property (nonatomic, retain) UIImage* image;

These correspond to the attributes of the Recipe we’re editing. If we are adding a new recipe, then these are left to their default nil values. But when editing an existing recipe, we copy the Recipe‘s name, instructions and image into these properties, like so:

// in RecipeDetailsViewController.m:
- (IBAction)editRecipe
{
	EditRecipeViewController* controller = [[EditRecipeViewController alloc] init];
	controller.delegate = self;
	controller.name = self.recipe.name;
	controller.instructions = self.recipe.instructions;
	controller.image = self.recipe.image;
	[self presentModalViewController:controller animated:YES];
	[controller release];
}

When you press Save on the Edit Recipe screen, the editRecipeDidSave: method is called on the delegate. The delegate can now look at controller.name, controller.instructions and controller.image to get the new values of the recipe.

That’s exactly what we do in both SmoothiesViewController and RecipeDetailsViewController, although in the former we add a completely new Recipe object to the DataModel while in the latter we just change the properties of the existing object.

// in SmoothiesViewController.m:
- (void)editRecipeDidSave:(EditRecipeViewController*)controller
{
	// Create a new Recipe object with the values from the controller
	// and add it to the data model
	Recipe* recipe = [[Recipe alloc] init];
	recipe.name = controller.name;
	recipe.instructions = controller.instructions;
	recipe.image = controller.image;
	[self.dataModel addRecipe:recipe];
	[recipe release];
 
	// Refresh the table
	[self.tableView reloadData];
}
 
// in RecipeDetailsViewController.m:
- (void)editRecipeDidSave:(EditRecipeViewController*)controller
{
	self.recipe.name = controller.name;
	self.recipe.instructions = controller.instructions;
	self.recipe.image = controller.image;
	[self updateControls];
}

The call to [self updateControls] will update the label and button with the new name and image of the recipe. And that’s the way we do it.

Now, why don’t I simply pass a Recipe object to EditRecipeViewController? That is after all what we do with RecipeDetailsViewController

Think about this: If you pass in a Recipe object and the user changes the name, then the name of the Recipe is immediately updated. But what if the user cancels? Then we have to find some way to put back the original name in the Recipe object, so either we have to keep a copy of the original values around or do our modifications in a copy of the actual Recipe object. Too much hassle for my taste.

Propagating the changes

One more thing to cover: if you rename a recipe, then any screen that displays that recipe also has to be updated. So far we’ve only updated the controls in the Recipe Details screen, but we also need to update the Smoothies screen and maybe also the Favorites screen. Despair not, we’ve faced a similar situation before and dealt with it using a notification.

This, however, highlights another problem. Because we store favorites by name, changing the name of a recipe messes up our favorites because one of them now refers to a recipe that no longer exists. Yikes. It gets worse, what will happen when the user gives two smoothies the same name?

It is probably a good idea to reconsider using the recipe names as their unique identifier, now that the names can be changed by the user. Fortunately, because we have hidden how favorites are implemented inside of DataModel, we only have to change the DataModel class. None of our other classes is impacted by this change.

You can see in the code what I changed, but to summarize I added a recipeId property to the Recipe class. This is an integer. We now store those integers instead of the recipe names in the NSUserDefaults. (I changed the key under which they are stored to @”Favorites2” so the app won’t crash if you’re installing it on top of one of the previous versions.) The only tricky thing is assigning an ID to new recipes, but that’s something we can neatly tuck away inside DataModel.

Finally, we tell DataModel that the recipe was updated. It will send out the new RecipesChangedNotification. Both the SmoothiesViewController and FavoritesViewController listen for this notification and reload their tables in response.

// in RecipeDetailsViewController.m:
- (void)editRecipeDidSave:(EditRecipeViewController*)controller
{
	self.recipe.name = controller.name;
	self.recipe.instructions = controller.instructions;
	self.recipe.image = controller.image;
	[self updateControls];
	[self.dataModel didChangeRecipe:self.recipe];
}

A new way to sort

Because we no longer store favorites by name, we cannot sort the favorites list by name any more either. Let’s change the way DataModel exposes the favorites list to the outside:

// in DataModel.h:
@property (nonatomic, readonly, retain) NSArray* sortedFavorites;
 
//- (Recipe*)favoriteAtIndex:(int)index;

We added a property and got rid of the favoriteAtIndex: method. Any class that wishes to use the list of favorites can now only get an immutable array using the sortedFavorites property that is guaranteed to be sorted by name.

Inside DataModel.m it works like this:

- (NSArray*)sortedFavorites
{
	if (sortedFavorites == nil)  // lazy loading
	{
		// Add the Recipe objects to a new list
		self.sortedFavorites = [NSMutableArray arrayWithCapacity:favorites.count];
		for (NSNumber* number in self.favorites)
		{
			int recipeId = [number intValue];
			Recipe* recipe = [self findRecipeWithId:recipeId];
			if (recipe != nil)
			{
				[sortedFavorites addObject:recipe];
			}
		}
 
		// Sort the list by last name
		[sortedFavorites sortUsingSelector:@selector(compareName:)];
	}
	return sortedFavorites;
}

We use a technique called “lazy loading” to make this as efficient as possible. The very first time this method is called, we make a new NSMutableArray array object and fill it up with the Recipe objects whose ID’s are in the favorites list. Then we sort that array (the selector compareName: is a method that I added to Recipe). From then on, we always return a reference to that array.

The trick is that we set sortedFavorites to nil whenever we change the recipes list or the favorites list. The next time this method is called, the sorted array will be generated anew. There are other ways to accomplish the same thing (directly changing sortedFavorites when we add or remove a favorite may be faster), but I wanted to illustrate how to use lazy loading in this context.

I’ll leave re-sorting the list in the main Smoothies screen as an exercise for the reader.

As you can tell, our code has become complex rather quickly. We now have several different screens that all influence each other. By keeping them as self-contained as possible, we can keep our code manageable. But we cannot escape the use of some kind of notification mechanism to update everyone when things change.

Our final class structure looks like this:

Figure 8.2. We added the EditRecipeViewController.

That’s it for this tutorial. I might do another chapter later that illustrates how to use Core Data as your data model instead of rolling your own like we did.

Download the source code for version 8

Version 4: Deleting smoothies

Often in a screen that has a table view, you are able to delete items by swiping a row or by tapping an Edit button in the navigation bar. Let’s add “swipe to delete” to our list of smoothies. (In a later chapter we’ll also add a way to create new smoothies.)

Swipe-to-delete is activated by a UITableViewDataSource method:

- (void)tableView:(UITableView*)theTableView
	commitEditingStyle:(UITableViewCellEditingStyle)editingStyle
	forRowAtIndexPath:(NSIndexPath*)indexPath
{
}

If you just add this method to SmoothiesViewController.m, even though it doesn’t do anything yet, then swiping the row in the table will make the red Delete button appear.

Figure 4.1. Swipe-to-delete in action.

The commitEditingStyle method is called when the user actually presses the Delete button. Two things need to happen then: 1) we must remove the Recipe in question from our data model; 2) we must tell the table view to remove the row.

This is how we do that:

// in SmoothiesViewController.m:
- (void)tableView:(UITableView*)theTableView
	commitEditingStyle:(UITableViewCellEditingStyle)editingStyle
	forRowAtIndexPath:(NSIndexPath*)indexPath
{
	// Remove the Recipe from our data model (the list of recipes)
	[self.recipes removeObjectAtIndex:indexPath.row];
 
	// Remove the row from the table with an animation
	[theTableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade];
}

Very simple and it looks pretty good too. Note that the recipes aren’t gone forever. The next time you start the app, they are back again. That is because we always create a new list of recipes when the SmoothiesViewController is loaded.

The DataModel class

I want to make a fundamental change now to the app. So far when we’ve talked about the data model, it concerned two items: the Recipe class, which describes a single recipe, and the NSMutableArray that contains a list of those Recipe objects.

In SmoothiesViewController, we often use self.recipes directly: when the controller is loaded, we add several Recipe objects into this list; the table view data source loads the cells from this list; and now the swipe-to-delete method removes items directly from this list.

So far it has been manageable, but now I want to abstract away these operations and hide the list. To that end, we’ll make a new class named DataModel. This is our top-level data model class. For the time being it will just have the list of recipes, but in later chapters we’ll give it more responsibilities.

What should the DataModel class do?

• It owns the list of recipes.
• It is able to tell how many recipes are in the list. We need this for the table view data source so it knows how many rows there are in the table.
• It can return a Recipe object at a specific position in the list. Also needed for the table view.
• It can delete a Recipe from the list.

I used Xcode’s New File wizard to create an Objective-C class that is a subclass of NSObject and named it DataModel. In DataModel.h, I added methods for the tasks we outlined above:

@class Recipe;
 
@interface DataModel : NSObject
{
}
 
// Returns how many recipes are in the list.
- (int)recipeCount;
 
// Returns the Recipe object at the specified position in the list.
- (Recipe*)recipeAtIndex:(int)index;
 
// Deletes a Recipe object from the list.
- (void)removeRecipeAtIndex:(int)index;
 
@end

We already have the code for these methods because SmoothiesViewController already does these things. So I was able to cut-and-paste a bunch of code from SmoothiesViewController to DataModel.m.

At this point, DataModel does no more than what NSMutableArray does. The advantage is that it hides from SmoothiesViewController (and anyone else) the fact that it uses an NSMutableArray underneath. In fact, it does a lot less than NSMutableArray and that’s exactly what we want. You can’t modify the list of recipes unless DataModel has a method for it. This encapsulation and abstraction makes our code more robust. We already talked a bit about this in the previous chapter.

That DataModel uses an NSMutableArray is a so-called “implementation detail”. It’s important to the implementation of DataModel, but not to anyone who uses DataModel. It’s a good strategy to hide implementation details from the rest of your code. Always ask yourself: is this something I can hide in my class because no one needs to know about it?

Private properties

Note that DataModel‘s @interface does not have an NSMutableArray property or even instance variable. Then where do we keep the list of recipes? I used a trick called a “class extension” for this.

Maybe you’re familiar with the concept of Objective-C’s categories. A category lets you add new methods to an existing class, which can be very convenient. A class extension is like that, although you use it in your .m file only and it allows you to add properties. Because this property is not in your .h file, it’s private.

Since we don’t want anyone to know that we use an NSMutableArray to store the list of recipes – or depend on this – we declare it as such a private property at the top of DataModel.m:

// Yes, this goes into DataModel.m:
@interface DataModel ()
 
// The list of Recipe objects
@property (nonatomic, retain) NSMutableArray* recipes;
 
@end

Simplifying SmoothiesViewController

If you compare SmoothiesViewController to the previous versions, it’s now a lot simpler. We moved a lot of the logic into DataModel. Instead of a list of recipes, it now just has a dataModel property.

Where previously we did:

- (NSInteger)tableView:(UITableView*)theTableView numberOfRowsInSection:(NSInteger)section
{
	// Return the number of recipes in our list
	return self.recipes.count;
}

We now do:

- (NSInteger)tableView:(UITableView*)theTableView numberOfRowsInSection:(NSInteger)section
{
	// Return the number of recipes in our list
	return [self.dataModel recipeCount];
}

Likewise, swipe-to-delete now becomes:

- (void)tableView:(UITableView*)theTableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath*)indexPath
{
	// Remove the Recipe from our data model
	[self.dataModel removeRecipeAtIndex:indexPath.row];
 
	// Remove the row from the table with an animation
	[theTableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade];
}

The reason for making this change is that a view controller’s job isn’t to manage the data, that is really the job for a separate data model object. The view controller also doesn’t draw directly on the screen; that is the job for a view. The actual job of the controller is to let the view and the data model talk to each other. That’s why it is better to separate these jobs into different classes. This keeps everything well-organized.

If this is all our app would do, then using a separate DataModel class instead of managing the list ourselves would be overkill. But we’ll be adding a whole bunch of new features soon that make having this class indispensable.

The class structure now looks like this:

Figure 4.2. The DataModel class has replaced NSMutableArray. It still uses an NSMutableArray internally to store the Recipe objects, but that is of no concern to the rest of the app.

Download the source code for version 4

Version 5: Favorites!

Let’s make the app a little more interesting and add a Favorites screen. Even though the current app only has three smoothies and thus hardly needs a new screen to help you keep track of your favorites, this exercise will illustrate a number of important concepts that you’ll see over and over again in real apps.

When we’re done the app will look like this:

Figure 5.1. We've added a tab bar and a Favorites screen.

I decided to add a tab bar to the app because that makes it easy to switch between the main list of smoothies and the Favorites screen, and because it’s a common design for iPhone apps.

Previously, the top-level controller in our window was the navigation controller that held SmoothiesViewController. Now we have to restructure this a little. I added a tab bar controller to the nib and connected that to the SmoothiesAppDelegate (and thus, the window) instead. The navigation controller is then added to the tab bar controller.

Figure 5.2. The new MainWindow.xib

The second tab has a navigation controller of its own, which in turn contains the FavoritesViewController. Just like the main Smoothies screen, the Favorites screen is also a list of smoothies, so it also extends from UITableViewController.

There is another user interface problem to solve: how do we let users mark a smoothie as a favorite? For this, I added a button on the Recipe Details screen:

Figure 5.3. The Recipe Details screen now has a “Favorite” toggle button.

It will work as a toggle button. Tap it once to mark the recipe as a favorite, tap it again to remove it from the favorites. When the user taps this button, the smoothie will immediately appear in the Favorites screen. If the user changes his mind and taps the button again, the smoothie disappears from the Favorites screen.

Saving the favorites

Where and how do we store which smoothies are favorites? There are several ways we could do this. We want to remember these favorites even after the user quits the app, so we must store it in a file somehow and then load the file back in when the app starts again. We could use an XML file, a Plist file, or even an SQLite database. However, there is also the very handy NSUserDefaults class. This class is often used to store user settings and is very convenient to use. It works like a dictionary.

In RecipeDetailsViewController.m, we add the following method:

- (IBAction)favoriteTapped
{
	NSArray* favorites = [[NSUserDefaults standardUserDefaults] objectForKey:@"Favorites"];
	if ([favorites containsObject:self.recipe.name])
	{
		// un-favorite this recipe
	}
	else
	{
		// add this recipe to the favorites
	}
}

This asks the NSUserDefaults for an object named “Favorites”. That’s just a name I picked. Because NSUserDefaults works as a dictionary, it stores each object under a key and “Favorites” will be the key for our object. The type of our object is NSArray because it makes sense to store the favorites as an array of names.

After we’ve obtained our NSArray from NSUserDefaults, the code looks if the name of the current recipe (self.recipe.name) is already in this list. If yes, then we have to un-favorite this recipe. If the recipe wasn’t in the favorites yet, then we add it.

Hold on a minute… why do we store a list with just the names of the recipes here and not the entire Recipe object? First of all, we can’t store our own classes in NSUserDefaults, only standard objects such as arrays and strings. But more importantly, if we stored an entire Recipe object then we would be saving a copy of the object, not the object itself.

Instead, it is better to store something that lets us refer to a Recipe object from the main data model, because that’s what is being used in the Recipe Details screen. If your data objects have an unique ID, then you could use that. Our recipes don’t have an ID, but their name is going to be unique so that will work just as well.

You might be tempted to store the pointer to the Recipe object instead. After all, that is going to be unique too and it makes it really easy to find the corresponding Recipe object. But consider what happens when the app exits and is started again. We will have completely new Recipe instances, with new pointers. The pointers that you stored in NSUserDefaults will no longer point to the correct Recipes and your app will most likely crash hard.

So the main data model stores a list of Recipe objects, while the favorites are stored as a list of recipe names. We can use these names to find the corresponding Recipe objects.

Defaults for the defaults

There is something else we need to do before we can use the above method. The very first time the app is run, NSUserDefaults does not have anything stored under the key “Favorites” yet. The above code assumes there is always an NSArray there, which is currently not guaranteed. We could solve this problem by checking if the value is nil and then create the array and add it, but there is an easier method.

Add the following to SmoothieAppDelegate.m:

+ (void)initialize
{
	if ([self class] == [SmoothiesAppDelegate class])
	{
		NSDictionary* dict = [NSDictionary dictionaryWithObjectsAndKeys:
			[NSArray array], @"Favorites",
			nil];
 
		[[NSUserDefaults standardUserDefaults] registerDefaults:dict];
	}
}

The initialize method is called when the class is first used. We take advantage of this to set defaults on NSUserDefaults; in this case an empty NSArray for the key “Favorites”. This default value will be used if NSUserDefaults does not contain the key “Favorites” yet. Now we are guaranteed that [objectForKey:@"Favorites"] will return a valid NSArray object.

To add a recipe to the list of favorites, we do:

NSMutableArray* newArray = [NSMutableArray arrayWithArray:favorites];
	[newArray addObject:self.recipe.name];
	[[NSUserDefaults standardUserDefaults] setObject:newArray forKey:@"Favorites"];
[[NSUserDefaults standardUserDefaults] synchronize];

Because the array we received from NSUserDefaults is immutable, we have to create a new array with the contents of the old one and add the recipe’s name to it. Finally, we put the new array in NSUserDefaults.

Just for good measure, we “synchronize” the NSUserDefaults. This causes the new settings to be written to disk immediately. Calling synchronize isn’t strictly necessary because NSUserDefaults will sync itself periodically and when the app exits or goes to the background, but not when you exit the app from within Xcode.

Removing a recipe from the favorites works similarly.

Let’s display the favorites in the Favorites screen, as that’s what it is there for. In the next chapter we’ll look at a better solution but for now we’ll simply read the list of recipe names from NSUserDefaults and show them in the table.

In FavoritesViewController.m:

- (NSInteger)tableView:(UITableView*)theTableView numberOfRowsInSection:(NSInteger)section
{
	NSArray* favorites = [[NSUserDefaults standardUserDefaults] objectForKey:@"Favorites"];
	return favorites.count;
}
 
- (UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath
{
	...
 
	NSArray* favorites = [[NSUserDefaults standardUserDefaults] objectForKey:@"Favorites"];
	NSString* recipeName = [favorites objectAtIndex:indexPath.row];
 
	cell.textLabel.text = recipeName;
	return cell;
}

We’ll refresh the table whenever the Favorites screen becomes visible, so if you click the “Favorite” button in the Recipe Details screen and then switch to the Favorites tab, the list is immediately updated with any changes.

Again in FavoritesViewController.m:

- (void)viewWillAppear:(BOOL)animated
{
	[super viewWillAppear:animated];
	[self.tableView reloadData];
}

There is one more thing to do. In the Recipe Details screen it would be nice to show whether the recipe is currently a favorite. If it is, we add a checkmark in front of the title, like so:

// in RecipeDetailsViewController.m:
- (void)updateFavoriteButton
{
	NSString* title;
	NSArray* favorites = [[NSUserDefaults standardUserDefaults] objectForKey:@"Favorites"];
	if ([favorites containsObject:self.recipe.name])
		title = @"√ Favorite";
	else
		title = @"Favorite";
 
	[self.favoriteButton setTitle:title forState:UIControlStateNormal];
}

This method is called whenever we press the button (in favoriteTapped) but also when the Recipe Details screen is loaded, so we set the button in the proper initial state.

The class diagram has become a little bigger now:

Figure 5.4. We've added a tab bar controller and the Favorites view controller.

To be honest, the implementation of how we store favorites is a little messy. NSUserDefaults really is part of the data model, so in the next chapter we’ll abstract it away in the DataModel class.

Download the source code for version 5

Version 6: Putting the favorites in the data model

You probably wondered why on earth we were storing stuff directly in NSUserDefaults in the previous chapter. That became kind of messy really quickly. Indeed, a better place to do this is… in the DataModel class. That is exactly why we have that class. Favorites certainly count as data objects, so their proper place is in DataModel.

These are the tasks that we need to do with our favorites:

• We need to know how many there are. This is required by the Favorite screen’s table view.
• We need to retrieve the Recipe objects that are marked as favorite. Also for the table view.
• Determine whether a Recipe is currently favorite.
• Add a new Recipe to the favorites.
• Remove a Recipe from the favorites.

Let’s add a method for each of these tasks to DataModel:

- (int)favoritesCount;
- (Recipe*)favoriteAtIndex:(int)index;
- (BOOL)isFavorite:(Recipe*)recipe;
- (void)addToFavorites:(Recipe*)recipe;
- (void)removeFromFavorites:(Recipe*)recipe;

In order for RecipeDetailsViewController to be able to use this, it needs to know about the DataModel class. So we add a property:

// in RecipeDetailsViewController.h:
@property (nonatomic, assign) DataModel* dataModel;

Now when SmoothiesViewController creates the RecipeDetailsViewController in response to a tap on a row in the table, we assign the data model object to it:

// in SmoothiesViewController.m:
- (void)tableView:(UITableView*)tableView didSelectRowAtIndexPath:(NSIndexPath*)indexPath
{
	RecipeDetailsViewController* controller = [[RecipeDetailsViewController alloc] init];
 
	// Assign the data model object to the controller
	controller.dataModel = self.dataModel;
 
	Recipe* recipe = [dataModel recipeAtIndex:indexPath.row];
	controller.recipe = recipe;
 
	[self.navigationController pushViewController:controller animated:YES];
	[controller release];
}

The code for RecipeDetailsViewController is updated to look as follows:

// in RecipeDetailsViewController.m:
- (IBAction)favoriteTapped
{
	if ([self.dataModel isFavorite:self.recipe])
	{
		[self.dataModel removeFromFavorites:self.recipe];
	}
	else
	{
		[self.dataModel addToFavorites:self.recipe];
	}
 
	[self updateFavoriteButton];
}

That is a lot cleaner than what we had before! All the hassle of dealing with NSUserDefaults is now hidden away in DataModel.

Weak and strong references

Note that we declared the dataModel property in RecipeDetailsViewController “assign” instead of “retain”. If you’ve done any iOS programming you should be aware of retain and the memory management rules.

In short: the owner of an object will retain that object and is ultimately responsible for releasing it when it no longer uses that object. When an object is retained, this is called a strong reference. SmoothieViewController has a strong reference to DataModel, because it created that object. SmoothieViewController owns the DataModel for as long as it is alive (which is until this app exits) and will release it in its dealloc.

When we pass the DataModel instance to RecipeDetailsViewController, we make it a so-called weak reference; RecipeDetailsViewController does not own the object and therefore does not retain it. Because RecipeDetailsViewController is guaranteed that the DataModel instance will be around for at least as long as it is (i.e. until the user exits the app), it has no need to retain it.

In general, if you pass along pointers to objects you should make them weak references (using the “assign” property semantics), to signify that the object you are giving it to does not assume ownership. You only use “retain” or “copy” when you are not guaranteed that the object may stick around, in which case you become responsible for releasing it when the time comes.

Where do we put DataModel?

The other place that used NSUserDefaults directly is FavoritesViewController. So let’s change that. But wait a minute… DataModel is currently created and owned by SmoothiesViewController but now FavoritesViewController also needs to use it. The problem is that these classes don’t know anything about each other. And preferably I would like to keep it that way (separation of concerns, remember?). So how can we make FavoritesViewController use the DataModel?

Obviously SmoothiesViewController is no longer the proper place to create the DataModel. I did that before because it was our only view controller, so it made sense. But now that we have another view controller that also needs to use the DataModel object, we have to refactor this code a little.

There are generally four ways to share your data model code among your controllers:

1. Make the shared data a global variable
2. Make the shared data a singleton
3. Put the shared data in your application delegate
4. Make one class the owner of the object and pass a (weak) reference to any other class that needs to use the object

The first three are variations on the same theme and I’ll explain below how to do that but also why you really shouldn’t.

Global variables

A global variable is a variable that can be accessed from anywhere in your code. We can make our DataModel object a global by making these changes:

In DataModel.h, below the interface definition:

@interface DataModel : NSObject
...
@end
 
extern DataModel* dataModel;

The “extern” line tells any code that #imports DataModel.h that there is a global variable named dataModel that points to an instance of a DataModel object.

The extern declaration just said that there was a dataModel variable defined somewhere, but it didn’t actually define it yet. We do that in DataModel.m, near the top:

#import "DataModel.h"
 
DataModel* dataModel = nil;
 
@implementation DataModel
...
@end

We still need to create the instance of DataModel and put it into that variable because currently it is nil. The app delegate is a logical place for that:

// in SmoothieAppDelegate.m:
#import "DataModel.h"
 
@implementation SmoothieAppDelegate
 
+ (void)initialize
{
	if ([self class] == [SmoothiesAppDelegate class])
	{
		...
 
		dataModel = [[DataModel alloc] init];
	}
}

Because we #import DataModel.h, our app delegate knows about the global variable dataModel and can put values into it.

Now in FavoritesViewController‘s table data source we do:

- (NSInteger)tableView:(UITableView*)theTableView numberOfRowsInSection:(NSInteger)section
{
	// Return the number of favorites
	return [dataModel favoritesCount];
}
 
- (UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath
{
	... make a UITableViewCell ...
 
	// Get the favorite Recipe from the list
	Recipe* recipe = [dataModel favoriteAtIndex:indexPath.row]; 
 
	// Put the Recipe data into the cell
	cell.textLabel.text = recipe.name;
	cell.imageView.image = recipe.image;
 
	return cell;
}

Note that the favoriteAtIndex: method now returns a Recipe object, not just the name of the Recipe. This lets us put the recipe’s image into the cell as well.

Pretty sweet, right? Well, there is a problem: using globals is considered bad programming practice. It generally makes programs harder to understand. The value of dataModel can be changed at any point in the program, and then any other objects that depend on dataModel might start to behave strangely if they did not expect that change. In our small app that doesn’t happen but when a program grows larger and starts to use more and more globals, it becomes a lot harder to keep track of what is going on.

Now, I admit that I use global variables from time to time. Occasionally they are the best way to solve a certain problem. Most of the time, however, they aren’t. Whenever you are tempted to use a global variable, try to find a cleaner solution first.

You can find the source code for this solution in Version 6A.

Singleton

The singleton is a controversial design pattern because it is basically a global variable hidden in a class. The iOS API uses singletons in various places. We’ve already seen one when we used NSUserDefaults.

There are two ways to make singletons:

1. Use only class methods. This class will not have an instance. This method isn’t very common as it is a little cumbersome to use.
2. Make a single instance of the class behind the scenes and use a class method that gives access to it. This is what [NSUserDefaults standardUserDefaults] does.

I’ll demonstrate how to do the latter. Add the following method to DataModel.m:

+ (id)sharedInstance
{
	static DataModel* instance = nil;
	if (instance == nil)
	{
		instance = [[self alloc] init];
	}
	return instance;
}

If you want to use DataModel anywhere, you use [DataModel sharedInstance]. This only creates a new DataModel instance once, the first time you call it.

FavoritesController‘s data source method now becomes:

- (NSInteger)tableView:(UITableView*)theTableView numberOfRowsInSection:(NSInteger)section
{
	// Return the number of favorites
	return [[DataModel sharedInstance] favoritesCount];
}
 
- (UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath
{
	... make a UITableViewCell ...
 
	// Get the favorite Recipe from the list
	Recipe* recipe = [[DataModel sharedInstance] favoriteAtIndex:indexPath.row]; 
 
	// Put the Recipe data into the cell
	cell.textLabel.text = recipe.name;
	cell.imageView.image = recipe.image;
 
	return cell;
}

Similar changes were made to SmoothiesViewController.

This is only a simple implementation of the singleton pattern. There is nothing stopping you from doing:

DataModel* anotherDataModel = [[DataModel alloc] init];

Apple has some sample code that can help prevent this, but I never find that worth implementing. Just stick to the convention that your code has to use this class through the +sharedInstance method.

The main problem with singletons is that, just like global variables, they make it harder to isolate parts of the code. It is often desirable to keep the scope of objects as small as possible, i.e. to restrict the use and visibility of an object to only the portion of the code that depends on it. But a global as well as a singleton are visible anywhere in the code. This increases the general complexity of the code and thus makes it harder to understand. Again, for a small app such as this using a singleton won’t get you into trouble, but there is a better way that I will be showing you soon. First, however, a worse way.

You can find the singleton source code in Version 6B.

Application delegate

As I said, iOS itself uses singletons in various places and one of these is UIApplication. Because UIApplication has a delegate that you already have to write a class for, many people treat their app delegate as a kind of singleton too. They like to put shared data in their app delegate class, simply because it is convenient.

Here is how that works. We add DataModel as a property to SmoothieAppDelegate, and create the instance when the app starts up:

- (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions
{
	// Create the Data Model object
	self.dataModel = [[[DataModel alloc] init] autorelease];
 
	...
}

Then to use this shared DataModel object in our code, we do:

- (NSInteger)tableView:(UITableView*)theTableView numberOfRowsInSection:(NSInteger)section
{
	// Return the number of favorites
	DataModel* dataModel = (SmoothieAppDelegate*)[[UIApplication sharedApplication] delegate];
	return [dataModel favoritesCount];
}
 
- (UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath
{
	... make a UITableViewCell ...
 
	// Get the favorite Recipe from the list
	DataModel* dataModel = (SmoothieAppDelegate*)[[UIApplication sharedApplication] delegate];
	Recipe* recipe = [dataModel favoriteAtIndex:indexPath.row]; 
 
	// Put the Recipe data into the cell
	cell.textLabel.text = recipe.name;
	cell.imageView.image = recipe.image;
 
	return cell;
}

Everywhere we want to use the data model, we now have to do this first:

DataModel* dataModel = (SmoothieAppDelegate*)[[UIApplication sharedApplication] delegate];

And we have to #import “SmoothieAppDelegate.h” in every file where we want to use DataModel.

Yuck. Because that is ugly, some people even go as far as this:

#define AD ((SmoothieAppDelegate*)[[UIApplication sharedApplication] delegate])
 
Recipe* recipe = [AD.dataModel favoriteAtIndex:indexPath.row];

Please, don’t resort to such atrocities! It makes me sad to see code like that.

Just because you already have an AppDelegate class and that you can access it more or less as a singleton, doesn’t mean that this is the proper place for your data model code.

I did not make a source code example for this, because this approach is horrible! I really want to dissuade you from using it. On to the proper solution…

Passing references

The idea is simple: there will be one owner of DataModel. In our case, we’ll make our app delegate the owner. There is nothing wrong with that. But instead of always asking the app delegate for what the data model is, the app delegate will pass a reference to the data model to any class that needs to use it. We already did something similar before when SmoothieViewController passed its DataModel reference on to RecipeDetailsViewController.

In SmoothieAppDelegate.h we add the following:

@class DataModel;
@class SmoothiesViewController;
@class FavoritesViewController;
 
@interface SmoothiesAppDelegate : NSObject 
 
...
 
@property (nonatomic, retain) IBOutlet SmoothiesViewController* smoothiesViewController;
@property (nonatomic, retain) IBOutlet FavoritesViewController* favoritesViewController;
 
// The shared Data Model object
@property (nonatomic, retain) DataModel* dataModel;
 
@end

We added the DataModel as a retained property, and we added two new IBOutlets so we can refer to the SmoothiesViewController and FavoritesViewController from the app delegate. I connected these outlets in Interface Builder.

We need those outlets because that is how we pass the DataModel reference around:

// in SmoothieAppDelegate.m:
- (BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions
{
	// Create the Data Model object
	self.dataModel = [[[DataModel alloc] init] autorelease];
 
	// Tell the view controllers about the Data Model
	self.smoothiesViewController.dataModel = self.dataModel;
	self.favoritesViewController.dataModel = self.dataModel;
 
	[self.window addSubview:self.tabBarController.view];
	[self.window makeKeyAndVisible];
	return YES;
}

Both SmoothiesViewController and FavoritesViewController now have a property for the data model:

// in SmoothiesViewController.h and FavoritesViewController.h:
@property (nonatomic, assign) DataModel* dataModel;

This is a weak reference because these objects don’t own the data model instance; they just use it. Because the app delegate class will be around until the app exits, so will the data model object.

As you can see, this approach requires that you make a few more properties than if you were to use a global variable or singleton, but it’s a cleaner solution. The Smoothies and Favorites view controllers don’t care where the data model object comes from; they just know that it’s there when they need it and that they can access it through their self.dataModel property:

- (NSInteger)tableView:(UITableView*)theTableView numberOfRowsInSection:(NSInteger)section
{
	// Return the number of favorites
	return [self.dataModel favoritesCount];
}
 
- (UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath
{
	... make a UITableViewCell ...
 
	// Get the favorite Recipe from the list
	Recipe* recipe = [self.dataModel favoriteAtIndex:indexPath.row]; 
 
	// Put the Recipe data into the cell
	cell.textLabel.text = recipe.name;
	cell.imageView.image = recipe.image;
 
	return cell;
}

So it’s a little harder to set up in the AppDelegate, but it’s easier to use after that.

You only pass the data model to objects that need it. Those objects now don’t depend on any other part of the code to do their job. That’s an approach I have been using throughout this tutorial series. For example, when we open the Recipe Details screen, we give that view controller all the data it needs to use and nothing more. The view controller is completely self-contained; it does not depend on any other classes or global variables to do its job. Once we’ve created it and filled in its properties, it is good to go.

We could put the Recipe Details screen in a totally different part of the app if we wished, as long as we have a DataModel and Recipe object to give it. You should strive to design your view controllers (and any other classes) that way, with a little dependencies on external state as possible.

You can find the source code for the final solution in Version 6C.

Our class diagram now looks like this:

Figure 6.1. The DataModel is now shared among the view controllers.

In this chapter, we hid the fact that favorites are stored with NSUserDefaults. If we want to change how we store the favorites — maybe a PList file or JSON would be better – then we can do that without having to change anything besides DataModel. It is DataModel‘s responsibility (and DataModel alone) to store and retrieve this data. None of your other classes should have to care about that. All they care about is that they can ask the DataModel for how many favorites there are, and what they are. It’s up to DataModel to make sure it does that properly, but how it does that is an implementation detail as far as anyone else is concerned.

Note: We could have stored the fact whether a recipe is a favorite or not directly into the Recipe object instead of DataModel. Sometimes it’s obvious where a piece of data or logic goes, but often it’s a matter of taste and personal preference. There is usually more than one way to do it. And if you find in the course of developing your app that your initial choice is no longer the best choice, then ruthlessly refactor your code until its structure is good again. It doesn’t really matter to me, as long as your code is clean!

In part 3 of this tutorial, we’ll finish the app.

One question that I see a lot on developer forums is: “How do I use a variable from one class in another?” Or related: “How does my class call a method from another class?” Or: “How do I send my data from view controller A to view controller B?”

Obviously these are newbie questions, and a typical answer is: go read a book on programming. While I certainly recommend that beginners get a good book on Objective-C and a book on developing for iOS, I may be able to offer some tips on how to structure your programs.

There are several approaches you can use and I’ll highlight the most common ones. I will also point out bad practices that you should avoid in your own apps.

I always put a lot of effort into keeping my code as clean as possible. I will often rewrite large sections of my app when they have become too messy. If you let the source become too complex, then fixing bugs or adding new features will be a nightmare. Knowing a handful of best practices for structuring your code will help you to stay sane and it will also make your apps better.

Hopefully my explanations will be clear enough to understand, even if you’re just getting started developing for the iPhone or iPad. Let me know in the comments how you’re getting along!

Model-View-Controller

Much of UIKit is built around the idea of Model-View-Controller, or MVC for short. You will get the most out of working with UIKit if you split up your code into three different parts:

The models. These classes contain your data and any operations on the data. For example, if you are writing a cookbook app, the model would consist of the recipes. You should be able to take this code and port it to a completely different platform (such as Mac OS X or Android) without too many modifications (although you may need to switch programming languages). Your model code will be dependent on Objective-C and Foundation, but not on UIKit.

The views. These form the visual part of the app: images, buttons, labels, text fields, and so on. A view can draw itself and respond to user input, but it typically does not handle any application logic. Most views can be re-used in many different applications because they are not tied to a specific data model. To show a list of recipes, we could use a standard UITableView. To show a single recipe in more detail, we would also use standard controls: a label for the title of the recipe, an image view for a photo, and a text view for the cooking instructions.

The controllers. Simply put, each screen in your application will have its own controller. The main list of recipes sits in a UITableViewController, which is a subclass of UIViewController that works with a dedicated table view. If you tap on a row in that list, the details screen for that recipe should open. That screen is also a subclass of UIViewController. The controller is what connects your data model to your views. The view controller has a view that shows the contents of the screen, which it loads from your data model.

Conceptually, this is how it fits together:

The trick is splitting up our app’s functionality into such models, views and controllers, and making all these different classes talk to each other. That’s exactly what this tutorial is about.

All this talk of recipes makes me hungry. Let’s do something about that!

Smoothies!

To illustrate these concepts, I have made a simple but complete app, named Smoothies. As you can guess from the name, it’s a smoothie recipe app. In its finished state it looks like this:

In this article series we will build the app step-by-step. We will begin with the most basic of features and with every new version we add features and refactor the code to keep it clean and well-organized. By the end of this article you should have a good idea of the different approaches to organizing your classes and what are the pros and cons of each approach. But let’s begin with the very basics.

Version 1: Building the skeleton

This first version of the app will look like this:

Figure 1.1. The very basic first version of our smoothie recipes app.

It’s just an empty table view with a title bar on top. The table view sits in a UITableViewController, which in turn belongs to a UINavigationController. This is a standard design for many iPhone apps. I’m sure you will have seen it before.

You can view and download the source code for Version 1 from github.

I used Xcode’s “View-based Application” template to create a new project. Then I reorganized the files a bit because I don’t like where the standard template puts them.

The template makes an application delegate, SmoothiesAppDelegate, and a view controller, SmoothiesViewController. I cleaned up the app delegate a bit and changed SmoothiesViewController from a basic UIViewController into a UITableViewController. We want to display a list of smoothies and a table view is ideal for that.

I also made some changes to the nib files. I removed SmoothiesViewController.xib because we no longer need it now that we’re using a table view controller. In MainWindow.xib I added a navigation controller and put the SmoothiesViewController inside that. The navigation controller provides the title bar at the top of the screen, and we’ll use it later to present a details screen when you tap the name of a recipe.

Figure 1.2. The MainWindow.xib in Interface Builder.

The application delegate has a navigationController outlet, which I connected to our UINavigationController (see under “Referencing Outlets” in the right side bar in figure 1.2). When the app starts up, the delegate adds this controller’s view to the window and makes it visible. Because we set the SmoothiesViewController as the root of the navigation controller, it shows up in the window as well.

This should be familiar to you if you’ve done any iOS programming before. Having an app delegate and a view controller are the basics of any app.

Our class structure currently looks like this:

Figure 1.3. We have three classes that are connected together.

Notice that nowhere in our code do we use the UINavigationController class directly. It is instantiated for us when MainWindow.xib is loaded during app startup, and we only need it to hold our SmoothiesViewController.

Take a quick peek at the source and build and run the project. It doesn’t do much yet, but we’re off to a good start!

Version 2: Adding a Recipe class

Let’s put some recipes on the screen. First, we need to decide exactly what constitutes a recipe. To keep things simple we’ll just give each recipe three attributes: a name, the preparation instructions, and an image. We’ll show the name and image in the table view on the app’s main screen. To see the entire recipe in detail you’ll have to tap on it, but that is for the next version.

Figure 2.1. What the app will look like at the end of this chapter.

Since a recipe is a separate entity in our app, it makes sense to give it its own class. It shouldn’t surprise you that I named it Recipe. In this case it was easy to name our class, but it isn’t always so. Finding good names for your classes is an important part of writing clear and maintainable code, so don’t skimp on it!

Recipe is a so-called data model class. Its purpose is to describe what a recipe is, nothing more. In a little while we will also need write some logic to display the recipes on the screen, but that logic will not be part of the Recipe class.

This the Model-View-Controller separation that I talked about earlier. It makes sense to organize your classes by the principle that anything that can be considered pure data goes into its own set of classes. Any calculations on that data (often called the “business logic” or “domain logic”) also goes into these classes. In our case, the topic of our app is recipes, so it makes sense to consider recipes to be part of our app’s data model.

The data model classes are separate from the controllers and views. Recall that the views are used to display the items from the data model on the screen. Their function isn’t to store data or perform calculations on it; views just know how to draw stuff. Examples of views are labels, sliders, buttons, and so on. The task of the controller is to connect the two together.

For the moment, we won’t do much with recipes except show them in a table, so the Recipe class will be very simple.

I used Xcode’s New File assistant to create the Recipe class, which extends from NSObject. The assistant created two files, Recipe.h and Recipe.m, and this is what they look like after I added my data model code to them.

Here is Recipe.h, the interface of the Recipe class:

@interface Recipe : NSObject
{
}
 
@property (nonatomic, copy) NSString* name;
@property (nonatomic, copy) NSString* instructions;
@property (nonatomic, retain) UIImage* image;
 
@end

It’s very simple. I subclassed NSObject and added properties for the recipe’s name, instructions and image.

Copy vs retain

Notice that the name and instructions properties are declared with “copy” semantics. This is a good idea for properties of type NSString, NSArray, NSSet, and a few others.

Let me briefly explain. NSString has a subclass NSMutableString, which means you can use an NSMutableString instance anywhere you can use an NSString. The following code is perfectly valid, but it produces different rules if the name property is declared with retain or copy:

NSMutableString* str = [NSMutableString stringWithString:@"Raspberry Smoothie"];
 
Recipe* recipe = [[[Recipe alloc] init] autorelease];
recipe.name = str;
 
NSLog(@"Recipe name is now: %@", recipe.name);
// This outputs "Raspberry Smoothie"
 
[str appendString:@" with Chocolate"];
 
NSLog(@"Recipe name is now: %@", recipe.name);
// This should still output "Raspberry Smoothie"
// and not "Raspberry Smoothie with Chocolate"

In this example, we assign the NSMutableString object to recipe’s name parameter. No problem here, but then we change that mutable string object. If name was declared as retain instead of copy, then the Recipe‘s name would be changed out from under it. Since you usually do not want that to happen, specify copy for any property whose type also has a mutable subclass. If you’re not very familiar with the various classes in the Foundation framework yet, then just remember to do this for NSString and NSArray.

By the way, if you haven’t seen NSLog() before, this function writes text to the console window. It’s very handy for debugging and for figuring out what is going on in your app.

The implementation of Recipe

On to the implementation inside Recipe.m:

#import "Recipe.h"
 
@implementation Recipe
 
@synthesize name, instructions, image;
 
- (void)dealloc
{
	[name release];
	[instructions release];
	[image release];
	[super dealloc];
}
 
- (NSString*)description
{
	return [NSString stringWithFormat:@"%@ %@", [super description], self.name];
}
 
@end

There is not much special in the .m file, except maybe for the description method. This method is defined by NSObject and we override it here with our own version. The purpose of description is to help with debugging. When we now do:

NSLog(@"Recipe name is now: %@", recipe);

the console will show something like this:

Recipe name is now:  Raspberry Smoothie

Note that we did not call [recipe description]. NSLog() will automatically call description for us, so that saves some typing. The bit between the brackets is the name of the class and its memory pointer. This is done by NSObject, thanks to our call to [super description].

Our own version of description added the name of the smoothie to the output. If our app now crashes on something that has to do with a recipe, this makes it a little easier for us to determine which particular Recipe object is the culprit.

Filling up the table

A UITableView needs a data source and a delegate to provide it with the entries it needs to display and other information. If you recall, our SmoothiesViewController is actually a subclass of UITableViewController, and a table view controller automatically serves as both the delegate and data source for the table. That’s very handy! Now we simply have to add a few methods to our SmoothiesViewController to make this all work.

Let’s create a list of recipes first. Add the following to SmoothiesViewController.h:

// The list of Recipe objects
@property (nonatomic, retain) NSMutableArray* recipes;

And to SmoothiesViewController.m:

@synthesize recipes;
 
- (void)dealloc
{
	[recipes release];
	[super dealloc];
}

All we did here was add a property recipes of type NSMutableArray. This list will hold our Recipe objects. You always have to do this sort of housekeeping when you want to add a property: declare the @property in your .h, add a @synthesize in your .m, and release it in your dealloc if the property is of type “copy” or “retain”.

Now we can create the recipes list and fill it up with some tasty recipes. In SmoothiesViewController.m add:

- (id)initWithCoder:(NSCoder*)aDecoder
{
	if ((self = [super initWithCoder:aDecoder]))
	{
		// Create the recipe list object
		recipes = [[NSMutableArray arrayWithCapacity:10] retain];
 
		// And add a few recipes to it
		Recipe* recipe = [[Recipe alloc] init];
		recipe.name = @"Banana Shake";
		recipe.instructions = @"...";
		recipe.image = [UIImage imageNamed:@"Banana Shake.png"];
		[recipes addObject:recipe];
		[recipe release];
 
		... we add more recipes here ...
	}
	return self;
}

The initWithCoder method is called when the view controller is loaded from the nib. We use it to allocate and initialize the recipes array, and then we create several new Recipe objects and add them to that array.

We’re not done yet. We still have to tell the table view to display the entries from this array. Add the following methods to SmoothiesViewController.m:

- (NSInteger)tableView:(UITableView*)tableView numberOfRowsInSection:(NSInteger)section
{
	return self.recipes.count;
}
 
- (UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath
{
	static NSString* CellIdentifier = @"RecipeCellIdentifier";
 
	UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
	if (cell == nil)
		cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
 
	Recipe* recipe = [self.recipes objectAtIndex:indexPath.row];
	cell.textLabel.text = recipe.name;
	cell.imageView.image = recipe.image;
	return cell;
}

This should be old-hat for anyone who has used a UITableView before. In numberOfRowsInSection:, we simply return the number of recipes in our list. In cellForRowAtIndexPath: we first obtain a UITableViewCell and then set the cell’s text label and image with the properties from the Recipe at the specified row.

You can run the app now and you’ll see a list of recipe names, each of which has a small thumbnail image to the left. There is one more tweak I’d like to make. The standard height of table view rows is 44 points, which is a little small for our thumbnails. So we’ll set it to 66 points instead.

Add the following snippet to SmoothiesViewController.m:

- (void)viewDidLoad
{
	[super viewDidLoad];
	self.tableView.rowHeight = 66;
}

As its name implies, this method is called after the view controller’s view is loaded. We want to set the rowHeight property of the table view, and this is the ideal place to do it. We cannot do this in initWithCoder because that is too early; by then the table view is not created yet and self.tableView is still nil.

The class structure

To recap, we added a Recipe class and modified the SmoothiesViewController class to hold an array of those Recipe objects. The class structure is now as follows:

Figure 2.2. We added a list of Recipe objects to the SmoothiesViewController.

I have encircled the classes that form our data model. It consists not just of the Recipe objects, but also of the NSMutableArray that contains them.

We also wrote code to display these Recipe objects on the screen. For every Recipe, we made a UITableViewCell and set its text label and image to the data from the recipe. The UITableViewCell serves as the “view” for the recipe. The SmoothiesViewController ties both of them together in the table view’s data source methods. There you have Model-View-Controller in action!

This concludes version 2 of the app. You can get the full source code from github. Next, we’re going to add the Recipe Details screen, which shows up when you tap on a recipe.

Version 3: Recipe details

So far we’ve just shown the names of the recipes and a thumbnail image. I would really like to go make a smoothie now, so it’s time to add some functionality to the app that lets us see the actual recipes. We’re going to add the Recipe Details screen that shows up when you tap a smoothie in the table view. It will show the title of the smoothie, a photo (a bigger version of the thumbnail), and the recipe instructions.

This is what it will look like:

Figure 3.1. That looks delicious!

A new screen means a new view controller. Basically, every screen in your app uses its own UIViewController subclass (such as UITableViewController or a subclass of your own). Sometimes you can re-use the same view controller class for different screens if those screens are similar, and we’ll see an example of that later in this tutorial.

For the Recipe Details screen we will make our own subclass, RecipeDetailsViewController, that extends directly from UIViewController. It will be loaded from a nib file, so we can make the UI in Interface Builder.

I used Xcode’s New File wizard and chose “UIViewController subclass” and checked “With XIB for user interface”. I opened the nib in Interface Builder and added an image view for the photo and a text view for the instructions. We’re going to display the recipe’s name in the navigation bar, so we don’t need to add a label for that.

Then I connected these new subviews to outlets in the source file. In Xcode 4 that is really easy to do. Hold down Ctrl and drag from a subview into the .h file. This will automatically insert the @property statement for you, as well as @synthesize and release statements in the .m file.

Figure 3.2. The new view controller in Interface Builder.

Let’s connect this new screen to our table view. Add the following code to SmoothiesViewController.m:

- (void)tableView:(UITableView*)tableView didSelectRowAtIndexPath:(NSIndexPath*)indexPath
{
	RecipeDetailsViewController* controller = [[RecipeDetailsViewController alloc] init];
	[self.navigationController pushViewController:controller animated:YES];
	[controller release];
}

This is a method from the UITableViewDelegate protocol. It is called when the user taps one of the rows in the table. We create a new instance of the RecipeDetailsViewController (this will automatically load the nib file) and then push it on the navigation stack. Try it out. You can now tap on the name of a smoothie and in response the Recipe Details screen will appear. Because we pushed this screen onto the navigation controller, you can close it again by pressing the back button in the top left.

Displaying the recipe

At this point, the Recipe Details screen doesn’t do much yet. We still have to tell it which Recipe object to display. So how do we get the recipe to show up in this screen? First, we add a @property to the interface of the view controller in RecipeDetailsViewController.h:

@class Recipe;
 
@interface RecipeDetailsViewController : UIViewController
{
}
 
@property (nonatomic, retain) IBOutlet UIImageView* imageView;
@property (nonatomic, retain) IBOutlet UITextView* instructionsTextView;
 
// This is the new property
@property (nonatomic, retain) Recipe* recipe;
 
@end

Then we change the table view delegate method to:

// in SmoothiesViewController.m:
- (void)tableView:(UITableView*)tableView didSelectRowAtIndexPath:(NSIndexPath*)indexPath
{
	RecipeDetailsViewController* controller = [[RecipeDetailsViewController alloc] init];
 
	// Pass the Recipe object to the controller
	Recipe* recipe = [self.recipes objectAtIndex:indexPath.row];
	controller.recipe = recipe;
 
	[self.navigationController pushViewController:controller animated:YES];
	[controller release];
}

After we have instantiated the controller, we look up the Recipe object in our data model and then pass it on to the new controller. This gives the controller everything it needs to know about the recipe.

We’re not done yet. In the implementation of RecipeDetailsViewController, we add the viewDidLoad method:

// in RecipeDetailsViewController.m:
- (void)viewDidLoad
{
	[super viewDidLoad];
	self.title = self.recipe.name;
	self.imageView.image = self.recipe.image;
	self.instructionsTextView.text = self.recipe.instructions;
}

Here, we take the Recipe‘s attributes and use them to configure our subviews. We set self.title to the recipe’s name; the navigation bar will use this as its own title. We set the recipe’s image on the image view and the instructions on the text view.

This approach works because we assigned the recipe to the view controller before we did pushViewController. If we had done it in the order below, it would not have worked because viewDidLoad would have been called while the recipe property was still nil:

// This is the wrong order!
[self.navigationController pushViewController:controller animated:YES];
controller.recipe = recipe;

Classes are black boxes

Maybe you’re wondering why we’re giving a Recipe object to the RecipeDetailsViewController when we could have done it as follows:

- (void)tableView:(UITableView*)tableView didSelectRowAtIndexPath:(NSIndexPath*)indexPath
{
	RecipeDetailsViewController* controller = [[RecipeDetailsViewController alloc] init];
 
	Recipe* recipe = [self.recipes objectAtIndex:indexPath.row];
	controller.title = recipe.name;
	controller.imageView.image = recipe.image;
	controller.instructionsTextView.text = recipe.instructions;
 
	[self.navigationController pushViewController:controller animated:YES];
	[controller release];
}

After all, imageView and instructionsTextView are properties on the view controller, so we can access them from outside the class. I advise against doing it like this. It exposes the internal details of RecipeDetailsViewController and it is better to keep those hidden.

This is one of the main principles of object-oriented programming. Each class performs a certain job but from the point of view of someone using that class, it acts as a “black box”. You know what goes into it and you can see what comes out of it, but you have no idea what it does on the inside. And that’s great, because that is one less thing to worry about (as long as you are guaranteed that the class does its job properly and is fast enough).

Hiding away the details of how a class works helps to reduce the complexity of your program. That makes it easier to understand how all the classes in your program work together, without getting lost in unnecessary details. It also helps to reduce “side effects”, where a change in the implementation of one class causes an unwanted change (usually a bug!) somewhere else in the code. So in short: make your classes as independent from each other as possible!

In our app, the subviews of RecipeDetailsViewController are its own business. The SmoothiesViewController shouldn’t have to know whether the name of the recipe goes into the Recipe Details screen’s title bar or in a UILabel, for example. It should just say to the RecipeDetailsViewController, “Here is the name of the recipe. Do with it what you want. I trust you will put it in the right place.”

It is then the responsibility of RecipeDetailsViewController to set the content of its subviews. The SmoothiesViewController doesn’t need to know how RecipeDetailsViewController does its thing; it just gives it a Recipe object and that’s it.

Likewise, the RecipeDetailsViewController does not have to be concerned with the list of all the recipes, it just needs to know about a single one. When you tap on another smoothie, we create a new RecipeDetailsViewController and assign it the Recipe object for that particular smoothie. This “separation of concerns” helps to keep the design of your apps simple and clean.

That’s it. In this chapter you’ve seen how you can pass data from one view controller to another, and we’ll be doing this again and again in next chapters.

Our class structure now looks like this:

Figure 3.3. We added a view controller for the Recipe Details screen.

Download the source code for this version

If you’re ready for more, head on over to part 2.

There are several strategies for creating these higher-resolution images:

1. Draw the image using vectors at 1x scale and scale up 200% to get the Retina image.
2. Draw the image using vectors at 2x scale and scale down 50% to get the low-res image.
3. Draw the image using pixels at 2x scale and scale down. You can also combine pixels and vectors.
4. Draw the 1x and 2x images separately, either as vectors or bitmaps.

Ideally, you’d use vectors for everything because they scale better than bitmaps. Vector graphics can scale up or down without quality loss. However, if your image includes a texture background then you’ll need to use a bitmap anyway. Just never scale bitmaps up, only down.

Don’t use Photoshop to scale down bitmaps

Scaling down bitmaps in Photoshop is problematic because the various scaling filters (bicubic, nearest neighbor, etc) introduce artifacts. They are designed for scaling photos, not application graphics.

I found the best way to scale down is to take each group of 2×2 pixels and average them into a single pixel. If you observe a few rules when drawing the Retina image, then this type of scaling is comparable to vector scaling

The rules are: snap everything to a 2×2 grid and make all your stroke widths multiples of two. A crisp 3-pixel stroke at high resolution turns into a blurry 2-pixel stroke when scaled down (because you can’t have 1.5 pixels).

I wrote a simple command-line utility, ShrinkPng, that takes a @2x.png file and halves its dimensions the way I just described. It scales with higher fidelity than Photoshop, so if you’ve been frustrated by the way Photoshop scales down your high-res images, give this tool a shot.

You run ShrinkPng from the Terminal, like so:

ShrinkPng Image@2x.png

It outputs “Image.png”, overwriting any existing file with that name. I only wrote this quickly, so there is no nice user interface. I found that it works best when the input PNG does not have an embedded color profile. You can strip color profiles from PNG files using the pngcrush tool:

pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB in.png out.png

Note that scaling down bitmap text is a bad idea. Fonts are vector graphics that have embedded hints for drawing at small sizes, which will generally produce better results than rasterizing a font at high-resolution and scaling it down by hand, no matter which scaling algorithm you use.

Draw your images twice

Even though it is double the work, I tend to favor the “draw the 1x and 2x images separately” method. A Retina image is more than just the low-resolution image at twice the size. You can see this in the standard navigation bar buttons:

The strokes in the Retina version are not simply doubled but have additional detail. They look more like a 1.5 pixel stroke than a 2 pixel stroke, which makes the edges slightly softer. Compare also the drop shadow at the bottom of the button.

My current approach goes like this:

1. First draw at 1x, using vectors where possible.
2. Scale up to 2x. Replace any pixel artwork, such as textures, with a higher resolution version.
3. Add subtle details to the 2x image.
4. Export the images separately.

The appeal of first drawing the 1x size is that it gives you a good idea of the limits of your image. If you start out at 2x then you might be tempted to put in too much detail that will not only get lost when you scale down, but will also muddy up the low-res image.

Good tools are hard to find

As for the actual drawing of the images, I’m a little disappointed by Photoshop’s drawing functions. Layer styles are great, but its vector drawing tools leave much to be desired. For anything beyond simple button shapes you have to use a true vector drawing application such as Illustrator.

For the past few years, GIMP has been my image editor of choice. It is open source, has a ton of features and you can’t beat the price. However, since starting as a freelance iOS developer I’ve had to bite the bullet and buy Photoshop.

There is no way around it, Photoshop simply is the de facto standard for image work. Clients like to send .psd files and the only reliable way to open them is to have a copy of Photoshop. (You can also view PSD files in QuickTime Player, but that is useless if you need to cut up the design into separate images.)

Photoshop could actually learn a thing or two from GIMP. For example, GIMP lets you easily tweak a marquee selection after you’ve made it, using a set of dragging handles. You can also alter the radius of rounded rects after the fact. In Photoshop you always have to eye things just right the first time or do it all over again. Very frustrating. (Other wish: snap-to-pixel for everything.)

If not for the fact that I spent a lot of money on it and invested quite a bit of time to learn how to use it, I’d probably swap Photoshop for the recently released Acorn 3.0. It seems to have about the same kind of functionality as far as drawing is concerned and it’s a lot cheaper!

Acorn also claims to import PSD files, but in my experience you can only trust Photoshop to read PSD files correctly, especially if they contain Smart Objects and vector layers. If you’re doubting whether to get Photoshop, give Acorn a try first!

As for vector drawing apps, I’m considering forking over even more cash to Adobe for a copy of Illustrator, but for the time being I’ll stick to Inkscape. This is GIMP’s little vector brother. It’s a little less stable than GIMP and it has a number of annoying user interface quirks, but it’s a pretty good application otherwise.

Unfortunately you can’t paste an Inkscape drawing as a vector object into Photoshop; that only seems to work with Illustrator.

There is also Opacity, but I found its vector drawing tools too limited for my use.

Are there any other, relatively inexpensive, Mac OS X vector drawing tools out there that I may have missed? If you know any, let me know in the comments. Thanks!

I have a few promo codes left over and I thought it would be nice to give them away to the readers of my blog before they expire. It’s first come, first serve, so be quick if you want one.

Here are the codes:

FETMJYPHETJF
R7FHFA3L3KWX
9L7K4P4NJ6TN
KPA6XRTKLETX
KJ6PJ63XR6FH

To redeem the promo code, go to the iTunes Store in iTunes and click Redeem. Enter the code and iTunes should start downloading the app. If it doesn’t work, then you were too late.

For the lucky few who manage to get their hands on a code, enjoy the app! (And if you like it, I’d appreciate it if you left a review in the App Store. Thanks!)

The app first downloads the list of top paid apps from iTunes (this is an XML file) and shows the list of apps in a UITableView. Then it downloads the icons for the apps in the background and displays them as they become available. Until the icon is loaded, a placeholder image is visible instead.

Only the icons for the visible rows are downloaded; when you scroll the table to make new rows visible, it downloads the icons for these new rows (but only when you are done scrolling).

For a recent client project, I needed to do something similar on several different screens. I took the code from this sample project and rewrote it so it was more generic and could be reused among my different view controllers. Today I decided to refactor this some more and make the code available as an open source component. That component is named MHLazyTableImages and you can download it at github.

To demonstrate how to use this class, I modified Apple’s original LazyTableImages sample. The logic for downloading the images is now handled by the MHLazyTableImages and MHImageCache classes. The table view controller only has to create an instance of MHLazyTableImages and connect its data model and table view to it.

To put an image into a table view cell, you simply call -addLazyImageForCell:withIndexPath:. This will first see if the image is already present in the cache and will download it if not.

- (UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath
{
	UITableViewCell* cell = [tableView dequeueReusableCellWithIdentifier:...];
	if (cell == nil)
		cell = [[[UITableViewCell alloc] initWithStyle:...];
 
	cell.textLabel.text = ...;
	[lazyImages addLazyImageForCell:cell withIndexPath:indexPath];
}

Of course, you need to tell MHLazyTableImages about the URL for the image. That happens in a delegate callback method:

- (NSURL*)lazyImageURLForIndexPath:(NSIndexPath*)indexPath
{
	AppRecord* appRecord = [self.entries objectAtIndex:indexPath.row];
	return [NSURL URLWithString:appRecord.imageURLString];
}

I used a delegate — rather than telling MHLazyTableImages directly what the URL should be for the cell — in order to accommodate scrolling. While scrolling, we don’t want the images to load yet. We will defer downloading until the user stops scrolling. What that happens, -lazyImageURLForIndexPath: is automatically called for the newly visible rows.

There are a few more things that need to happen to make it all work, but that is the gist of it.

Just for fun, I also replaced the original networking code with ASIHTTPRequest. I was already using this class in MHImageCache, and it allowed me to use blocks instead of delegates. That means the demo project will work only on OS 4 and up.

Check out the demo project (RootViewController in particular) to see how everything works in detail.

The average user browses the internet, sends email, and occasionally writes something in Word. The iPad is already capable of handling these tasks and many more; it just needs to be able to print wirelessly to any printer and you’re all set.

The iPhone and iPad have proven that touch as the primary mode of interaction works wonderfully well. The problem with today’s touch screens, however, is that there really isn’t much to touch. They are completely flat and smooth. Our fingers deserve more than that!

I imagine a touch screen where the outer glass layer consists of a matrix of squares that can be configured, electronically, to go up and down. This layer allows the programmer to create a terrain of bumps and holes on top of the pixels that make up the visual display.

When the app shows an on-screen keyboard, for example, it will also send signals to this tactile feedback layer to form actual button shapes on top of the pixel buttons. Tap one of those button shapes and the software will make it sink into the screen, giving the user the impression that he is tapping an actual button. If the refresh speed is quick enough, say 1/10th of a second, then this effect will be believable to the user.

Not every pixel needs to have a “bump”. I’m thinking that one bump per group of 4 pixels will be sufficient to make this work, with each bump having three possible positions: flat, raised or lowered. The raised position would be half a millimeter or so above the surface. Likewise, the lowered position would sink that same distance into the screen.

Seen from the side, it might look something like this:
Maybe if this technology becomes sufficiently advanced, several heights could be possible instead of just raised/flat/lowered. Ideally, there would be at least one bump per pixel. With this kind of configuration, the feel of real textures such as wood can be emulated. If the refresh speed is quick enough, even moving things such as a vibrating guitar string could be reproduced. Blind people could read braille straight from the device.

Of course this is wishful thinking. I doubt the technology to do anything remotely like this exists today and I don’t have a clue how one would go ahead and build it. Nanotechnology maybe — you don’t want any wires to be visible on top of the display — but that’s something of the far-away future. Also, because the glass is now no longer flat, care would need to be taken that the underlying picture does not get distorted.

Still, it’s fun to think of these things. Anyone already working on tech like this?