As strong and weak properties are new in iOS 5.
If any one tell me which property is used when.
When we should use strong or when we should use weak?
#property(nonatomic,strong)
#property(nonatomic,weak)
Review Apple documentation for the Automatic Reference Counting (ARC)
If you don't have time for reading it:
ARC introduces several new lifetime qualifiers for objects, and weak references. A weak reference does not extend the lifetime of the object it points to, and automatically becomes nil when there are no strong references to the object.
strong is the default. An object remains “alive” as long as there is a strong pointer to it.
weak specifies a reference that does not keep the referenced object alive. A weak reference is set to nil when there are no strong
references to the object.
As iOS 5 ARC automatically nullifies weak links, when an object is unloaded its object hierarchy is automatically set to nil. Because this reason, Weak is the recommended relationship for all outlet properties. These view objects are already part of the view controller’s view hierarchy and don’t need to be retained elsewhere. The big advantage of declaring your outlets weak is that it saves you time writing the viewDidUnload method.
Check a very detailed document refering memory management. It is previous to ARC, but it will help you to understand the memory management. The retain keyword for properties still works with ARC and is simply a synonym for strong. Or another specific ARC tutorial.
Strong means that as long as this property points to an object, that object will not be automatically released. In non-ARC it's a synonym for retain.
Weak instead, means that the object the property points to, is free to release but only if it sets the property to nil. In ARC you use weak to ensure you do not own the object it points to.
strong is like retain, weak is like assign. The main difference is that weak properties turn to nil when the object that is assigned to them gets released.
eg:
#property (nonatomic, weak) id test;
...
- (void)example
{
id foo = [[NSObject alloc] init];
self.test = foo;
foo = [[NSObject alloc] init];
assert(self.test == nil);
}
There are following difference between strong and weak.
1.If we declare variable strong then it is not deallocated by compiler till the Application instance in memory.When we set nil value to that reference then it deallocates by compiler, by default any local variable as strong variable.
For instance:-
var str = "hello world"
if we set str = nil then it is deallocated.
2.If we declare variable as strong then it is retain by other instance(Class) and it's retain count increment by 1.
Weak property.
1.When we declare weak property then it only contains data/instance address till strong reference is in memory if strong variable reference deallocated it is automatically set to nil.
For ex:-
var str = "hello world"
weak var stringVar = str
suppose str contain 200 heap address and we set str = nil, then automatically weak property reference set to nil by the compiler.
So that's the reason in stoary board ref controller, Main view only set to strong and other are weak for ex- we can see UIButton,UILabel out let e.t.c.
Related
Per:
#IBOutlet weak var nameLabel: UILabel!
Whenever I declare my IBOutlets, i just use var instead of weak var. But I've recently come across a few code templates that use weak var. Why do they do it? What's the added benefit?
Why is there a bang operator at the end of UILabel. I know it's required and i go along w/ it, but just asking it now.
Thanks in advance.
Swift IBOutlet are weak by default (but others properties are strong by default). So both writing are the same.
You have more details about the difference between weak and strong here
According to apple documentation
When you declare an outlet in Swift, you should make the type of the
outlet an implicitly unwrapped optional (!). This way, you can let the
storyboard connect the outlets at runtime, after initialization.
The outlets are weak since the view elements are owned (strongly) by the view. I think it's technically OK for your view controller to have a strong reference too, but not necessary.
Weak variables are optional since they can be nil. You can declare your outlets with ? instead but that means using force-unwrapping or optional binding every time. Declaring them as implicitly-unwrapped optionals with ! is just a convenience.
You use weak when referring to IBOutlets because so long as the object remains in its superview there will be a strong reference to it. See weak or strong for IBOutlets.
Next, the bang operator indicates that the IBOutlet is an explicitly unwrapped label. With the bang operator, it guarantees that the object will exist, so when referencing it, you can simply reference it like this:
someLabel.text = "some text"
However, you can make them IBOutlets optional:
#IBOutlet weak var someLabel: UILabel?
But you must use ? when accessing them
someLabel?.text = "some text"
#gregheo's response is the best explained, to further elaborate: if you consider ownership in this situation the View object referred to by the #IBOutlet usually shouldn't be owned by the View Controller referring to it.
Rather it should be owned by its superview wherever it may be in the tree (which happens strongly by UIView.subviews). The View Controller instead owns the very root of it's View Tree strongly (UIViewController.view). weak explicitly declares a non-owning reference that may become nil at different points in the View Controller's life.
Here I would offer an alternative to using !: using an implicitly unwrapped optional reference is a dangerous practice that weakens the tools Swift offers us. A View Controller which is loaded from Xib or Storyboard includes in its lifetime a regular time after being created and before it's View has been loaded where the #IBOutlet reference is nil, every time. To assume no one will operate on the member during that time means not using the Swift grammar and compiler's feedback to our advantage.
Additionally #IBOutlets are a powerful tool that enables a flexible, visually focused approach when designing a screen or view. It is common practice to have your View Controller expose #IBOutlets for all information it has available, regardless of whether or not it is known that it will be used and separately deciding which to actually connect and use when building and iterating on the View from within Interface Builder.
Additionally-additionally if your View should be flexible enough to be instantiated from Xib/Storyboard AND from code, depending on how you decide referenced subviews should be instantiated and connected they may or may not be available immediately.
For the reasons above I define mine: #IBOutlet weak var nameLabel: UILabel?
Swift has:
Strong References
Weak References
Unowned References
How is an unowned reference different from a weak reference?
When is it safe to use an unowned reference?
Are unowned references a security risk like dangling pointers in C/C++?
Both weak and unowned references do not create a strong hold on the referred object (a.k.a. they don't increase the retain count in order to prevent ARC from deallocating the referred object).
But why two keywords? This distinction has to do with the fact that Optional types are built-in the Swift language. Long story short about them: optional types offer memory safety (this works beautifully with Swift's constructor rules - which are strict in order to provide this benefit).
A weak reference allows the possibility of it to become nil (this happens automatically when the referenced object is deallocated), therefore the type of your property must be optional - so you, as a programmer, are obligated to check it before you use it (basically the compiler forces you, as much as it can, to write safe code).
An unowned reference presumes that it will never become nil during its lifetime. An unowned reference must be set during initialization - this means that the reference will be defined as a non-optional type that can be used safely without checks. If somehow the object being referred to is deallocated, then the app will crash when the unowned reference is used.
From the Apple docs:
Use a weak reference whenever it is valid for that reference to become
nil at some point during its lifetime. Conversely, use an unowned
reference when you know that the reference will never be nil once it
has been set during initialization.
In the docs, there are some examples that discuss retain cycles and how to break them. All these examples are extracted from the docs.
Example of the weak keyword:
class Person {
let name: String
init(name: String) { self.name = name }
var apartment: Apartment?
}
class Apartment {
let number: Int
init(number: Int) { self.number = number }
weak var tenant: Person?
}
And now, for some ASCII art (you should go see the docs - they have pretty diagrams):
Person ===(strong)==> Apartment
Person <==(weak)===== Apartment
The Person and Apartment example shows a situation where two properties, both of which are allowed to be nil, have the potential to cause a strong reference cycle. This scenario is best resolved with a weak reference. Both entities can exist without having a strict dependency upon the other.
Example of the unowned keyword:
class Customer {
let name: String
var card: CreditCard?
init(name: String) { self.name = name }
}
class CreditCard {
let number: UInt64
unowned let customer: Customer
init(number: UInt64, customer: Customer) { self.number = number; self.customer = customer }
}
In this example, a Customer may or may not have a CreditCard, but a CreditCard will always be associated with a Customer. To represent this, the Customer class has an optional card property, but the CreditCard class has a non-optional (and unowned) customer property.
Customer ===(strong)==> CreditCard
Customer <==(unowned)== CreditCard
The Customer and CreditCard example shows a situation where one property that is allowed to be nil and another property that cannot be nil has the potential to cause a strong reference cycle. This scenario is best resolved with an unowned reference.
Note from Apple:
Weak references must be declared as variables, to indicate that their
value can change at runtime. A weak reference cannot be declared as a
constant.
There is also a third scenario when both properties should always have a value, and neither property should ever be nil once initialization is complete.
And there are also the classic retain cycle scenarios to avoid when working with closures.
For this, I encourage you to visit the Apple docs, or read the book.
Q1. How is an “Unowned reference” different from a “Weak Reference”?
Weak Reference:
A weak reference is a reference that does not keep a strong hold on
the instance it refers to, and so does not stop ARC from disposing of
the referenced instance. Because weak references are allowed to have
“no value”, you must declare every weak reference as having an
optional type. (Apple Docs)
Unowned Reference:
Like weak references, an unowned reference does not keep a strong hold
on the instance it refers to. Unlike a weak reference, however, an
unowned reference is assumed to always have a value. Because of this,
an unowned reference is always defined as a non-optional type. (Apple Docs)
When to Use Each:
Use a weak reference whenever it is valid for that reference to become
nil at some point during its lifetime. Conversely, use an unowned
reference when you know that the reference will never be nil once it
has been set during initialization. (Apple Docs)
Q2. When is it safe to use an “unowned reference”?
As quoted above, an unowned reference is assumed to always have a value. So you should only use it when you are sure that the reference will never be nil. Apple Docs illustrate a use-case for unowned references through the following example.
Suppose we have two classes Customer and CreditCard. A customer can exist without a credit card, but a credit card will not exist without a customer, i.e. it can be assumed that a credit card will always have a customer. So, they should have the following relationship:
class Customer {
var card: CreditCard?
}
class CreditCard {
unowned let customer: Customer
}
Q3. Are “unowned reference” reference an security risk like “dangling pointers” in C/C++
I don't think so.
Since unowned references are just weak references that are guaranteed to have a value, it shouldn't be a security risk in any way. However, if you try to access an unowned reference after the instance that it references is deallocated, you will trigger a runtime error, and the app will crash.
That's the only risk I see with it.
Link to Apple Docs
If self could be nil in the closure use [weak self].
If self will never be nil in the closure use [unowned self].
If it's crashing when you use [unowned self] then self is probably nil at some point in that closure and you probably need to use [weak self] instead.
Check out the examples on using strong, weak, and unowned in closures:
https://developer.apple.com/library/ios/documentation/swift/conceptual/swift_programming_language/AutomaticReferenceCounting.html
Extracts from link
Few Concluding points
To determine if you even need to worry about strong, weak, or
unowned, ask, “Am I dealing with reference types”. If you’re working
with Structs or Enums, ARC isn’t managing the memory for those Types
and you don’t even need to worry about specifying weak or unowned for
those constants or variables.
Strong references are fine in hierarchical relationships where the parent references the child, but not vice-versa. In fact, strong references are the most appropraite kind of reference most of the time.
When two instances are optionally related to one another, make sure
that one of those instances holds a weak reference to the other.
When two instances are related in such a way that one of the
instances can’t exist without the other, the instance with the
mandatory dependency needs to hold an unowned reference to the other
instance.
Both weak and unowned references will not impact the reference count of the object. But weak reference will always be optional i.e. it can be nil, whereas unowned references can never be nil so they will never be optional. When using an optional reference you will always have to handle the possibility of the object being nil. In case of an unowned reference you will have to ensure that the object is never nil. Using an unowned reference to a nil object will be similar to forcefully unwrapping an optional that is nil.
That said it is safe to use an unowned reference where you are sure that the object’s lifetime is more than the reference’s. If that is not the case it is better to use a weak reference instead.
As for the third part of the question, I don’t think unowned reference is similar to a dangling pointer. When we talk about reference count, we usually refer to strong reference count of the object. Similarly swift maintains unowned reference count and weak reference counts for the object (weak reference points to something called a "side table" rather than the object itself ). When the strong reference count reaches zero, the object gets deinitialised, but it cannot be deallocated if the unowned reference count is more than zero.
Now a dangling pointer is something that points to a memory location that has already been deallocated. But in swift since the memory can only be deallocated as long as there is an unowned reference to the object, it cannot cause a dangling pointer.
There are a lot of articles that discuss swift memory management in more detail. Here is one.
Unowned references are a kind of weak reference used in the case of a Same-Lifetime relationship between two objects, when an object should only ever be owned by one other object. It's a way to create an immutable binding between an object and one of its properties.
In the example given in the intermediate swift WWDC video, a person owns a credit card, and a credit card can only have one holder. On the credit card, the person should not be an optional property, because you don't want to have a credit card floating around with only one owner. You could break this cycle by making the holder property on the credit a weak reference, but that also requires you to make it optional as well as variable (as opposed to constant). The unowned reference in this case means that although CreditCard does not have an owning stake in a Person, its life depends on it.
class Person {
var card: CreditCard?
}
class CreditCard {
unowned let holder: Person
init (holder: Person) {
self.holder = holder
}
}
Use unowned when you are sure self can never be nil at the point you accessing self at that point.
Example (you can of course add the target directly from MyViewController, but again, it's a simple example).:
class MyViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
let myButton = MyButton { [unowned self] in
print("At this point, self can NEVER be nil. You are safe to use unowned.")
print("This is because myButton can not be referenced without/outside this instance (myViewController)")
}
}
}
class MyButton: UIButton {
var clicked: (() -> ())
init(clicked: (() -> ())) {
self.clicked = clicked
// We use constraints to layout the view. We don't explicitly set the frame.
super.init(frame: .zero)
addTarget(self, action: #selector(clicked), for: .touchUpInside)
}
#objc private func sendClosure() {
clicked()
}
}
Use weak when there is a possibility self can be nil at the point you accessing self.
Example:
class MyViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
NetworkManager.sharedInstance.receivedData = { [weak self] (data) in
print("Can you guarentee that self is always available when the network manager received data?")
print("Nope, you can't. Network manager will be alive, regardless of this particular instance of MyViewController")
print("You should use weak self here, since you are not sure if this instance is still alive for every")
print("future callback of network manager")
}
}
}
class NetworkManager {
static let sharedInstance = NetworkManager()
var receivedData: ((Data) -> ())?
private func process(_ data: Data) {
// process the data...
// ... eventually notify a possible listener.
receivedData?(data)
}
}
Cons of unowned:
More efficient than weak
You can (well, you are forced) to mark the instance as immutable (not anymore since Swift 5.0).
Indicates to the reader of your code: This instance has a relationship to X and it can't live without it, but if X is gone, I am gone too.
Cons of weak:
More safe than unowned (since it can't crash).
Can create a relationship to X that goes in both ways, but both can live without each other.
If you aren't sure, use weak. Wait, I mean ask here on StackOverflow what you should do in your case! Using weak all the time when you shouldn't is just confusing for you and the reader of your code.
I have few questions.
1)where assign property will take memory as we dont need to release for reducing reference count?
2)what is the difference between auto zero reference and non-auto zero reference?how does it work? how will take memory?
weak applies to objects (they have reference counts and all the stuff), but weak references don't increase refcount. But once the 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 does absolutely nothing with the reference, it 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).
Your concerns about "memory use" are weird - references don't take memory, object do. But you can't deallocate an object if you are going to use it. The simple rule for beginners is: for objects, use strong references whenever you can. When you have a reason not to use strong reference, use weak (usually for delegates and datasources). For primitive types (int, float, CGRect, ...) use assign, because they are not objects.
assign is like weak but there's no zeroing of the pointer when it leaves the heap. So, it's not as safe as weak.
Is the following true:
weak = unsafe_unretain = assign
strong = retain
If it is why they are duplicated ? Which one should we choose?
No, it's not true. weak means that the object is not retained, and additionally, the variable/property will automatically be set to nil when the object is deallocated. unsafe_unretained means the object is not retained, but there is no automatic zeroing. strong and retain are equivalent.
assign is typically used for primitives, like int or double, since you're just assigning. unsafe_unretained is used for Objective-C objects that you know are not being retained, and understand why that's unsafe. weak is a new feature introduced in iOS 5 that is like unsafe_unretained, but has different semantics with ARC. Check out Apple's Advanced Memory Management guide for more info.
In practice, you'll almost never use unsafe_unretained if you're targeting iOS 5 or higher.
strong: variable is retained during its scope. retain also works as a synonym for strong.
copy: creates and retains a copy.
weak: use it to point to an object without claiming ownership. Once the object is released, the pointer will be nil'ed.
unsafe_unretained: same as weak but doesn't nil the pointer after release.
assign: primitive values.
If you're targeting iOS 4, you cannot use weak. Use unsafe_unretained instead.
Before ARC, the default on properties was assign, now the default is strong.
weak != unsafe_unretain
weak will automatically convert its pointer to a nil if the object it is pointing to is deallocated.
Going forward you should use strong & weak for objects and assign for primitive types
Wikipedia states "In computer programming, a weak reference is a reference that does not protect the referenced object from collection by a garbage collector". How do those two types of references look like in code? Does a weak reference is a reference made by an autoreleased message?
The following answer is for the case when there is no garbage collection (such as on iOS).
In the case of garbage collection, there is actually a keyword (__weak) to create a weak reference.
A "weak" reference is a reference that you do not retain.
You need to use these weak references to break up cycles. A common case is a child object that needs a reference to its parent object. In this scenario, the parent would retain a reference to the child object, and the child object has a reference to its parent, but does not retain it. This works because the child object only needs to exist as long as the parent object does.
Does a weak reference is a reference made by an autoreleased message?
Not really, that would be a "very weak reference" ;-)
Auto-released stuff goes away when the call stack is unwound (at the end of every event loop for example). If you need anything to be less temporary, you need to retain a reference (or like in the case above be sure that some other part retains it sufficiently).
A weak reference is a reference that isn't strong enough to force an object to remain in memory while a strong reference forces an object to remain in memory.
If you have created weak reference to any variable, you may get nil for that.
UITableViewDelegate, UIScrollViewDelegate, etc are examples of weak references.
Example of Strong reference :
MyClass *obj1 = [[Myclass alloc] init];
Myclass *obj2 = obj1;
Here obj2 has strong reference to obj1 mean if you remove obj2 from memory then obj1 also get removed.