When using ARC, you simply do not call [super dealloc] explicitly – the compiler handles it for you (as described in the Clang LLVM ARC document, chapter 7.1.2): – (void) dealloc { [observer unregisterObject:self]; // [super dealloc]; //(provided by the compiler) }
The capture of self here is coming in with your implicit property access of self.timerDisp – you can’t refer to self or properties on self from within a block that will be strongly retained by self. You can get around this by creating a weak reference to self before accessing timerDisp inside your block: __weak … Read more
Create a generic wrapper as: class Weak<T: AnyObject> { weak var value : T? init (value: T) { self.value = value } } Add instances of this class to your array. class Stuff {} var weakly : [Weak<Stuff>] = [Weak(value: Stuff()), Weak(value: Stuff())] When defining Weak you can use either struct or class. Also, to … Read more
Short answer Instead of accessing self directly, you should access it indirectly, from a reference that will not be retained. If you’re not using Automatic Reference Counting (ARC), you can do this: __block MyDataProcessor *dp = self; self.progressBlock = ^(CGFloat percentComplete) { [dp.delegate myAPI:dp isProcessingWithProgress:percentComplete]; } The __block keyword marks variables that can be modified … Read more
The primary memory-related problem you’ll still need to be aware of is retain cycles. This occurs when one object has a strong pointer to another, but the target object has a strong pointer back to the original. Even when all other references to these objects are removed, they still will hold on to one another … Read more
Both weak and unowned references do not create a strong hold on the referred object (a.k.a. they don’t increase the retain count in order to prevent ARC from deallocating the referred object). But why two keywords? This distinction has to do with the fact that Optional types are built-in the Swift language. Long story short … Read more
It helps not to focus on the strong or weak part of the discussion. Instead focus on the cycle part. A retain cycle is a loop that happens when Object A retains Object B, and Object B retains Object A. In that situation, if either object is released: Object A won’t be deallocated because Object … Read more
Surround each case itself with braces {}. That should fix the issue (it did for me in one of my projects).
My guess is that the compiler version you’re using follows the memory management rules for declared properties, too — more specifically, for declared properties’ accessors: You take ownership of an object if you create it using a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy”. A property named newTitle, when synthesised, yields a … Read more
Nonatomic Nonatomic will not generate threadsafe routines thru @synthesize accessors. atomic will generate threadsafe accessors so atomic variables are threadsafe (can be accessed from multiple threads without botching of data) Copy copy is required when the object is mutable. Use this if you need the value of the object as it is at this moment, … Read more