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.
Related
I'm struggling to get an existing ARC-enabled control to run under Xcode 4.2 (OSX Snow Leopard), in a non-ARC-enabled project, and I'm facing various issues :
How should I fix the following issues ?
Use of (strong) in properties
Use of (nonatomic) in properties
Instance methods not found (not having being declared in the interface)
Enable new-style Objective-C
Also, it seems to be complaining about NSScrollerKnobStyle not being defined. Is it a 10.8-to-10.6 SDK-specific issue?
P.S. The control I'm using is ITSidebar
You're going to have to change those strong properties to retain or copy, as appropriate. There's nothing wrong with nonatomic in non-ARC code.
You may have to add #synthesize directives for your properties to get the compiler to add accessor methods. #synthesize is the default in the latest compiler.
There ae a number of other changes to the language, such as object literals. They're all well documented; you just need to apply them in reverse.
I'm not sure about NSScrollerKnobStyle, but if you look it up the documentation will tell you when it was introduced.
I'm playing around with Julius Guzy's sample code for creating a document based application that can save text files. I ran his code and it works perfectly and the app runs/save files (All in the latest version of Xcode. Though Guzy's sample code compiles using the 10.6 SDK). I'm trying to learn from it and rewrite the code. I have everything in order to compile the app but for the strangest thing in MyDocument.m. I am unable to run it.
#synthesize nsTextViewObj;
Xcode is giving me this error, which I don't really understand it.
Existing ivar 'nsTextViewObj' for property 'nsTextViewObj' with
assign attribute must be __unsafe_unretained
nsTextViewObj; is suppose to be linked to the "File Owners" in IB. I did that in the first place. It beats me why I'm getting that error. SDK conflicts maybe? How can I fix this?
ARC requires some changes to the code. Xcode provides a tool to automatically convert non-ARC code to ARC: Edit / Refactor / Convert to Objective-C ARC…
The Xcode tool is a good start, still I would recommend you to read Transitioning to ARC Release Notes.
I don't know Julius Guzy's code, but probably you should change it to something like:
#interface ifc_name : NSWindowController {
NSTextView *__unsafe_unretained nsTextViewObject;
}
#property (unsafe_unretained) NSTextView *nsTextViewObject;
As the name implies, unsafe_unretained is not safe: when the object is deallocated, your reference is invalid. If you are deploying only to iOS 5 or higher, and OS-X 10.7 or higher, you can use weak instead. With weak your reference will become zero when the object is deallocated.
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.
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.
i am currently starting to learn Xcode and objective-c and i am reading three different books on that topic currently. All of these books refer to a file called "AppDelegate" (My_First_ProjectAppDelegate.m, My_First_ProjectAppDelegate.h) which are said to be "created with the Project" (i am creating a "Cocoa Application"). These files are not present when I create a new Project. I seem to be not the only one having this problem (see http://pragprog.com/titles/dscpq/errata ).
Is there any more information about AppDelegate? What is the current practice on how to deal with a missing Appdelegate? i am using Xcode Version 3.1.4 on Mac OSX Leopard.
AppDelegate is nothing more than a common NSObject class with needed connections in MainMenu.xib. You can easily recreate your own:
Create a class, name it AppDelegate
Open MainMenu.xib and add NSObject object to object palette
In object inspector's Identity tab (the last one) set object's class to AppDelegate (you should get autocomplete)
Ctrl+drag from Application object to your newly created AppDelegate object and choose "delegate" from opened panel.
As I recall, only the iPhone templates were providing delegate classes by default. This is not a huge deal, but I can see how you would be concerned if you are just learning. Are you sure what you are reading is relevant to MacOS applications and not Iphone?
You can always create your own delegate class manually. You just create a class as you normally do, then set it as the delegate for NSApplication in Interface Builder.
I think the confusion comes from the version of XCode you are using.
Xcode version 3.2 changed the default behavior when you create a new project: it now creates an AppDelegate for your project. I can't remember what the earlier versions did, but it was different.
As Eimantas says, if you want to use an AppDelegate then you can just create one following the steps he describes.