Miscellanies of iOS 3) Managing Memory with ARC

pp101 

Not just copy and paste anymore...              For the usage of review

1. All Objective-C Objects are stored in a part of memory called the heap. When we send an alloc message to a class, a chunk of memory is allocated from the heap. This  chunk includes space for the object's instance variables. 

2. There is another part of memory called the stack that is separate from the heap. The reason for the names heap and stack has to do with how we visualize them. The heap is a giant heaping mess of objects, and we use pointers to remember where those objects are stored within the heap. The stack, on the other hand, can be visualized as a physical stack of frames. 

When an application launches and runs the main function, the frame for main is put at the bottom of the stack. When main calls another method or function....

3. Pointer Variables and Object Ownership

! Pointer variables convey ownership of the objects that they point to.

a) When a method or function has a local variable that points to an object, that method is said to own the object being pointed to.

b) When an object has an instance variable that points to another object, the object with the pointer is said to own the object being pointed to.

4. The idea of object ownership help us determine whether an object should be destroyed.

a) An object with no owners should be destroyed. An ownerless object cannot be sent messages and isolated and useless to application. Keeping it around wastes precious memory. This is called a memory leak.

b) An object with at least one owner must not be destroyed. Sending messages to an object that no longer exists will crash your application. This is premature deallocation.

5. Automatic Reference Counting in iOS 5 or later version

    Manual Reference Counting before

dont need to keep track of who owns whom and what pointers still exist.

6. How objects lose owners       pp109

a) A variable that points to the object is changed to point to another object.

b) A variable that points to the object is set to nil.       (The object used to be pointed to loses an ownership)

c) A Variable that points to the object is itself destroyed. ?

When a pointer variable itself is destroyed, the object that the variable was pointing at loses an owner. At what point a pointer variable will get destroyed depends on whether it is a local variable or an instance variable.

Recall that instance variables live in the heap as part of an object. When an object gets destroyed, its instance variables are also destroyed, and any object that was pointed to by one of those instance variables loses an owner. 

Local variables live in the method's frame. When a method finishes executing and its frame is popped off the stack, any object that was pointed to by one of these local variables loses an owner.

7. NSObject implements -(void)dealloc method

by setting items = nil;                (dealloc)

At the end, there are no more objects taking up memory, and only the main function remains. All this automatic clean-up and memory recycling occurs simply by setting items to nil. That's the power of ARC.

8. Strong and Weak References      

Under ARC, an iVar will be strong reference to an object by default.

For object types, the default has changed. The compiler is smart enough to know that, if I have a property that is an object, it should be strong, not assign.

For non-ARC, the assign is the default, which is the same as __unsafe_unretain in ARC

So far, we've said that anytime a pointer variable stores the address of an object, that object has an owner and will stay alive. This is known as a strong reference. However, a variable can optionally not take ownership of an object it points to. A variable that does not take ownership of an object is known as a weak reference. 

A weak reference is useful for an unusual situation called a retain cycle. A retain cycle occurs when two or more objects have strong references to each other.  They will never be destroyed by ARC.  cause a memory leak      pp112

p114

To declare a variable as a weak reference, we use the __weak attribute. 

__weak BNRItem *container;

Every retain cycle can be broken down into a parent-child relationship. A parent typically keeps a strong reference to its child, so if a child needs a pointer to its parent, that pointer must be a weak reference to avoid a retain cycle.          so does the parent's parent

9. An interesting property of weak references is that they know when the object they reference is destroyed. 

10. __unsafe_unretained attribute, like a weak reference, but it does not take ownership of the object it points to. Unlike a weak reference, an unsafe unretained reference is not automatically set to nil when the object it points to is destroyed. 

this is for the backward compatibility: application prior to iOS 5.

11. When you declare a property, you are implicitly declaring a setter and a getter for the instance variable of the same name. ? not _pname?

12 nonatomic property attribute is not the default option, so, explicitly declare it.

13. A readwrite property declares both a setter and getter, and a readonly property just declares a getter. And the readwrite is the default.

14.  The third attribute of a property describes its memory management. The default option is assign, which is for properties like int. pp117

15. synthesize the property and override for our own version of getter and setter if needed.

16. If there is no instance variable that matches the name of a synthesized property, one is automatically created.

17. copy property attributes

@property (nonatomic,copy)NSString *itemName;

-(void)setItemName:(NSString *)str
{
	itemName = [str copy];
}

in terms of ownership, copy gives you a strong reference to the new object pointed to. The original object is not modified in any way: it doesn't gain or lose an owner, and none of its data changes.