Beginning ARC in iOS 5 Tutorial Part 1

http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-part-1

ARC is a feature of the new LLVM 3.0 compiler and it completely does away with the manual memory management that all iOS developers love to hate.

 

strong and weak

By default all instance variables and local variables are strong pointers.

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

__weak NSString *weakName = self.textField.text;

If the text field contents change, then the string object no longer has any owners and is deallocated: ,the value of weakName automatically becomes nil. It is said to be a “zeroing” weak pointer

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

An example of this is the delegate pattern. Your view controller may own a UITableView through a strong pointer. The table view’s data source and delegate pointers point back at the view controller, but are weak.

 

ARC is great and will really remove a lot of clutter from your code. You no longer have to think about when to retain and when to release, just about how your objects relate to each other. The question that you’ll be asking yourself is: who owns what?

 

Automatic Reference Counting also has a few limitations. For starters, ARC only works on Objective-C objects. If your app uses Core Foundation or malloc() and free(), then you’re still responsible for doing the memory management there

 

If you keep holding on to all the objects you’ve ever created, then ARC will never be able to release them. Therefore, whenever you create a new object, you still need to think about who owns it and how long the object should stay in existence

 

Fortunately you can combine ARC with non-ARC code in the same project

employ the automatic conversion tool. The tool will compile the app in ARC mode and rewrites the source code for every error it encounters, until it compiles cleanly.

LLVM 3.0 compiler            Core Foundation objects (that’s what the CF stands for

ARC readiness issue

The strong keyword means what you think it does. It tells ARC that the synthesized ivar that backs this property holds a strong reference to the object in question

 

One of the things I love about ARC is that in most cases it completely does away with the need to write dealloc methods. When an object is deallocated its instance variables and synthesized properties are automatically released.

Under ARC you are not allowed to call release, nor [super dealloc]. You can still implement dealloc — and you’ll see an example of this later — but it’s no longer necessary to release your ivars by hand.

 

Any time you return an object from a method whose name doesn’t start with alloc, init, copy, mutableCopy or new, the ARC compiler will autorelease it for you.??

 

only the call to [super dealloc] was removed. You are no longer allowed to call super in your dealloc methods.

 

At the top of SVProgressHUD.m you’ll find a so-called “class extension”,  The declaration of a class extension looks like that of a category but it has no name between the () parentheses. Class extensions can have properties and instance variables, something that categories can’t, but you can only use them inside your .m file.

The cool thing about class extensions is that they allow you to add private properties and method names to your classes.

 

As we’ve seen before, retain properties will become strong properties

 

“Receiver type ‘X’ for instance message is a forward declaration”
“Switch case is in protected scope”

“A name is referenced outside the NSAutoreleasePool scope that it was declared in”

“ARC forbids Objective-C objects in structs or unions”