retain-cycle | 易学教程

Retain cycle when grabing values or keys from Dictionary in Swift

阅读更多关于 Retain cycle when grabing values or keys from Dictionary in Swift

问题 When I grab values from a Dictionary and put them into Array, I can't release memory any more. I tried to remove all object from Array and Dictionary, but these object still exist somewhere (deinit were not called). I was playing in the following way: class MyData { let i = 0 init () { NSLog("Init") } deinit { NSLog("Deinit") } } var myDictionary:Dictionary<String, MyData> = ["key1":MyData(), "key2":MyData()] // Init was called twice // here is the problem: extract values from Dictionary var

Objective-C / Blocks - Isn't this a retain cycle?

阅读更多关于 Objective-C / Blocks - Isn't this a retain cycle?

问题 @interface ClassA : NSObject @property (strong, nonatomic) dispatch_queue_t dispatchQ; @property (strong, nonatomic) NSString *string; @end @implementation ClassA - (id)init { self = [super init]; if (self) { _dispatchQ = dispatch_queue_create("com.classa.q", NULL); } return self; } - (void)longRunningTaskWithCompletion:(void(^)(void))completion { dispatch_async(self.dispatchQ, ^{ for (int i = 0; i < 10000; i++) { NSLog(@"%i", i); } dispatch_sync(dispatch_get_main_queue(), ^{ self.string = @

How does UIView prevent retain cycle?

阅读更多关于 How does UIView prevent retain cycle?

Subview has a reference to superview, while superview also has reference (subviews) to subview. I'm wondering why this doesn't cause retain cycle? UIView 's superview property is declared as @property(nonatomic, readonly) UIView *superview; In Objective-C, properties declared without a different ownership specifier are assign by default strong by default as of the introduction of ARC, however, the UIKit headers appear to not be using ARC, so this property is most like assign . Note also, since the property is readonly, there is most likely a custom getter in the source, so the ownership

What is the reason of @strongify

阅读更多关于 What is the reason of @strongify

问题 In ReactiveCocoa there is macro to prevent retain cycle @weakify and @strongify. From my understanding @weakify do something like what I usually do that is create __weak reference for using in the block, but what about @strongify ? Why do I need to make it strong again in the block? Here is some sample usage: @weakify(self); [RACObserve(self, username) subscribeNext:^(NSString *username) { @strongify(self); [self validateUsername]; }]; 回答1: If you just use a weak reference within the block,

Is cleaning up strong references in deinit a correct pattern?

阅读更多关于 Is cleaning up strong references in deinit a correct pattern?

There are several resources ( blog , SO question , plus I've seen it used everywhere) that recommend removing an observer from the NotificationCenter in the deinit of the UIViewController , e.g.: deinit { NotificationCenter.default.removeObserver(self, name: NSNotification.Name.UIKeyboardWillShow, object: nil) NotificationCenter.default.removeObserver(self, name: NSNotification.Name.UIKeyboardWillHide, object: nil) } Now while according to another blog entry I don't have to care about removing an observer from NotificationCenter since it uses weak references, I've seen the same pattern used

What is the reason of @strongify

阅读更多关于 What is the reason of @strongify

In ReactiveCocoa there is macro to prevent retain cycle @weakify and @strongify. From my understanding @weakify do something like what I usually do that is create __weak reference for using in the block, but what about @strongify ? Why do I need to make it strong again in the block? Here is some sample usage: @weakify(self); [RACObserve(self, username) subscribeNext:^(NSString *username) { @strongify(self); [self validateUsername]; }]; If you just use a weak reference within the block, self can get deallocated while the block is being executed. But if you want to ensure that self stays in

Core Data - break retain cycle of the parent context

阅读更多关于 Core Data - break retain cycle of the parent context

问题 Let's say we have two entities in a Core Data model: Departments and Employees. The Department has a one-to-many relationship to Employees. I have the following ManagedObjectContexts: - Root: connected to the Persistent Store Coordinator - Main: context with parent Root When I want to create an Employee I do the following: - I have a Department in the Main context - I create an Employee in the Main context - I assign the Department to the Employee's department property - I save the Main

Can't make weak reference to closure in Swift

阅读更多关于 Can't make weak reference to closure in Swift

问题 Update: I tried writing it without making it weak, and there doesn't seem to be a leak. So maybe the question is no longer necessary. In Objective-C ARC, when you want to have a closure be able to use itself inside of the closure, the block cannot capture a strong reference to itself, or it will be a retain cycle, so instead you can make the closure capture a weak reference to itself, like so: // This is a simplified example, but there are real uses of recursive closures int (^fib)(int); _

substituting for __weak when not using ARC

阅读更多关于 substituting for __weak when not using ARC

I have this line of code: __weak NSBlockOperation *weakOperation = operation; which is triggering this compiler error: __weak attribute cannot be specified on automatic variable. Reason for this is I don't have ARC enabled (not ready to make the switch just yet). So from another StackOverFlow question, I was recommended to use: __unsafe_unretained NSBlockOperation *weakOperation = operation; Which makes the error go away, but for the context I'm using it, it's not working (see this question if interested: How to cancel NSOperationQueue ). So my question is, what I can substitute the __weak

Swift Memory Management: Storing func in var

阅读更多关于 Swift Memory Management: Storing func in var

I'm looking for the best practice for storing functions as variable in other objects. Specifically, I'm looking to avoid retain cycles inherent in capturing self in the function. Coming from objective-c and blocks, I would normally do something like this: __weak id _self = self; iVar.someBlock = ^{ [_self doSomething]; }; Of course, the iVar class would copy the block and store it. No retain cycle exists because I've capture __weak id _self . In Swift, I'm a little less certain, especially since I can pass class functions/methods. So, let's say in the iVar class I have: class iVarClass { var