4

I have a UIViewController that has a reference to a Timer object that is calling a closure repeatedly. The Timer object captures self in its block. As far as I understand this leads to a retains cycle between the View Controller and the block. There is a logic to set the timer to nil and then the retain cycle is broken, but it may not be executed.

My question is the following: The View Controller will live as long as the app lives (at least in current implementation). In this case - how should I best take care of this retain cycle? Should I ignore it since the View controller won't be released anyway. Should I consider possible future changes and handle it with unowned or weak references and which one. I guess it should be unowned since the timer is retained only by the View Controller and it should be released once the View Controller is released, but not sure if I am missing something. Thank you in advance. The following code is simple example of what I am talking about. Class A is the View Controller. 

class A {

    var timer: Timer? = nil
    var varToReference: Int = 0

    func startTimer() {
        timer = Timer.scheduledTimer(withTimeInterval: 2, repeats: true, block: {  (theTimer) in

            self.varToReference += 1

        })
    }

    func stopTimer() {
        if let theTimer = timer {
            theTimer.invalidate()
            timer = nil
        }
    }

    func onAdapterStarts() {
        self.startTimer()
    }

    func onAdapterStops(){
        self.stopTimer()
    }

    deinit {
        print("A Deinit")
    }

}
surToTheW
  • 772
  • 2
  • 10
  • 34

2 Answers2

2

In your case weak and unowned are acceptable. With simple code inside of timer block i suggest to use weak, otherwice, you can prefer unowned. Use weak to care about future updates and extendings of your project.

timer = Timer.scheduledTimer(withTimeInterval: 2, repeats: true, block: {[weak self] (theTimer) in

        self?.varToReference += 1

    })
Agisight
  • 1,778
  • 1
  • 14
  • 15
2

Retain cycle is the condition when two objects keep a reference to each other and are retained, it creates a cycle since both objects try to retain each other.

Now let's take your example code

In your example, Class A owns the closure through the timer variable. If you do not declare self as weak or unowned the closure would also own self creating a strong reference cycle.

Difference between unowned and weak

A simple difference is between unowned and weak is that weak is declared as optional where as unowned is not. By declaring it weak you get to handle the case that it might be nil inside the closure at some point. If you try to access an unowned variable that happens to be nil, it will crash the whole program. So only use unowned when you are positive that variable will always be around while the closure is around

Always be feature ready, as your work in any mobile app should always be expandable.

See this accepted answer for better understanding.

Vijay Sanghavi
  • 340
  • 1
  • 5
  • 23
  • Thanks for your answer and explanations. I wonder if I get this particular case correctly. The timer variable will live only if the view controller lives if self is captured as weak or unowned. Then does it mean it's safe to use unowned, or again I should think of a case when something else retains the timer (although it doest's seem likely) and the closure tries to access self when it's being deallocated? – surToTheW Apr 25 '19 at 11:05
  • In your use case what you can do is to make the self weak as example given by @Agisight. Now why do you use it? Because you've the time interval of 2 seconds after which your closure will get called. Since 2 seconds are more then enough for view controller to get deallocated, weak self (optional self) will help your code not to crash whereas if you make it unowned and self found nil, you'll see the crash. – Vijay Sanghavi Apr 25 '19 at 13:32
  • Okay, thank you. I thought the timer will get deallocated with the view controller and thus the block it holds on to will not execute. – surToTheW Apr 25 '19 at 14:21