automatic-ref-counting | 易学教程

What is the proper way to avoid Retain Cycle while using blocks

阅读更多关于 What is the proper way to avoid Retain Cycle while using blocks

问题 What is the proper way to add objects in NSMutableArray which is strongly defined by property. [tapBlockView setTapBlock:^(UIImage* image) { [self.myImageArray addObject:image]; // self retain cycle } If I will create weak reference something like __weak NSMutableArray *array = self.myImageArray; [tapBlockView setTapBlock:^(UIImage* image) { [array addObject:image]; // If I will do this then how will I update original Array ? } I have also tried __weak id weakSelf = self; [tapBlockView

ARC forbids explicit message send of 'retain' issue

阅读更多关于 ARC forbids explicit message send of 'retain' issue

问题 I'm using this very simple code from the Apple Guide: NSMutableData *receivedData; // Create the request. NSURLRequest *theRequest=[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://www.apple.com/"] cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:60.0]; // create the connection with the request // and start loading the data NSURLConnection *theConnection=[[NSURLConnection alloc] initWithRequest:theRequest delegate:self]; if (theConnection) { // Create the NSMutableData

@property definitions with ARC: strong or retain?

阅读更多关于 @property definitions with ARC: strong or retain?

Using Xcode 4.2 and ARC, I notice that the auto-generated code for an NSManagedObject still reads like this for properties: @property (nonatomic, retain) NSString * someString; 1) Shouldn't retain now be replace with strong or weak ? 2) Why does the auto-generated code still use retain 3) What is the correct replacement for retain in this property statement? I'm currently debugging a problem using NSFetchRequest , and I thought this might be the source of the problem. Thoughts? 1) Shouldn't retain now be replace with strong or weak? No. You cannot replace retain with weak; they are different.

Static library with ARC support linked to non-ARC project causing linker errors

阅读更多关于 Static library with ARC support linked to non-ARC project causing linker errors

问题 I have a non-ARC project that uses an ARC-enabled static library. This is a supported scenario, so that everything works fine. That is, until I run the code on a 4.x device, including the Simulator. In that case the code blows up with the following linker error: dyld: lazy symbol binding failed: Symbol not found: _objc_storeStrong Referenced from: /Users/zoul/Library/Application Support/iPhone Simulator/4.3.2/Applications/…/Demo.app/Demo Expected in: /Developer/Platforms/iPhoneSimulator

AutoLayout: removeFromSuperview / removeConstraints throws exception and crashes hard

阅读更多关于 AutoLayout: removeFromSuperview / removeConstraints throws exception and crashes hard

We use auto layout constraints selectively, primarily to position labels in relation to editable field elements (UITextView, UITextField, typically). However, since implementing auto layout for these fields, we're seeing a nasty exception and crash whenever we're unloading views, deallocating, etc. The exceptions are happening as it's attempting to remove the constraints from a view before unloading it. Our view/controller hierarchy is as such: UITableViewController (plain style, but with cell appearance to mimic grouped style) --> UITableViewCell ----> UIViewController (container for editable

Is it ever Ok to have a 'strong' reference for a delegate?

阅读更多关于 Is it ever Ok to have a 'strong' reference for a delegate?

问题 I have a class that retrieves JSON from a URL and returns the data via the protocol/delegate pattern. MRDelegateClass.h #import <Foundation/Foundation.h> @protocol MRDelegateClassProtocol @optional - (void)dataRetrieved:(NSDictionary *)json; - (void)dataFailed:(NSError *)error; @end @interface MRDelegateClass : NSObject @property (strong) id <MRDelegateClassProtocol> delegate; - (void)getJSONData; @end Note that I'm using strong for my delegate property. More about that later... I am trying

Singleton with ARC

阅读更多关于 Singleton with ARC

问题 My question is the following: I have a singleton type object (I'm using ARC) that has this code in the implementation file +(id)sharedInstance { static DataManager *sharedInstance; if (sharedInstance == nil) { sharedInstance = [[DataManager alloc] init]; } return sharedInstance; } +(NSManagedObjectContext *)getManagedContext { AppDelegate *applicationDelegate =(AppDelegate *)[[UIApplication sharedApplication] delegate]; return [applicationDelegate managedObjectContext]; } +(void)saveContext:

Cocoa blocks as strong pointers vs copy

阅读更多关于 Cocoa blocks as strong pointers vs copy

问题 I did work several times with blocks as with pointers to which i had strong reference I heard that you should use copy, but what is the implication in working with blocks as pointers and not with the raw object? I never got a complain from the compiler, that i should not use @property (nonatomic, strong) MyBlock block; but should use @property (nonatomic, copy) MyBlock block; as far as i know, the block is just an object, so why to preferrer copy anyway? 回答1: Short Answer The answer is it is

How to enable/disable ARC in an xcode project?

阅读更多关于 How to enable/disable ARC in an xcode project?

问题 If a project has already been created with ARC disabled, how do I enable it and vice versa? 回答1: Open your project and select Edit -> Refactor -> Convert to Objective-C ARC. This will start checking your code if it is ready for the conversion. Good link to read: Everything you need to know about automatic reference counting (ARC) How to disable ARC has been answered here 回答2: Following are the steps which I did and it worked for me Select Project Select Targets From the right panel, select

Do I set properties to nil in dealloc when using ARC?

阅读更多关于 Do I set properties to nil in dealloc when using ARC?

问题 I am trying to learn Automatic Reference Counting in iOS 5. Now the first part of this question should be easy: Is it correct that I do NOT need to write explicit release-property statements in my dealloc when using ARC? In other words, is it true that the following does NOT need a explicit dealloc? @interface MyClass : NSObject @property (strong, nonatomic) NSObject* myProperty; @end @implementation MyClass @synthesize myProperty; @end My next and more important question comes from a line in