iOS5 automatic reference counting (ARC)

ARC is a feature of the new LLVM compiler, it avoids memory management problems completely by automatically inserting the proper retains and releases for you.

It is important to realize that ARC is a feature of the Objective-C compiler and therefore all the ARC stuff happens when you build your app. ARC is not a runtime feature (except for one small part, the weak pointer system), nor is it *garbage collection* that you may know from other languages.

Reference counting:

• retain: +1 retain count (claim ownership)
• release: -1 retain count (revoke ownership)
• autorelease: ownership is transfered to latest autorelease pool on the current thread
• when retain count reaches 0, the object is deleted

with ARC, you ignore all of this.

new rules:

You cannot explicitly invoke dealloc, or implement or invoke retain, release, retainCount ,or autorelease.

the prohibition extends to using @selector(retain), @selector(release), and so on.

You may implement a dealloc method if you need to manage resources other than releasing instance variables.

You do not have to (indeed you cannot) release instance variables, but you may need to invoke [systemClassInstance setDelegate:nil] on system classes and other code that isn't compiled using ARC.

Custom dealloc methods in ARC do not require a call to [super dealloc] (it actually results a compiler error). The chaining to super is automated and enforced by the compiler.

You can still use CFRetain, CFRelease, and other related functions with Core Foundation-style objects.

You can not use NSAllocateObject or NSDeallocateObject.

You create objects using alloc, the runtime takes care of deallocating objects.

You can not use object pointers in c structures, rather than using a struct, you can create an objective-c class to manage the data instead.

There is no casual casting between id and void *;

You must use special casts that tell the compiler about object lifetime. You need to do this to cast between objective-c objects and core foundation types that you pass as function arguments.

Cannot use NSAutoreleasePool objects, ARC provides @autoreleasepool blocks instead. These have an advantage of being more efficient than NSAutoreleasePool.

You cannot use memory zones, there is no need to use NSZone any more, they are ignored by modern Objective-C runtime anyway.

To allow interoperation with manual retain-release code, ARC imposes some constraints on method and variable naming:

You cannot give a property a name that begins with new.

 

The new rules you have to learn for ARC are quite simple. With manual memory management you needed to retain an object to keep it alive. That is no longer necessary, all you have to do is make a pointer to the object. As long as there is a variable pointing to an object, that object stays in memory. When the pointer gets a new value or ceases to exist, the associated object is released. This is true for all variables: instance variables, synthesized properties, and even local variables.

There is also a “weak” pointer. Variables that are weak can still point to objects but they do not become owners:

You probably won’t use weak pointers very much. They are mostly useful when two objects have a parent-child relationship. The parent will have a strong pointer to the child — and therefore “owns” the child — but in order to prevent ownership cycles, the child only has a weak pointer back to the parent.

Summary

ARC does a lot of stuff for you. Just write your code and trust ARC to do the right thing.

If you write C code, then you actually have to do some work.

 

• strong. This is a synonym for the old “retain”. A strong property becomes an owner of the object it points to.
• weak. This is a property that represents a weak pointer. It will automatically be set to nil when the pointed-to object is destroyed. Remember, use this for outlets.
• unsafe_unretained. This is a synonym for the old “assign”. You use it only in exceptional situations and when you want to target iOS 4. More about this later.
  copy. This is still the same as before. It makes a copy of the object and creates a strong relationship.
• assign. You’re no longer supposed to use this for objects, but you still use it for primitive values such as BOOL, int, and float.

old way-->ARC way

@autoreleasepool {
NSAutoreleasePool * pool = [NSAutoreleasePool new];

NSArray * comps = [NSArray arrayWithObjects:@"BYU",@"CocoaHeads",nil];

NSString * path = [NSString pathWithComponents:comps];

NSURL * url =[[NSURL alloc] initWithPath:path];

//do something with url

[url release];

[pool drain];

}//automatic drain

strong vs weak

With ARC , the only thing you have to consider are the qualifiers strong or weak.

The strong qualifier is set by default, with this qualifier you are instructing compiler that you would like to retain an object for the current event cycle.

You can still use retain, however it is recommended that you use strong instead.

The weak qualifier also known as a zeroing weak reference, instructs the compiler that you do not need to retain the object. And if all the references to this object go down to zero then the object is released and set to nil. This is important because a message sent to a nil object does not causes a crash, it simply doesn't do anything.

You can still use assign, however it is recommended that you use weak instead because it will send a deallocated object to nil.

A weak qualifier is especially used in a parent child object relationship, when the parent has a strong reference to a child object. And the child object a weak reference back to parent otherwise you will end up creating a circular reference.

 

                           --strong ---to detail view--> 

MyViewController <-weak datasource property-- DetailViewController

                          <-weak delegate property-- 

 

Weak is the recommended relationship for all *outlet* properties. These view objects are already part of the view controller’s view hierarchy and don’t need to be retained elsewhere. The big advantage of declaring your outlets weak is that it saves you time writing the viewDidUnload method.