I have a project with ARC but I disable it and now I have problem with properties as:
#property (weak, nonatomic) IBOutlet UIView *frame;
now I have an error for "weak", what kind I can replace? retain?
thanks
The closest thing to weak under manual reference counting is assign. Keep in mind, that unlike weak under ARC, the value of assign properties is not automatically zeroed when the instance pointed to by the property is deallocated. So, you need to be careful to discard assign references to objects before they're deallocated.
Why did you disable ARC?
You should replace it with assign. And strong with retain. retain means the reference counter will be increased for every object stored there. And if you replace weak with retain you can get reference cycle and leak some memory.
Related
When I control-drag outlet from xib, I got unsafe_unretained property by default. I'm using Xcode 9.1. The following code is what it looks like.
#property (unsafe_unretained, nonatomic) IBOutlet UILabel *shIndexLabel;
__unsafe_unretained specifies a reference that does not keep the referenced object alive and is not set to nil when there are no strong
references to the object. If the object it references is deallocated,
the pointer is left dangling.
Above excerpt from Apple docs. So answering your question WHY?
It is not possible for the Swift compiler to know if these references
are really intended to be strong (+1) or unretained (+0)
This change involved with respect to the swift compiler. They made __unsafe_unretained by default.
Actually, it's a bug of Xcode. It seems unsafe_unretained will appear when project didn't complete indexing. So we should change it to weak manually.
Can anyone tell me what is the difference among three property of delegation. I searched in google but did not get any satisfactory answer.
Please also tell me which is the best option and why?
#property (nonatomic, strong) id <GameAddViewControllerDelegate> delegate;
#property (nonatomic, weak) id <GameAddViewControllerDelegate> delegate;
#property (nonatomic, assign) id <GameAddViewControllerDelegate> delegate;
The difference is same as with strong, weak and assign specifiers.
Points to be noted : Any object never retains the delegate. Hence strong and retain should not be used.
weak and assign are allowed or even you can go with unsafe_unretained.
Why not to use retain?
Why use weak or assign?
Weak
weak applies to the delegate object (which has reference counts and
all the stuff), but weak references don't increase refcount. But once
the delegate object is deallocated (from anywhere in the code), any
weak reference to that object is set to nil. This is extremely useful,
because if you use only strong and weak references, you can't end up
with an invalid pointer (pointer to an already deallocated object).
Assign
assign is usually used for ints, floats and other non-object types.
You can of course assign an object reference to such a variable, but
if the object is deallocated, you will still have a pointer to it's
memory (which is garbage now, and will hurt you when you use it).
Strong
Strong will keep the object in the heap until it don't point to it
anymore. In other words " I'am the owner, you cannot dealloc this
before i'm fine with that same as retain" You use strong only if you
need to retain the object.
In case of delegation, weak preferred
You generally want to assign delegates rather than retain them, in order to avoid circular retain counts where object A retains object B and object B retains object A. (You might see this referred to as keeping a "weak reference" to the delegate.) For example, consider the following common pattern:
-(void)someMethod {
self.utilityObject = [[[Bar alloc] init] autorelease];
self.utilityObject.delegate = self;
[self.utilityObject doSomeWork];
}
if the utilityObject and delegate properties are both declared using retain, then self now retains self.utilityObject and self.utilityObject retains self.
Also see this detailed answer on stackoverflow
I am little confused about specifying strong, copy, or assign and not specifying them. We don't use NIB files. My colleague always use following - he says iOS detects it and use it automatically strong, weak etc.
#interface viewController : UIViewController
#property (nonatomic) UIImageView *imageView1;
#property (nonatomic) NSUInteger num;
#property (nonatomic) NSArray *array;
#end
I prefer following way doing it.
#interface viewController : UIViewController
#property (nonatomic, strong) UIImageView *imageView1;
#property (nonatomic, assign) NSUInteger num;
#property (nonatomic, copy) NSArray *array;
#end
Which one is better programming style? First option always have strong type as it defaults but I always specifies them explicitly.
As pointed out in earlier answers, in Objective C properties are by default,
atomic, strong/retain, readwrite --> For pointer types
atomic, assign, readwrite --> For primitive types
Property types weak, copy need to be explicitly specified by the programmer and in no way gets automatically decided.
What does each mean,
strong/retain referenced objects are kept alive in the memory until specified.
weak referenced objects will be destroyed when there is no strong reference. Typically used to reference delegate objects.
copy will create a shallow copy of the object getting assigned to the property.
assign/usafe_unretained(ARC) assigns the value. If used in case of pointer types this is an unsafe unretained assignment of the pointer. In ARC, typically use weak for pointer types because it will make the ivar=nil once weak referenced object is destroyed. assign in this case will lead to dangling pointer.
Personally, I prefer specifying property types even if it strong by default. This adds readability, which comes handy specially when profiling application for memory leaks or debugging crashes.
You can read more about properties here.
Hope that helps.
With ARC, strong is the default so the two are technically the same. From the Transitioning to ARC Release Notes:
__strong is the default. An object remains “alive” as long as there is a strong pointer to it.
Note that ARC will NOT automatically detect when something needs to be weak, however.
I tend to be explicit, like your second example, but I think it's mostly a matter of style/habit.
The default for a property is strongand for a variable is __strong too. In your current example the recommended property would actually be weak, but strong is acceptable too.
For properties of non-primitives you should no longer use assign, but rather unsafe_unretained. Practically they're the same, but the latter lets you know that you're using an object unsafely.
The copy property means that an object is copied (using the copy method) and not retained. It's recommended for classes such as NSString and NSArray, which have mutable forms. This is because you don't want to retain what you think is an immutable string but is actually being changed elsewhere.
The assign property declaration should be used only for primitive types and structs, e.g. int and CGSize.
Have an interesting issue where there is a class that is referenced in an XIB layout (subclass of UIScrollView) and is not being de-allocated according to Instruments / Allocations and does not break in it's dealloc routine. Let's call it Sclass1.
There is a using class (let's call it Uclass) that has the XIB file and the outlet.
#property (nonatomic, weak) IBOutlet Sclass1* sclass1;
This is hooked properly to the XIB file layout.
Sclass1 is property allocated when the XIB for Uclass is loaded. Uclass does get deallocated and then recreated from time to time and thus we have another instance of Sclass1, but Sclass1 never goes away and can't find another reference to it.
Drill down in Instruments shows the one Malloc and that is it.
fyi, the class gets started with
[UIClassSwapper initWithCoder:]
If an object doesn't get deallocated under ARC, it means a strong reference to it exists. Since your property is weak the object must be owned strongly by something other than the Uclass object (Otherwise it would get deallocated immediately after the XIB has loaded). In the code you've provided it isn't clear what the actual strong owner of this object is, but I assume it could be one (or more) of the following:
Since the object's class is a UIView subclass, it may be (strongly) referenced by its superview if added as one of subviews. This happens automatically when a XIB file is loaded. If the superview doesn't get deallocated neither will the SClass object. You can remove this ownership by calling removeFromSuperview
A strong ownership cycle (retain-cycle) exists somewhere among ivars of the SClass1 object (i.e. one of the strongly-owned instance variables have a strong reference back to its owner - the SClass1). Beware that any block using self directly also keeps a strong reference. Having a strong reference to the block then often leads to a retain-cycle. Save self to a __weak var and pass that to the block instead unless you have a good reason not to.
A manually created strong reference exists by e.g. adding the object to a container or saving the pointer to a non-__weak variable.
Try finding and removing these strong ownerships. Only after all of them are removed the object can be deallocated.
Since your property is weak and it's still not deallocated, look for strong references to Sclass or it's owner, Uclass. Maybe you are using Uclass(or Sclass) in block directly, without __weak typeof(self) weakSelf dancing and this block creates retain cycle. Also watch for parent-child relations and delegates. Maybe there is delegate which is strong instead of weak or two controllers hold strong references to eachother.
Also, if you want to have more detailed answers, please post more relevant code.
I think your #property should be strong for a class :
#property (nonatomic, strong) IBOutlet Sclass1* sclass1;
Because strong is the equivalent to retain and ARC will manage the release for you.
You will have more information with the Apple Documentation about Transitioning to ARC Release Notes in the section on property attributes.
I recently had the same symptoms - To solve it in my case, my object was acting as delegate for a number of other objects, so had to release the object from all its delegate responsibilities before it would call dealloc
I am developing an iPhone app with ARC option enabled. i am creating IBOutlets in .h files which are connected from file owners icon to .xib elements.for eg.
IBOutlet UIButton *bt;
#property(nonatomic,retain)IBOutlet UIButton *bt;
in .m file, i am doing
#synthesize bt;
Is there a need to explicitly set bt to nil in viewDidUnload method? i.e. self.bt = nil; in viewDidUnload?
Also, do I need to write dealloc method with ARC option enabled? When should I make IBOutlets elements as strong and weak references with ARC enabled?
There's a difference between the need to put your outlets to nil in viewDidUnload and dealloc
Having ARC means you don't need to write that in your dealloc method (it gets done automatically), however the viewDidUnload method serves another purpose, and it is to free memory that the application isn't using when a memory warning occurs.
dealloc is still needed in some cases, for example, when your class is registered for a notification, or when your class is someone else's delegate and you don't want some glitchy callback giving you a bad access
When you get a memory warning, all the UIViewControllers not being displayed will unload their view and call that method to free up memory. If you are still retaining outlets (like buttons, tables and etc) they will not get released, thus, killing the purpose of the viewDidUnload method.
When using ARC there is no need to use modifiers like retain or copy, for example. That kind of memory managment is done automatically using the strong and weak modifiers.
You also don't have to worry about writing dealloc methods.
strong is kind of the equivalent of retain, so you should mark your outlets with it
#property(nonatomic, strong) IBOutlet UIButton *bt;
That's the way interface builder creates them by default.
I won't go into detail about their semantic differences, but you should really have a look at Apple's guide on transitioning to ARC if you want to know what's going on and read about the specifics of strong and weak modifiers.
EDIT:
Sorry, interface builder creates outlets with weak by default.
EDIT 2:
strong and retain are indeed 100% identical. (thanks to #Adam)
EDIT 3:
You set your pointers to nil to avoid getting any message sent to deallocated instance or BAD_ACCESS_EXCEPTION errors.
If you are actually using ARC, you should make your outlets (nonatomic, weak) instead of (nonatomic, strong). By using the weak zeroing pointers, what the compiler does is automatically set your outlets to nil when nothing else references them.
So, summing up, if you don't use weak properties, you should set your pointers to nil.