What is the Swift standard for setting a variable you already know the value for? Here are the 2 different ways I'm thinking of.
Option 1: Declaring the variable in the class and then setting it in the ViewDidLoad method
class ViewController: UIViewController {
var refreshControl: UIRefreshControl!
var sampleString: String!
override func viewDidLoad() {
super.viewDidLoad()
refreshControl = UIRefreshControl()
sampleString = "Hello"
}
}
Option 2: Declaring the variable in the class and setting it inline
class ViewController2: UIViewController {
var refreshControl = UIRefreshControl()
var sampleString = "Hello"
override func viewDidLoad() {
super.viewDidLoad()
}
}
Which is the preferred way to do this in Swift? Thanks in advance!
First of all, you have two fundamentally different types in your two examples. In the first example, the type is an implicitly unwrapped optional String (i.e., String!), which means it can accept the nil value. In the second example, it is just String. If the value does not need to be nil assignable, the second option is better.
With regard to your actual question. I would say the second option is preferable, as you initialize the value earlier and there is no chance that you will use it before it is initialized. This would be equivalently good to declaring the type as String and deferring the initialization to an init method.
The viewDidLoad method is only useful for UIViewController instances, and doesn't get invoked until the view is loaded (which typically is during presentation). Waiting to initialize a value until then is probably not preferred and wouldn't be useful in objects that don't subclass UIViewController.
Related
I read an article says property needs to be nil when UIViewController class created, and then storyboard or you add it to value when viewDidLoad invoked.
It says properties can not be initialized when object is constructed also.
According to article it would be like below
Note that it is custom button not from storyboard.
class BetterViewController: UIViewController {
var myButton: UIButton!
override func viewDidLoad() {
super.viewDidLoad()
myButton = UIButton() // I set value to myButton.
let anotherVariable = myButton.method // whatever method
}
Above, myButton was type of nil first and then I set a value to it when viewDidLoad. Everything is okay so far. But I see so many codes like below
class ToDoListVewController: UITableViewController {
let defaults = UserDefaults.standard
var itemArray = [Item]() //
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view, typically from a nib.
if let items = defaults.array(forKey: "ToDoListArray") as? [String]{
itemArray = items
}
}
Above example, itemArray is not nil. But it needs to be nil when UITableViewController created. So I have to declare itemArray inside viewDidLoad or it is ok? I am confused.
Without any more context, the article is wrong. You obviously can have properties initialised inline, just like the examples you showed. If you want me to explain why the article says that, you should include a link to the article.
Generally, we would like set the property to nil and initialise it in viewDidLoad when the initialisation of the property requires the use of self. Gesture recognisers are a good example of this. We cannot do this:
let myGestureRecognizer = UITapGestureRecognizer(target: self, selector: ...)
because self is used. By the time the above executes, self may not have been constructed properly, so the compiler prohibits this kind of thing. Therefore, we can only set it tot nil:
var myGestureRecognizer: UITapGestureRecognizer!
and initialise it in viewDidLoad:
myGestureRecognizer = UITapGestureRecognizer(target: self, selector: ...)
On the other hand, if the initialisation of the property does not require self to be constructed, you can initialise it inline. For example, if you want to keep track of how many times a user has tapped on a button:
// Without doubt, this will be 0 at the start
var buttonPressedCount = 0
I've researched this 100 times, and still can't find the answer to my problem. I have a very simple protocol, but it's always nil. I've tried to add periodDelegate = self but get the error Cannot assign value of type 'ScoreClockPopoverViewController' to type 'PeriodDelegate!' I have other Protocol, using the same setup and work fine.
What am I missing?
Thanks in advance!
import UIKit
protocol PeriodDelegate {
func changePeriodButtonImage(selectedPeriod: Period)
}
class ScoreClockPopoverViewController: UIViewController {
//delegate
var periodDelegate: PeriodDelegate!
override func viewDidLoad() {
super.viewDidLoad()
print("viewDidLoad / periodDelegate \(String(describing: periodDelegate!))")
}
}
Function I need to call is in a UICollectionViewCell`
class HeaderCollectionViewCell: UICollectionViewCell {
override func awakeFromNib() {
super.awakeFromNib()
...
}
extension HeaderCollectionViewCell: PeriodDelegate {
func changePeriodButtonImage(selectedPeriod: Period) {
print("blah")
switch selectedPeriod {
case .first:
print("first")
case .second:
print("second")
case .third:
print("third")
case .overtime:
print("overtime")
case .shootout:
print("shootout")
}
}
}
First of all, it is very uncommon to have cell as delegate for view controller. Usualy, it is other way round. But anyways, in your case you have to set periodDelegate as this cell, not self. Cause your cell implements delegate protocol not the VC. But better rethink what do you want to do because it smells like bad design.
Your statement "I have a very simple protocol, but it's always nil." does not make sense.
A protocol is a specialized language. It can't be nil or non-nil.
Your ScoreClockPopoverViewController has a delegate property periodDelegate that conforms to the PeriodDelegate protocol, and that delegate property is nil.
A delegate is a property like any other. It will be nil unless you assign a value to it. It's nil because you never assigned an object as your ScoreClockPopoverViewController's delegate.
Who creates instances of ScoreClockPopoverViewController, and what object is supposed to be the delegate of your ScoreClockPopoverViewController?
Post your code that creates a ScoreClockPopoverViewController. That's likely where you need to assign your delegate. That code might look something like this:
let myScoreClockPopoverViewController = storyboard.instantiateViewControllerWithIdentifier("ScoreClockPopoverViewController")
myScoreClockPopoverViewController.periodDelegate = self
present(myScoreClockPopoverViewController,
animated: true,
completion: nil)
(That code is meant as a guide and you will need to modify it to make it work in your app. You will not be able to paste it into your app without modification.)
If you're displaying your myScoreClockPopoverViewController as a popover, as the name suggests, you'll need to adjust the code above.
I had the same problem and I fixed it following Fangming's answer by just changing
var periodDelegate: PeriodDelegate!
to
weak var periodDelegate: PeriodDelegate? = nil
and changing the call to
periodDelegate?.blablabla()
Swift - Error passing data between protocols / delegates (found nil)
I have been programming in Swift for a couple months now. Recently, I have focused more on concepts of how Swift as a language works.
Hence, recently while reading apple documentation on Automatic Reference Counting(ARC), I came across the following lines:
This one on top:
In most cases, this means that memory management “just works” in Swift, and you do not need to think about memory management yourself. ARC automatically frees up the memory used by class instances when those instances are no longer needed.
And in the next paragraph, the following:
To make this possible, whenever you assign a class instance to a property, constant, or variable, that property, constant, or variable makes a strong reference to the instance. The reference is called a “strong“ reference because it keeps a firm hold on that instance, and does not allow it to be deallocated for as long as that strong reference remains.
I am a little confused as to what is the dynamics of the situation. I have noted while using storyboards, that you set reference to weak, hence the class looks like this, also what I would call case 1:
Case 1
class SomeClass : UIViewController {
#IBOutlet weak var nameLabel : UILabel!
override func viewDidLoad() {
nameLabel.text = "something."
}
}
Here, the label has one-to-one weak reference with the ViewController, and as soon as the Controller is changed, reference is broken (memory dealloc) since it is weak. Hence, no issues related to the memory.
Pardon me if the above statement is wrong or loosely held. I would be glad if someone confirms my assumption or counters it.
My question is about the second case however, where I do not use storyboards and class looks like below:
Case 2
class SomeClass : UIViewController {
var nameLabel : UILabel = {
let label = UILabel()
label.translatesAutoresizingMaskIntoConstraints = false
return label
}()
override func viewDidLoad() {
view.addSubView(nameLabel)
// view.addConstraints...
}
}
For the above case, My assumption is that the ViewController has one-on-one strong reference with the label, and the view inside ViewController also has strong reference with the label.. If the class is changed/ label is removed from subview.. then I think the memory would not be deallocated. Or at least the view controller will maintain a strong reference to the label (as per the docs.)
I confirmed this by removing label from view's subviews and printing out the label (It gave me an instance of UILabel with frame that was at 0 origin and 0 size.) hence an instance that isn't nil.
The only thing I could gather from this was that although the label was removed from UIView, it still maintained a strong reference with the controller, hence permanent state in memory. Am I right?
If this is the case. How should I prevent my code from having such memory issues? The bigger problem is that if I declare my variable like so, I get a nil while adding it as a subview of main view in controller.
weak var nameLabel : UILabel = {
let label = UILabel()
label.translatesAutoresizingMaskIntoConstraints = false
return label
}()
If declaring variables like in the second case can cause permanent strong references how should I declare them instead to not have memory issues?
So to conclude, my question is:
In cases where no storyboard outlets are used, and variables are strongly referenced to the view controller, will these references cause memory issues?
If so, what code declaration practice must I follow?
If not so, please provide thoughtful arguments with valid explanations to counter it.
Again, pardon me if I am incorrect anywhere.
Thank you in advance.
The only thing I could gather from this was that although the label was removed from UIView, it still maintained a strong reference with the controller, hence permanent state in memory. Am I right?
No. There's no big issue here.
The label has no strong reference to the view controller — if it did, that would be a retain cycle and would cause both the label and the view controller to leak. For this very reason, a view should never keep a strong reference to its view controller.
Here, however, it's the other way around: the view controller has a strong reference to the label. That's fine. It's true that the label therefore stays in existence after it has been removed from its superview. But that might not be bad. In many cases, it's good! For example, suppose you intend to put the label back into the interface later; you will need to have retained it.
If you are sure you won't need to keep the label around later, then simply use an Optional wrapping a UILabel as your instance property. That way, you can assign nil to the label instance property when you're done with it, and the label will go out of existence.
But in any case there is no leak here and you should just stop worrying. When the view controller goes out of existence, the label will go out of existence too. The label lived longer than it had to, but that's tiny and unimportant on the grand scale of things.
create the label when you need ,then call addsubView to make an strong reference to it and make an weak reference to your member var like this:
class ViewController: UIViewController {
weak var label : UILabel?
override func viewDidLoad() {
super.viewDidLoad()
let label = UILabel()
view.addSubview(label)
self.label = label
}
override func touchesBegan(touches: Set<UITouch>, withEvent event: UIEvent?) {
print(label)
//click first Optional(<UILabel: 0x7fb562c3f260; frame = (0 0; 0 0); userInteractionEnabled = NO; layer = <_UILabelLayer: 0x7fb562c11c70>>)
//click second nil
label?.removeFromSuperview()
}
}
anyway while the viewcontroller release ,the label will be release and view.subview will be release too.
Demo
i wrote an easy demo make the ViewControllerTest to be the rootviewcontroller
class Test{
weak var label:UILabel?
static let instance = Test()
}
class ViewControllerTest: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
let item = UIBarButtonItem(title: "Test", style: .Plain, target: self, action: #selector(self.test))
self.navigationItem.rightBarButtonItem = item
}
func test(){
print(Test.instance.label)
}
override func touchesBegan(touches: Set<UITouch>, withEvent event: UIEvent?) {
let vc = ViewController()
self.navigationController?.pushViewController(vc, animated: true)
print(vc.nameLabel)
let test = Test.instance
test.label = vc.nameLabel
}
}
class ViewController: UIViewController {
var nameLabel : UILabel = {
let label = UILabel()
label.translatesAutoresizingMaskIntoConstraints = false
return label
}()
override func viewDidLoad() {
super.viewDidLoad()
view.backgroundColor = UIColor.whiteColor()
view.addSubview(nameLabel)
let item = UIBarButtonItem(title: "Test", style: .Plain, target: self, action: #selector(self.test))
self.navigationItem.rightBarButtonItem = item
}
func test(){
print(Test.instance.label)
}
}
I don't think strongly referenced variables to view controller cause any memory issues.
Normally views are deallocated before deallocating their view controller. For example, in in your code, when deallocating the view, ARC decreases the counter pointing to namelabel, so it passes from 2 to 1. Then, when deallocating the view controller it decreases the counter again, from 1 to 0. Once there are 0 references pointing to namelabel its removed.
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. This behavior prevents the reference from
becoming part of a strong reference cycle. You indicate a weak
reference by placing the weak keyword before a property or variable
declaration
> 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.
Because a weak reference does not keep a strong hold on the instance
it refers to, it is possible for that instance to be deallocated while
the weak reference is still referring to it. Therefore, ARC
automatically sets a weak reference to nil when the instance that it
refers to is deallocated. Because weak references need to allow nil as
their value, they always have an optional type. You can check for the
existence of a value in the weak reference, just like any other
optional value, and you will never end up with a reference to an
invalid instance that no longer exists
Source: Apple docs
A weak reference is just a pointer to an object that doesn't protect the object from being deallocated by ARC. While strong references increase the retain count of an object by 1, weak references do not. In addition, weak references zero out the pointer to your object when it successfully deallocates. This ensures that when you access a weak reference, it will either be a valid object, or nil.
Hope can help you to understand better a weak reference, be it related to a storyboard item or created programmatically.
I always explain it to my students like this.
With a strong reference, you can see a value, and you have a lasso around it. You have a say in whether the value remains alive.
With a weak reference, you can see it, but there's no lasso. You have no say in whether the value lives or not.
For your situation to avoid occurrence of Memory leak for a second. You can go with Matt answer.
For better understanding, create a custom UILabel class under MRC flag in build phases->Complie sources.
In custom class, override retain and release method. Put breakpoints on them.
Use that custom UILabel class in your view controller with ARC flag ON. Go with matt answer or use below optional declaration of UILabel.
import UIKit
class ViewController: UIViewController {
var label:UILabel? = {
let label = UILabel()
label.translatesAutoresizingMaskIntoConstraints = false
label.text = "something"
return label
}()
override func viewDidLoad() {
super.viewDidLoad()
self.view.addSubview(self.label!)
//namelabel goes out of scope when method exists.
//self.view has 1+ ref of self.label
}
override func viewDidAppear(animated: Bool) {
super.viewDidAppear(animated)
self.label?.removeFromSuperview()//-1 ref of self.label
self.label = nil
print(self.label)
}
override func didReceiveMemoryWarning() {
super.didReceiveMemoryWarning()
// Dispose of any resources that can be recreated.
}
}
You will have clear picture of how ARC works and why weak ref of UILabel causes crash while adding to UIView.
I have a UICollectionView with a CollectionReusableView header. I want to pass a string from the collecitonview to the header, so that the header knows which data to load based on the string. I am trying to use delegates/protocols to do this, but keep getting "unexpectedly found nil while unwrapping an optional value." Here is my code:
protocol UserToQuery {
func thisUser(x: String)
}
class Profile: UICollectionViewController {
var ownProfile = true
var delegate:UserToQuery?
override func viewDidLoad() {
super.viewDidLoad()
if self.ownProfile == true {
let username = PFUser.currentUser()?.username
self.delegate!.thisUser(username!)
}
}
}
And here is the code for the Header view:
class ProfileHeader: UICollectionReusableView, UserToQuery {
var id1 = String()
var controller = Profile()
override func awakeFromNib() {
print(id1)
controller.delegate? = self
}
func thisUser(x: String) {
self.id1 = x
getProfileInfo()
}
func getUserData() {
// code here uses the id1 value to get data
}
}
My understanding of delegates/protocols is this: if you want to pass data (i.e., string), to another view, you make the view that receives the string conform to a protocol. This protocol includes a function that is used to pass the string, and when that function is called, it notifies the other view that the string is now available for use, and then you code what you want and use the string. Is that accurate?
In ProfileHeader, you have a variable, controller, which is creating a new instance of Profile, which is NOT the Profile view controller from your storyboard. This is why self.delegate! is nil in Profile.viewDidLoad().
I am going to make the assumption that ProfileHeader is a view in the Profile view controller. In your viewDidLoad, you should set the delegate to the ProfileHeader. See the example code below (I assume an outlet for the ProfileHeader view):
EDIT: ProfileHeader is not an outlet, as mentioned in the comments. Updated my answer to reflect that.
class Profile: UICollectionViewController {
var ownProfile = true
var delegate:UserToQuery?
override func viewDidLoad() {
super.viewDidLoad()
// Set the delegate!
self.delegate = ProfileHeader()
if self.ownProfile == true {
let username = PFUser.currentUser()?.username
// Delegate won't be nil now
self.delegate!.thisUser(username!)
}
}
}
}
As a general flow, the view controller should keep references to the view, not the other way around. So remove the controller property from your ProfileHeader view. The view shouldn't care what view controller is controlling it.
You have some misunderstandings about protocol/delegate, but it’s normal when you start iOS development.
First of all, why does the app crash :
The variable delegate is an optional UserQuery. It’s okay for a delegate to be optional, but it’s never set in your code, so when you call :
self.delegate!.thisUser(username!)
you try to force unwrapping a nil variable, which results in the crash.
Protocols
Now, let’s talk about the protocol/delegate relationship.
You have an UICollectionViewController subclass, which embeds an UICollectionView object. This UICollectionView will be contains a mix of header, footer and cell. Your ProfileHeader class will thus be displayed within your UICollectionView.
In order to populate an UICollectionView, you don’t need to create your own protocol : there are already two protocols for this :
UICollectionViewDataSource is the main protocol to conforms to, because it allows you to populate the collection view
UICollectionViewDelegate is used for further customization of your tableview, i.e. customizing the appearance and handling events.
Since your Profile class inherits from UICollectionViewControlleryou don’t have to named these protocols after your class name since UICollectionViewController already conforms to these protocols as written in Apple docs
You will have to override the delegate and protocol methods in order to display some data. My advice is, before using headers and footers, to use only UICollectionViewCell objects for start easily.
By overriding the method -collectionView:numberOfItemsInSection: and - collectionView:cellForItemAtIndexPath:, you will be able to populate the collection view.
A conceptual question. Why my function calls only work inside the viewDidLoad?
import UIKit
class ViewController2: UITableViewController, UITableViewDataSource {
#IBOutlet var tableview2: UITableView!
var forceView2 = [Float]()
var stiffView2 = [Float]()
var springNumView2 : NSInteger = NSInteger()
override func viewDidLoad() {
super.viewDidLoad()
println(self.forceView2)
println(self.stiffView2)
println(self.springNumView2)
var Answer = calculate(forceView2, stiffView2, springNumView2)
println(Answer.self)
}
If var Answer = calculate(forceView2, stiffView2, springNumView2) is placed above the viewDidLoad, an error of 'ViewController2.type does not have a member named 'forceView2'.
If you move that line out of the method scope, you are actually turning a local variable into a property. This way the Answer property is visible to all instance methods, but also accessible from outside.
The problem in your case is that the property is initialized with the return value of an instance function, which indirectly references to self - but swift doesn't allow referencing to self during the initialization, that's the reason why you have a compilation error.
You are trying to call a function in the class body and not within a method that's why.
You can of course create a computed property. A property that returns a calculated value:
https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Properties.html#//apple_ref/doc/uid/TP40014097-CH14-ID259
Something along these lines should work:
var answer : [Float] { return calculate(forceView2, stiffView2, springNumView2) }