Is there a list of classes in iOS that can't be referred with a __weak pointer when using automatic reference counting (ARC)?
Apple's Transitioning to ARC Release Notes only lists Mac classes so far:
Which classes don’t support zeroing-weak references?
You cannot currently create zeroing-weak references to instances of the following classes:
NSATSTypesetter, NSColorSpace, NSFont, NSFontManager, NSFontPanel, NSImage, NSMenuView, NSParagraphStyle, NSSimpleHorizontalTypesetter, NSTableCellView, NSTextView, NSViewController, NSWindow, and NSWindowController. In addition, in OS X no classes in the AV Foundation framework support weak references.
Is there a similar list for UIKit classes or even iOS-specific classes in general?
Thanks.
If you try to form a weak reference to an object that doesn't support weak references, the program should die immediately. This is mentioned in the Objective-C Advancements in Depth video from WWDC 2011. So you should know immediately if you find a class that doesn't support them.
I'm pretty sure the lack of mention in Transitioning to ARC Release Notes means that all UIKit classes are safe. I'm not sure if the warning about AV Foundation classes applies to iOS or not. I tested creating a weak reference to AVCaptureSession on both iOS 5 and Lion and neither crashed. I tested creating a weak reference to an NSWindow on Lion and it crashed with the message cannot form weak reference to instance (0x102232ef0) of class NSWindow.
Related
I noticed than in OSX, the NSTextView cannot for a weak refference (if you try to link it weak, you will get)
Cannot form weak reference to instance (0x600000122da0) of class NSTextView. It is possible that this object was over-released, or is in the process of deallocation.
also the outlet from XCode is created as assign by default
Why there cannot be a weak reference? What can be the reason?
Check FAQ here Transitioning to ARC Release Notes:
Q:Which classes don’t support weak references?
A:You cannot currently create weak references to instances of the
following classes: NSATSTypesetter, NSColorSpace, NSFont, NSMenuView,
NSParagraphStyle, NSSimpleHorizontalTypesetter, and NSTextView.
etc.
Read the message carefully. Read past the word NSTextView. It tells you exactly why at this moment you cannot create a weak reference to the NSTextView. You just have to read it.
For example, while dealloc is running, you cannot create new weak references anymore because the object will be going away and all weak references will be set to nil. Trying to assign the object to a weak variable will keep that variable nil, even though the object is not nil (yet).
And this has nothing to do with NSTextView.
I am creating my first static Cocoa Library, and I have noticed a curious thing compared to when I work with Cocoa Applications: When I add an IBOulet to a view in a xib file, the property is made unsafe_unretained by default instead of weak.
Is there any harm done in changing unsafe_unretained to weak?
Thanks,
Michael Knudsen
It happened to me too. i believe that if you'll change it to weak, you won't be able to compile it, because this library (or inner sub libraries) are deployed to an old xcode, which only support unsafe_unretained, but not in weak.
you can change the deployment in the right sidebar.
I'm fairly new to ARC for iOS (and pretty new to iOS in general) and I have a few quick questions about ARC.
~ In a View Controller, if I do not have statements in my viewDidUnload() method setting my properties to nil, will the properties' memory still be freed when my view controller is released? If so, why do I need to explicitly have this viewDidUnload method?
~ In objects that are not View Controllers, where should I set the properties to nil at? In dealloc? What about primitive properties such as #property BOOL isActive;...do I need to set them equal to nil/zero?
Thanks.
You don't need to set your properties to nil as long as they're weak references. IBOutlets should generally be weak references, since they the view controller contains a strong reference to the view, which in turn contains strong references to all of its subviews. (If you have IBOutlets that aren't part of that view hierarchy, they should be strong.)
You shouldn't need nil or zero anything, objects or scalars. Xcode will insert nilling statements when working with Interface Builder, but this is it still generating code for pre-ARC Objective-C.
You probably don't even need a viewDidUnload; it's only called in special circumstances, when there's low memory stress. Thus, you can't depend on it for cleaning up. Your IBOutlets should be weak, so they'll be cleaned automatically when the view is purged from the viewcontroller (and they'll be restored if the view is reloaded).
I'm assuming here that you're writing a new product, which means you're targeting iOS 5 or later only. If you're targeting iOS 4 in a new product, you really shouldn't be. The world has moved on, with 80% of the market on iOS 5 or later. And that's today. Going forward, it's going to be even harder to avoid iOS 5 features for an even smaller percentage of people.
Memory management for #properties is handled automatically under ARC. For times when you have set yourself as delegate, it is common to set the delegate to nil before going away (in viewWillDisapear for instance) so that future calls to delegate don't reference garbage. Stay tuned for the soon-to-be-posted WWDC videos for the latest guidance.
In viewDidUnload you need to set outlet references to nil, because ARC will release them and you do not want to accidentally use them after that happens.
You don't have to do anything with properties, they will be handled automatically. In fact you really do not normally even have a dealloc method any more with ARC.
I have a property that looks like this:
#property (weak, nonatomic) id<NavigationControllerDelegate> delegate;
But when I run my app I get the following error:
objc[4251]: cannot form weak reference to instance (0x101e0d4b0) of class TabBarController
The only reason I can get from google for this error is that you get it when you try to form a weak reference to an object that overrides retain/release/dealloc, which I am not. My TabBarController is inheriting from NSViewController.
Anyone knows what might cause this? It works if I use "assign", but obviously I'd prefer to use "weak".
According to Apple's Transitioning to ARC Release Notes,
You cannot currently create weak references to instances of the following classes:
NSATSTypesetter, NSColorSpace, NSFont, NSMenuView, NSParagraphStyle, NSSimpleHorizontalTypesetter, and NSTextView.
Note: In addition, in OS X v10.7, you cannot create weak references to instances of NSFontManager, NSFontPanel, NSImage, NSTableCellView, NSViewController, NSWindow, and NSWindowController. In addition, in OS X v10.7 no classes in the AV Foundation framework support weak references.
(Note: one needs to be very careful with nonzeroing weak references...)
i am getting an NSInvalidArgumentException with reason: -[UITapGestureRecognizer initWithCoder:]: unrecognized selector sent to instance
my understanding was that UITapGestureRecognizers were supported in ios4.x?
is it possible to load a different xib file for sub ios5 versions?
As #mit3z states in his comment on the original question, iOS 4.3 supports this feature only when setup up manually with code. It is not supported with Interface Builder.
Apple would have saved us all grief over this if they simply added this as a build-time warning.
I think you have a NSCoding compliant object that is deallocated before the crash. The UITapGestureRecognizer is allocated at its address and when the disappeared object (but not its reference) tries to call initWithCoder on itself, it actually calls this method on your gestureRecognizer instead.
Then your problem comes from that deallocated object but not from your gestureRecognizer.
Be sure to retain all your IBOutlet properties.