a project which is iOS5 only and ARC enabled compiles on Xcode 4.3.1 beta. When compiling on 4.2.1. LLVM is throwing warnings like these:
"ARC forbids synthesizing a property of an Objective-C object with
unspecified ownership or storage attribute"
So the property definitions looks like this:
#property (nonatomic) NSObject* object
ARC is enabled in Build Settings. Adding a strong attribute fixes this warning but this should be default right?
Is there a difference between the Xcode versions in handling those property defaults?
Thanks
Andi
This is not beta specific Xcode 4.2.1 has the same behavior (betas are under NDA and should only legally be discussed in apple's developer forums):
Strong is the default setting for ivars. For ivars if you want __unsafe_unretained or __weak you must specify.
It has always been best practice to specify attributes in property declarations. One example that pops most quickly to mind is the UILabel property text, defined as:
#property(nonatomic,copy) NSString *text; // default is nil
In this example the copy attribute tells me I can pass an NSMutableString reference to the label and it will make a copy and I can go on mutating the string the label will remain the same. The behavior is clearly defined.
And I suspect it's the clearly defined behavior which was the most prominent reason that the ARC compiler forces you to specify storage attributes. Remember with the new runtimes eliminating the need to declare ivars for properties and #synthesize for accessor methods, it's conceivable that the property declaration is the only point you will notice if you accidentally retained a delegate.
Also consider the possibility that a few classes in a project may have been excluded from ARC in these cases there internal implementation would be completely opaque to ARC.
Related
I have an NSWindow which can be closed and reopened (I've called [setReleasedWhenClosed: NO]). How do I check if it is open or closed programmatically?
I've read the doc and Googled but can't see a sane way to do this. [isVisible] is deprecated. [occlusionState] isn't what I'm after. I've worked around it using notifications, but I can't believe there isn't some property or method on NSWindow to do this
-[NSWindow isVisible] is not really deprecated.
For the 10.10 SDK, Apple went through and converted a bunch of informal properties to declared properties. An informal property is one for which there are just accessors declared, possibly just a getter method. A declared property uses #property.
As a consequence, they removed something like:
- (BOOL) isVisible;
and added:
#property (getter=isVisible, readonly) BOOL visible;
Note that both still imply the existence of an -isVisible getter with BOOL return type.
The tools they use to generate the documentation from the changes to their headers caused the documentation to claim that -isVisible is deprecated, but that's just wrong.
Note, though, that -isVisible reports false for a window which is minimized or which is "open" but in a hidden app.
You make make of use of screen property of NSWindow. If the window in offscreen it will return nil. Please check https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/index.html#//apple_ref/occ/instm/NSWindow/screen
I've subclassed UITextField and added two variables and a convenience function. One variables holds a String key and the other holds a reference to another TextField which is used to create a custom tab order.
All good except I've run into a small problem. Using the storyboard I'm not able to bind the IBOutlet in the controller to the text field elements that implement this subclass even though they are both the same type. I've had to set the IBOutlet variable to be a UITextField type, bind them and then set the IBOutlet back to the subclass.
This all works in Xcode5 using Objective-C so I assume this is an issue with the beta of XCode6 but just wanted confirm I wasn't missing something.
I am also playing with swift.. I can share what I checked when faced some problems, you can check these. Not sure though it is the solution for your problem.
1. Check class defined for subclass and main class
2. Check delegates defined for text fields.
3. Check if prototyping can solve your problem.
Beta 2 Release of XCode 6 has resolved this issue.
I added ARC to an app I'm working on. Unfortunately, it crashes. I found that the automatic script which updates all apps to ARC gave __unsafe_unretained qualifier to all id< protocolName> type.
Why isn't it a weak type? I have deployed the app and all its sub-projects to iOS 5, and therefore I do have weak qualifiers.
My main problem is if I declare those delegates as strong, I'll have a retain-cycle. If I do not, the next time I call them they will be zombies. I checked and before my app crash, the delegate is NSZombie.
What is the cause of this crash and how can it be prevented?
The qualifiers __unsafe_unretained and week have quite a few things in common. They both won't increase the retain count for example. If for example a view controller holds an __unsafe_unretained IBOutlet to a UIView and you remove that very UIView from the view hierarchy, then you (given that you don't retain the view anywhere else) will decrease the retain count and most likely dealloc the UIView. The pointer however will still point to that location and is left dangling. Not nice but also not problematic if you know what happened. Weak properties help you avoiding dangling pointers by nullifying the property when the object gets to a retain count of 0.
Now, if your app crashes or the properties show up as zombies, then they are being released - by whichever class though.
One statement that is not entirely correct is that if you retain the property instead, you'll create a retain cycle. There is the possibility of creating retain cycles though but it really depends on your implementation, not just the property declaration. When you retain an object, you take ownership and until you're done with that object, prevent it from being deallocated by increasing its retain count. If your delegate gets released already while you hold a weak pointer, you won't prevent it from being released. I am assuming you deal with modal view controllers here - UIPopoverController to be precise (just a guess).
You should use instruments and look at the lifecycle of your object and see who retains/releases it. It could be helpful to know. Otherwise, you could paste some code and maybe there will be a nice person here to help you find the issue.
cheers
Ronny
Took some time but i solved it:
I deployed the .xcodeproj projects to iOS 5, but the targets were left in iOS 4.3 deployment. When i fixed it (it's in the 'build settings' for each target) - i could change all '__unsafe_unretained' to '__weak', and all 'unsafe_unretained' to 'weak'.
To avoid retain cycle those delegates should be weak, and they won't be zombies anymore (because they are weak and not unsafe_unretained), and the app won't crash anymore.
If i was still using iOS4.3-, and there isn't unsafe_unretained qualifer, i should only assign nil to those delegates after i don't need them anymore.
In xcode 4.2 I have found it very frustrating because you can't use:
-(void)dealloc {
[label release]; //'release' is unavailable
[super dealloc]; //'dealloc' is forbidden in automatic reference counting
}
Is there another way because autorelease and other deallocs don't work either.
Xcode 4.2 introduces "Automatic Reference Counting" (aka ARC). This is a compiler feature that basically inserts the retain and release calls for you. Under ARC, if you have a pointer to an object, you're retaining it. When your pointer goes out of scope, or is reassigned to point to another object, the original object is released. It's really nice.
So, in short, you just remove all the calls to retain, release, and autorelease, and the compiler will do the right thing for you.
Read up on Automatic Reference Counting. If you write your code properly, you don't need to do any of that anymore.
If you want to use old code without converting, disable ARC. put -fno-objc-arc in the compiler flags for any source modules you don't want to use ARC.
joe
I saw a similar question addressing differences of the code completion between Xcode 3.2 and Xcode 4. My question addresses a specific behaviour of Xcode (3.2).
When I declare "private" methods in a class extension, these methods are visible in the code completion lists, where they shouldn't be visible.
An example (AClass.m):
#import "AClass.h"
#interface AClass()
- (void)someMethod;
#end
#implementation AClass
//...
- (void)someMethod
{
// do something here
}
//...
#end
When I import AClass.h to some other class and create an AClass-instance...
AClass *test = [[AClass alloc] init];
Xcode's code-completion shows the "private" method "someMethod":
[test som // Shows someMethod, though it shouldn't be visible here
At that point, this method is visible, even if it shouldn't be, because it's unknown here - it's not defined in the header-file. If I send the message [test someMethod] at that point and build the thing, I get a warning, that the object might not respond - as expected.
It actually does respond, but this is confusing behaviour, especially for someone else, who wants to use my class.
That affects #property / #synthesize as well, since they "just substitute methods". I want to access all of my private ivars by properties for a) having homogene code while b) being able to influence the use of ivars (like lazy instantiation). On the other hand all private stuff shouldn't be visible (in code completion) to anyone using my classes, to make it easier to use them.
Is there any way to change this behaviour?
Is the missing validation of context in Xcode 3.2 the reason, why code-completion shows this kind of methods, where they shouldn't be visible?
Is that behaviour different in Xcode 4 (because of context-validation)?
I still use Xcode 3.2, because I wanted to finish a project before switching and adapting myself to Xcode 4.