This is a simple and obvious technique, but it took me a while to adopt it: You can do by asserting with NSAssert or NSCAssert for [NSThread isMainThread], just as you would assert any other condition.

Like this:

- (void)updateUI {
    NSAssert([NSThread isMainThread], @"Only update UI from main thread");
    // update UI
}

- (void)backgroundWork {
    NSAssert(![NSThread isMainThread], @"Only do work off main thread");
    // do work
}

With assertions like this in place, you’ll sort out what executes where in short order.

I wish I had done this to my code right away; it’s much simpler to get it right than to go back and fix it all later.

For various reasons, you sometimes can’t use NSAssert in a block easily. I’m going to explain why and describe a new macro, BlockAssert, which solves this.

Background

An assertion is a predicate (a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place. (Source: Wikipedia.)

NSAssert and NSCAssert are Foundation’s assertion macros. They’re kind of like C’s assert macro, but provide an error message in the same form as NSLog. The difference between them is that NSAssert references self, which is only defined for Objective-C methods. NSCAssert, then, is NSAssert for C functions.

Blocks are often defined in Objective-C methods, but they’re not themselves Objective-C methods. Although they’re actually implemented as objects of their own, the syntax is more like a C functions. They don’t define self, though anything you want from the method scope are captured strongly into the block expression. This means that if you use NSAssert you’ll be capturing self. But that strong reference can cause a circular reference.

A circular reference is formed the block owns the object and the object owns something that owns the block. None of the memory will ever be cleaned up. Even you do clean up the memory, you’ll get a compiler warning that you need to ignore.

Rather than sort out which of these compiler warnings is valid, a lot of people use this pattern:

__weak typeof(self) weakSelf = self;
foo.completionBlock = ^{
	__strong typeof(self) strongSelf = weakSelf;
    [strongSelf doSomething];
};

This breaks the circular reference, and because we’ve used __weak we’re assured that weakSelf is not a dangling pointer. If self no longer exists, weakSelf is nil. Reassigning back to a __strong variable presents the variable from being deallocated

In this case, it’s not actually necessary to assign weakSelf to a __strong variable. The recipient of a message won’t be deallocated until the message returns. However, if you are doing multiple things with weakSelf — such as doing assertions against it and sending it a message — it could become deallocated between those messages.

The catch? NSAssert still uses the self variable by name. This led to an interesting question on StackOverflow about defining a block-scope self, a technique that’s valid but requires you to remember to do it every time and causes a warning if GCC_WARN_SHADOW is on.

A new assertion macro

In the past, I’ve mostly done avoided this by not using assertions in blocks. You don’t need them very often, as you can usually do your assertions in the method’s scope. But inspired by that question, I’ve found a better way: I define my own assertion macro.

I have several such macros I define, in a single file that’s imported in as part of my precompiled header.

The macro looks like this:

#define BlockAssert(condition, desc, ...) 
    do { 
        __PRAGMA_PUSH_NO_EXTRA_ARG_WARNINGS 
        if (!(condition)) { 
            [[NSAssertionHandler currentHandler] handleFailureInMethod:_cmd 
            object:strongSelf file:[NSString stringWithUTF8String:__FILE__] 
                lineNumber:__LINE__ description:(desc), ##__VA_ARGS__]; 
        } 
        __PRAGMA_POP_NO_EXTRA_ARG_WARNINGS 
    } while(0)

This is basically a copy-paste of NSAssert, but uses strongSelf instead of self. (Note, however, that we have not pretended to be part of Foundation by using a NS prefix.)

To use BlockAssert, you need to use the weakSelf = self; strongSelf = weakSelf; pattern, but you probably already are. And if not, the compiler will throw an error: Use of undeclared identifier: ‘strongSelf’. You can either adopt strongSelf or switch over to NSAssert.

For example:

- (IBAction)clickButton: (UIButton *)sender {
    sender.disabled = YES;
    [self performActionWithCompletion: ^{
        BlockAssert(state, @"Invalid state");
        sender.disabled = NO;
    }];
}

Conclusion

I think this is a pretty good approach: If you use NSAssert where you meant to use BlockAssert and it matters, you’ll get a warning about a potential circular reference. If you use BlockAssert where you meant to use NSAssert, you’ll probably get a compiler error.

I’m going to discuss how to do so, and why it’s a good idea.

Here’s an example, which I submitted to AFNetworking:

#if !__has_feature(objc_arc)
#error AFNetworking must be built with ARC.
// You can turn on ARC for only AFNetworking files by adding -fobjc-arc to the build phase for each of its files.
#endif

When the user builds the unit, the error will be highlighted. They’ll see the comment just below, explaining how to resolve the problem.

Adding it to every .m file may seem overkill, but there’s two good reasons for this:

1. No matter which file gets compiled first an error will top the list instead of warnings. It’s sufficient to add it only to a central file, but you’ll probably still get support requests that way. You’re better off adding it everywhere; this is all about reducing your work.
2. ARC can be decided on a per-file basis. If you include it in only one file, the user may add -fobjc-arc to just that one file!

But do not add this to your headers. Even if your code requires ARC, there’s no reason to require that the user’s code also use ARC. Apple did the right thing here.

The first one was clarification on how to fix a bug demonstrated by some Apple sample code. I got a response, but it wasn’t especially satisfying. But that’s okay, because in the end I found a way to do a different UI and avoid the bug entirely. Let’s call it a draw.

The second one, however, was a mistake in how I was using UIKit that I didn’t realize was a mistake. I boiled it down to a test case and submitted the project to Apple. As part of solving the incident, Apple not only explained what I was doing wrong, but provided snippets of code that would work.

This would be gold, but they also fully corrected my code the code I’d sent.

Of course, when I tried to integrate the solution back into my real application, I ran into other problems. However, the explanation Apple had offered me was enough that I was able to solve those other problems, too.

Basically, I got a fantastic code review out of that DTS incident by someone who clearly knows iOS and UIKit better than I ever will. Total win.

I don’t plan on wasting these in the future, but neither will I horde them in case of emergency. They’re worth using for the really nasty problems, and they’re not incredibly expensive to replace — $99 buys another two incidents.

The simplest example is a JPEG. You may get the JPEG you expect, but it’s also possible for the proxy to deliver a smaller JPEG than you expect. The cell provider considers it “close enough”, and the doubly-compressed JPEG is smaller (and far uglier).

This may be true of other file types as well, if they’re commonly recognized as lossy and computationally easy to re-compress.

I have read reports of T-Mobile and O2 doing this. I think it’s been noted with other cell providers, too.

There’s two possible fixes:

• Switching to HTTPS will fix this problem as the proxy will no longer be in the middle of the communication. If your resource is available via HTTPS, this is a fantastic and simple fix.
• Add a HTTP header to defeat this. The idea is to add a no-transform cache-control HTTP header to your request. This should disallow the server from making this kind of change. See RFC 2616, section 14.9.5.

Thanks to Tony Milllion for pointing out the HTTPS solution, and letting me know it affected O2 as well.

I haven’t been using github for long. That said, AFNetworking is the best-managed git project I’ve seen. It’s being managed so well that I wanted to write about it. In doing so, I’m not trying to praise Mattt Thompson’s efforts. It will probably come across that way, and he deserves it. Instead, I want to say that if you plan to maintain a git project, you should handle it as well as Mattt does.

Codebase

AFNetworking is, ultimately, a simple library. It has only a few classes, and reuses lots of the sane bits of iOS frameworks. Its main class is AFURLConnectionOperation, which encapsulates a NSURLConnection and its delegate methods in a subclass of NSOperation.

Without going into the gory details of Foundation framework classes, this is how iOS networking should work. Of course, you could get into a lot of trouble even with the right fundamentals. But AFNetworking doesn’t. It’s ten source files with headers, and one header to rope it all together.

Issues

As I write this, AFNetworking has 368 closed issues. 358 of them are closed. Alone, this tells you something: He responds to issues.

But if you watch how he handles issues, you’ll see qualities to which all developers should aspire:

1. Patience.
2. Humility.

His responses are available to everyone, of course. I came to appreciate how well Mattt was running the project by reading these. Along the way, I learned a lot about AFNetworking.

Pull requests

I have no idea what percentage of the code Mattt has written, vs. code brought in by other contributors. I can tell you that at the moment, AFNetworking has 99 pull requests total. 98 of these are closed. Whether they were merged or not, he’s dealt with them.

Some of these pull requests are pretty mundane. I’ve landed three myself, all very small and ordinary. However, in each case Mattt not only merged the request, but thanked me for it and explained what had happened. The thanks are appreciated. The explanation isn’t necessary, but gives me a better feeling of connectedness.

For the pull request that he didn’t accept, he explained what I was doing wrong (gently and politely), and provided me with an alternative that actually worked better than the pull request I’d made.

Looking through a few pull requests, I don’t see anything unusual about the way he treated me.

Conclusion

Look, I’m not saying Mattt Thompson is handling AFNetworking perfectly. That’d be impossible to prove, and you could probably prove otherwise pretty quickly. But he’s handling it well.

I’m also not going to claim the code is perfect. The library actually swizzles itself, which is one of the craziest things I’ve seen. But the craziness is localized to a small section of code, and minor overall.

I’m feeling connected to the project, I’m feeling confident, and I’m learning more about it. Even the bits I don’t care about yet. And if that isn’t a successful open source project, I’m not sure what is.

Although Objective-C supports exceptions, they’re not commonly used. A thrown exception is usually not caught, making it a fatal error.

The Objective-C Programming Language describes it thus:

Important In many environments, use of exceptions is fairly commonplace. For example, you might throw an exception to signal that a routine could not execute normally—such as when a file is missing or data could not be parsed correctly. Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors. Instead you should use the return value of a method or function to indicate that an error has occurred, and provide information about the problem in an error object. For more information, see Error Handling Programming Guide.

What, then, is the usual pattern for handling non-fatal errors. The answer is the NSError class, along with a few simple conventions:

1. Any method that can fail should return 0 (or an equivalent) on failure.
2. Any method that fails by returning 0 (or an equivalent) on failure should take a pointer to return a NSError instance, which it populates with error details.
3. If the error pointer is NULL, the method should not return an error.

For instance:

- (BOOL)doSomethingWithError: (NSError **)error {

    // other code
    NSError *e;
    if ( ![self bitWithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    return YES;
}

This seems pretty reasonable, but can get unmanageable quickly:

- (BOOL)doSomethingWithError: (NSError **)error {
    
    NSError *e;
    
    if ( ![self part1WithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    if ( ![self part2WithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    if ( ![self part3WithError: &e] ) {
        if (error) *error = e;
        return NO;
    }
    
    return YES;
}

Thankfully, blocks can simplify this for us!

- (BOOL)doSomethingWithError: (NSError **)error {

    BOOL(^fail)(NSError *e) = ^(NSError *e) {
        if (error) *error = e;
        return NO;
    };
    
    NSError *e;
    if ( ![self part1WithError: &e] ) return fail(e);
    
    if ( ![self part2WithError: &e] ) return fail(e);
    
    if ( ![self part3WithError: &e] ) return fail(e);
    
    return YES;
}

Using a fail block has a few advantages:

• You have a single place through which all errors in this method are routed. You can put a breakpoint here, or add logging.
• If you change what doSomethingWithError returns, you change just the return type of the block and the return within the block.
• You eliminate a lot of redundant code, therefore lessening the chance of an error in one of the copies.

Footnote: Usually, if I am writing an if statement, I’ll write it like this:

if (foo) {
    // statement
}

I do this even when it’s not necessary, because what if I expand on it later? And I think this is a good principle. But for a fail block like this, I’m never going to add an extra statement. The whole point of the block is to make sure that the failure code is a single statement.

What I’m going to cover:

• The basics of networking using NSURLConnection, part of Apple’s Foundation framework.

What I’m not going to cover:

• How to determine if a connection is available before trying a request. (Hint: Don’t.)
• How to retry an operation when a connection becomes available. (Hint: Reachability.)
• How to abstract this without losing anything important, and bring it all under control. (Hint: Use AFNetworking.)

All of these are topics I’ll write about in future articles. But today, just the basics!

Also, this code will assuming you’re using Automatic Reference Counting. Because you ought to be.

For any HTTP operation, you’re going to use NSURLConnection. It’s not safe to use synchronously from the main thread. This will cause the main thread to stop responding to user-level events, and iOS will quit your application. It behaves exactly as if your application crashed.

On Mac OS X, the system will not quit your application, though your application will become unresponsive and look like it’s frozen. So on Mac OS X, you should follow the same pattern of avoiding synchronous network requests on the main thread of your application.

That leaves three options:

1. Asynchronous networking on the main thread.
2. Synchronous networking on another thread.
3. Asynchronous networking on another thread.

Under normal circumstances, you don’t need to run networking operations on a different thread. There’s very few problems that require moving to another thread.

Using asynchronous operation will cause the networking itself to run in the background. You can consider this a dedicated thread by Apple. Your delegate methods will be called in the correct sequence on the main thread to catch up with networking as iOS determines it is appropriate.

Apple includes an example of how to use NSURLConnection in URL Loading System Programming Guide, Using NSURLConnection. It’s a short article, full of simple code examples. You should spend a few minutes to read this.

In a nutshell, here’s the pattern:

1. Keep a NSMutableData for your response data.
2. Clear the contents NSMutableData instance in connection:didReceiveResponse:. (You may receive multiple connection:didReceiveResponse: events as the request is redirected, but you should only use data from the last one.)
3. Append the data you receive from didReceiveData to the NSMutableData. Don’t try to process it immediately; you will usually receive multiple connection:didReceiveData: events for a single transfer.
4. In connectionDidFinishLoading:, your data is complete. Here, you can do something with it.

The idea here is that your start (or restart) accumulating data in connection:didReceiveResponse:, append data in your connection:didReceiveData:, and actually do something with the data in connection:connectionDidFinishLoading:.

Processing the data shouldn’t really be done on the main thread, either. You can start another thread, but it’s easier to just dispatch_async to a queue that isn’t running on the main thread.

It is possible to run an NSURLConnection on another thread, of course. That thread will need to be using a run loop to receive the delegate events from networking. But unless there’s some reason you need a separate thread, using asynchronous networking is Apple’s solution to this.

Using NSURLConnection requires a class member to accumulate data as its transferred. That means that if you’re going to have multiple simultaneous transfers, you’ll need something more complicated. Probably a wrapper class to drive NSURLConnection, and keep each response separate. By the time you’ve written this wrapper class, you’ve probably written a naive version of AFHTTPRequestOperation, a part of AFNetworking.

But we’ll get to AFNetworking in a future post.

Assuming you only have a single transfer going on at once, your code should look a bit like this:

- (void)doNetworkThing {

    NSURL *URL = [NSURL URLWithString: @"http://tewha.net/"];
    NSURLRequest *request = [[NSURLRequest alloc] initWithURL: URL];
    NSURLConnection *connection = [[NSURLConnection alloc]
                                   initWithURLRequest: request];

    receivedData = [[NSMutableData alloc] init]; // should be a class member
    [connection start];
}

- (void)connection:(NSURLConnection *)connection
didReceiveResponse:(NSURLResponse *)response {
    [receivedData setLength:0];
}

- (void)connection:(NSURLConnection *)connection
    didReceiveData:(NSData *)data {
    [receivedData appendData:data];
}

- (void)connection:(NSURLConnection *)connection
  didFailWithError:(NSError *)error {
    // do something with error here
}

- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
    dispatch_async(someQueue, ^{
        // do something that takes a long time with receivedData here
        dispatch_async( dispatch_get_main_queue(), ^{
            // access the UI here
        });
    });
}

See also:

• URL Loading System Programming Guide, Using NSURLConnection
• NSURLConnection Class Reference

Odds are, the compiler understands Objective-C and Cocoa better than you. I don’t mean this as an insult; it certainly understands it better than me. I think you could safely say it understands the rules better than all but maybe a dozen people worldwide. And it knows tricks to use them to a degree that you and I can’t repeat, even if we understood as well as it does.

The rest is just details, but they’re important:

1. You will write a lot less boring code. Code so boring it’s easy to make mistakes.
2. As a blended compile time and run time process, it has access to tricks that you don’t.
3. It will a better a job of writing memory management code than you can, even if you write the theoretical perfect memory management code.
4. It will reduce “high tide” memory usage (somewhat) without any effort on your part.

If you are starting a new application, stop thinking about it and just use it.

If you have an existing application, you need to think about it. You’re balancing the ease of future development vs. a need to re-test the app. The ARC conversion isn’t awful, but it isn’t painless or foolproof either. You will need to make sure you have no circular references, and you will need to make sure that objects don’t disappear sooner than you think.

If you have an existing application that targets iOS before iOS 5, zeroing weak references are not supported. You can find people who will tell you that zeroing weak references aren’t a big deal. They’re wrong. While it’s true you can use assign to prevent circular references, weak references are what turns ARC from a useful way to write less code to a fantastic way to write stable applications. You should seriously consider requiring iOS 5.

If you have an existing application that targets iOS before iOS 4, you can’t use it at all. What are you thinking, supporting a version of iOS that old?

See also:

• Transitioning to ARC: Apple’s ARC overview. A great overview, but possibly less than you need to know.
• Automatic Reference Counting: The living and detailed ARC specification and rationales. Certainly much more information than you require.

With HTTP status codes 302 and 303, the user agent (in this case, NSURLConnection) will change the request type from POST to GET. This is just how 302 was usually implemented; status code 303 was added to HTTP/1.1 to make this behaviour explicit.

HTTP/1.1 also added a status code to redirect without changing the request type from POST to GET. If you can change the web site, getting it to redirect you with a 307 instead will fix the problem.

If not, you can make NSURLRequest ignore this aspect of RFC2616.

NSURLRequest sends an event to its delegate, in which you can see what NSURLRequest plans to do and customize it:

- (NSURLRequest *)connection: (NSURLConnection *)connection
             willSendRequest: (NSURLRequest *)request
            redirectResponse: (NSURLResponse *)redirectResponse;
{
    if (redirectResponse) {
        NSMutableURLRequest *r = [[originalRequest mutableCopy] autorelease];
        [r setURL: [request URL]];
        return r;
    } else {
        return request;
    }
}

By doing this, you’re cloning the original request and changing the URL to match the request suggested by NSURLConnection (which is following the RFC).

See also:

• w3.org: RFC2616 HTTP/1.1, section 10: Status Code Definitions

After a couple years, I’ve come to adopt some very simple rules for memory management.

Concepts

The first step is to pick up a few concepts that will help you as you code.

• Be lazy in memory management. Rely on the compiler to do everything it possibly can. The compiler can synthesize property setters that handle memory management according to the rules you set. Rely on this.
• Ownership. Think in terms of ownership, rather than reference counting. Thinking in terms of ownership makes problems and solutions obvious. Thinking in terms of ownership will help you keep in mind the why of what you’re doing, rather than the what. After you’ve got a good grasp of why, the what becomes obvious.
• Protect your objects. Own any object that you want to keep around as long as self is around.
• Avoid circular references. Never own an object that could own self. This means never owning self’s delegate or data source.

Practical guidelines

But how does this translate to code? There’s a few specific and concrete things you can do to make this easier on yourself:

• Use properties to centralize memory management rules. Use @property to establish the rules for memory management of an instance variable. (And @synthesize your properties to underscored instance variables to prevent naming conflicts.)
• Pick the right memory management rule. Use retain properties as your default. Data sources, delegates or other objects that might own the object you’re working in should be assign properties instead of retain.
• Rely on the centralized memory management rules. Use property set notation (self.foo = nil;) or the property setter ([self setFoo: nil];) everywhere you change the property’s value except in the property’s setter (if you need one) In this way, you rely on the retain or assign in your @property to specify the memory management. If you need to use retain, release or autorelease outside of a setter you’re doing too much. (And, also, you’ll have more work to do to be compatible with ARC.)
• Avoid being called once deallocated. In dealloc, nil any delegates you’ve set to self. (This eliminates the possibility that the object will survive longer than self and try to send messages to self.)
• Protect your private bits, too. Don’t use raw instance variables in objects requiring memory management. Use anonymous properties.
• Containers own their contents. You not only don’t need to but must not try to manage memory in a system container. An NSArray will send a retain to objects that are added to it, and a release to objects as they are removed. If you try to manually retain and release objects, you’ll miss a case.
• Verify. Analyze your code frequently. And profile your code early and often for leaks.