I use:
#property(nonatomic, weak) IBOutlet UIView *videoView;
there is a warning:
Property 'videoView' requires method 'videoView' to be defined - use #synthesize, #dynamic or provide a method implementation in this class implementation
Then I try:
#synthesize videoView;
there is an error:
The current deployment target does not support automated __weak references.
And another question:
#property(nonatomic, unsafe_unretained) IBOutlet UIView *videoView;
- (void)dealloc {
videoView = nil;
}
Can I use this way?
The current deployment target does not support automated __weak references.
The issue is that iOS 4.x doesn't support auto-zeroing weak references. This means that, when a weakly-referenced object is destroyed, the weak references continue to point to it and may cause crashes if used.
Auto-zeroing weak references are supported in iOS 5 and newer. To take advantage of them and clear the warning above, raise your minimum iOS target to 5.0, and use the 5.0 SDK.
What is your deployment target? you need to have at least iOS4 to have weak references, and you need to be using LLVM4 with Xcode4.4 or later to be able to just declare your #property variables and not have to provide an #synthesize.
As for the second question - what is it that you are trying to do. If you are just trying to safely set the variable to nil on dealloc, then it is okay, since you are declaring it as unsafe_unretained you don't own it so you shouldn't release it.
Related
I hate doing following
//in file.h
#property (strong) NSString *reuseIdentifier;
//in file.m
#synthesize reuseIdentifier = _reuseIdentifier;
This feels so redundant. I get the distinction of concepts between property in which is named "reuseIdentifier" and memory block that's named "_reuseIdentifier" but why can't the xcode IDE do the work by itself?
I feel like I am doing chores.
It's not been necessary to explicitly implement or synthesize Objective-C properties since Xcode 4.4 in 2012. See the Xcode 4.4 section of the archived "What's New in Xcode" documentation:
Objective-C #properties are synthesized by default when not explicitly implemented.
I have a class:
#interface MyClass : NSObject
#property (weak) id delegate;
#end
and the implementation:
#implementation MyClass
#synthesize delegate;
#end
When I refactor the code for ARC, it tells me that synthesize of 'weak' property is only allowed in ARC/GC mode. But from what I known, delegate can be 'weak' in ARC, also, if I change it to assign, then it will be converted to unsafe_unretained.
My question is, does it mean the code before conversion(to ARC) should NOT use anything ARC?
Thanks!
It sounds like you might be targeting iOS 4.x
4.x added ARC, but not the full ARC that iOS5+ got. iOS 4.x arc doesn't have support for the "weak" keyword, only unsafe_unretained. If you want to use weak instead of unsafe_retained you will have to drop iOS 4 support.
The difference between "weak" and "unsafe_unretained" is that weak will set itself to nil when it is released, where as unsafe_unretained will hang around pointing to bad (released) memory.
My project is ARC enabled (the build settings have Objective-C Reference Counting set to YES). There are no file exceptions to this, it is enabled project wide. (Latest stable version of Xcode).
When I create an NSManagedObject subclass via File > New for a Core Data entity, the generated header uses the following in its property declarations:
#property (nonatomic, retain)
But 'retain' is not ARC!! Is this a bug, or is there something I'm missing or not understanding? There are no build warnings - if this is a bug though, how can I remedy it?
retain is a synonym for strong. So it is perfectly valid to use retain or strong in this case.
For more detail check out this question.
retain is a valid property declaration in ARC: See the clang documentation on it
My app must support iOS 3.1.2
But it looks like __weak, __block and __unsafe_unretained are only for newer versions of iOS
Can someone show me an example of how to declare a weak reference in for iOS 3.1.2?
Should I just do:
#interface foo
{
SomeType* _bar
}
#property (nonatomic, assign) Sometype* bar;
#end
#implementation
#synthesize bar = _bar;
#end
Assign, as you have used it, is the same as unsafe_unretained.
As you noted, you cannot declare something as weak before iOS5 (which cleans up a reference for you).
So basically when you are using an assign reference just be careful to clear out any assign references when the object is slated to go away.
At this point there is no value in supporting iOS 3.x. You should convince whoever you are working for to move away from it, if only to use ARC. It will make lots of memory issues and potential crashes go away.
I'm a newbie to ObjC/Cocoa and Mac development in general, and toying with the basics.
The simplistic default template for a new Cocoa application in Xcode 4.2 on Lion looks like this:
// AppDelegate.h
#import <Cocoa/Cocoa.h>
#interface AppDelegate : NSObject <NSApplicationDelegate>
#property (assign) IBOutlet NSWindow *window;
#end
// Appdelegate.m
#import "AppDelegate.h"
#implementation AppDelegate
#synthesize window = _window;
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
// Insert code here to initialize your application
}
#end
I've been using that as a basis for various experiments. Reading up on Automatic Reference Counting (which the project is set to use)—this article, for example—I assumed that one could, perhaps even should replace the assign qualifier for NSWindow *window with weak, but that does not seem to be the case.
The app builds fine, but hangs during startup, with Thread 1: Program received signal: "EXC_BAD_INSTRUCTION" in AppDelegate.m on the line with #synthesize window = _window;.
Changing the qualifier to strong makes the program work, but I fail to see how it would make sense to go from assign to strong. I'd gotten the impression that the pairings for non-ARC/ARC are assign/weak and retain/strong.
A more experienced coder friend suggested that even if the weak qualifier causes window to be prematurely deallocated and some access attempt on it to fail, the exception should be EXC_BAD_ACCESS, not EXC_BAD_INSTRUCTION.
I'm obviously missing something here, but I have no idea what.
EDIT: After a closer look at the crash-time gdb output, the same friend pointed me to this article by Mike Ash that sheds some light on this. Due to reasons beyond my understanding, NSWindow and some other classes that override retain and release can't be the target of zeroing weak references. Interestingly, changing the property declaration to this works:
#property (unsafe_unretained) IBOutlet NSWindow *window;
...even though unsafe_unretained isn't mentioned in Apple's documentation for Declared Properties.
With that, a REVISED QUESTION:
What would be the proper way to go here? Stick to assign despite mentions around the web that it shouldn't be used with ARC? Go for strong? Keep using unsafe_unretained since it seems to work? Something else?
Conceptually, 'weak' is the correct qualifier for a top-level IBOutlet on OS X (iOS is another story). However, to create a proper weak reference that zeroes on deallocation requires cooperation from the Objective C runtime. Classes that override retain or release break this support and so you can't create a weak reference to them. UIWindow is one such class.
That's why the template uses 'assign'. Perhaps it should really use the synonym 'unsafe_unretained' if ARC is enabled. In either case you have a simple weak reference that is not zeroed.
Mike Ash's blog discusses the issue with some Cocoa classes.
Look for it in the middle part of the page: Friday Q&A ARC. Look/Search for the text that starts with "ARC's implementation of zeroing weak references..."
The problem is that some classes don't handle the zeroing weak references that __weak brings. The solution is to go with what the normal ARC templates provide assign.
Well, to answer the second question, even Apple's templates use assign for window when using ARC. So you may be safe for now. But your mileage may vary in the future.
Mike Ash has a very good explanation of what's going wrong here (search for "ARC's implementation"). The gist of it is that the NSWindow class specifically does not support weak referencing: apparently because it relies on overriding retain and release with its own implementations.
I expect there's a few more such gotchas scattered through the legacy Cocoa classes, and these don't appear to be documented yet - instead, you find out through a runtime error. (I expect this will become a compiler warning as well at some point.)