I have one weak symbol from a specific file which is getting overrirden by strong symbol in release build. Is there any way to convert weak symbol to strong
I have one weak symbol from a specific file which is getting overrirden by strong symbol in release build. Is there any way to convert weak symbol to strong
Related
I want fully understand what going inside weak and unowned referance in Swift.
For this i read MikeAsh and got some questions.
What already known:
when there is no weak (and, i suppose, unowned) object reference, the strong reference counter is stored directly in the memory area of the object
when a weak link appears, the second word in the object memory is reused to reference the side table
side table has link to the object
weak link refers to this side table
And what i want to clearify:
What else side table store inside except link to the object and number of strong reference?
Is unowned reference link to the side table too? If not and unowned link refers to the object memory what about performance between weak and unowned ?
Okay, i found out.
Unowned link points to the object as well as strong.
Unowned link faster than weak.
Side table stores strong RC, weak RC, unowned RC, link to the object and some flags
Setting up a UILabel in Swift I can do the following
#IBOutlet var wLabel: UILabel!
or
#IBOutlet var wLabel: UILabel?
Setting the text I can either do
wLabel.text = "..."
or, for the latter do
wLabel?.text = "..." // with a question mark for the optional
Keeping them optional will help for the case when they are unexpectedly nil as it will just skip this call then and go ahead with the code. Having them declared with the ! would crash the app if the label was nil.
Now why would you not make everything optional? The only reason I could think of would be for better performance. Should I stay away from having them optional if my app has a lot of UI elements so them being optional would mean a disadvantage regarding performance? I wasn't able to find any information on this anyhere.
Using ? in your Outlet will make your code untracable
Crashes are very good in some scenarios, because if no crash is there then it becomes super difficult to trace even small error.
Consider the examples of #IBOutlet with !:
#IBOutlet var wLabel: UILabel!
wLabel.isEnabled = true
Just remove the connection of your Outlet label from your storyboard and run the app, your app will crash on wLabel.isEnabled = true. Since you got a crash so you can got to your storyboard see whether the connection is proper or not. In case there is no connect you add it and damn! you solved the problem easily.
Now consider the examples of #IBOutlet with ?:
#IBOutlet var wLabel: UILabel?
wLabel?.isEnabled = true
Do the same thing, just remove the connection of your Outlet label from your storyboard and run the app, your app won't crash at all. You won't be able to know the error, hence making your code a mess and untracable.
Apple guys were very aware of optional thing, they did force unwrapping of #IBOutlet for a reason. And of course there is no performance difference between ! and ?
If you're setting something up as an outlet it's set up as a force unwrapped optional (with exclamation mark !) because Swift requires your classes to have all of their properties initialized when the object is constructed (i.e. init method is called). Outlets are not created during object construction but rather assigned later when the xib or storyboard data is loaded into your component. Force unwrapped optionals are basically a way to say that you guarantee that the property will be initialized after object's init is called and before they're used.
There are no performance gains to using either of these. An Optional? type means that the property can either be nil or have a value. A force unwrapped optional ! means that the property is guaranteed to have a value when it is used. Upholding this is up to the developer and using such property if its value is nil will result in a crash.
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?
This question already has answers here:
What is the difference between a weak reference and an unowned reference?
(7 answers)
Closed 8 years ago.
In Swift, there is option to use unowned or weak. Why use unowned when you can use weak? It seems the two are almost the same, with weak being safer.
Apple says that the rules are as follows:
Use a weak reference whenever it is valid for that reference to become nil at some point during its lifetime.
Use an unowned reference when you know that the reference will never be nil once it has been set during initialization.
The reason for having unowned in the first place is that weak must be of an optional type, while unowned will be non-optional. This lets you avoid unwrapping and/or checking, which is associated with variables of optional type.
Both kinds of references carry the same costs: Swift keeps track of them, so that it could set weak references to nil, and mark unowned references invalid when the object they reference is destroyed.
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.