Animation is timing-based thing, and NSTimer obviously is a timing-based class. NSTimer is a very simple little class that allows us to call a method periodically. And we could either have it repeating where it's calling it over and over every certain amount of time, or we can actually just have it call it once sometime in the future. So it's a way to set up a time or to call a method. It couldn't really be simpler than that.

We are not going to use it for animation, things move around and stuff. There's other mechanisms for doing that. Where NSTimer kind of can come in and be used. It's actually quite useful in a lot of situations.

It's not a real time timer. This is not a real time operating system. You got that main queue. Other blocks might executing off that main queue. And so the timer is trying to execute, but it can't cuz it's busy. So it could be off a little bit but it's generally going to try to this, call this method when you say. The timer is built on a mechanism in iOS, called run loops.

For the main queue, there's a run loop set up for you, so NSTimer always worked in the main queue. For other queues, you may or may not have a run loop. You might have to set up your own run loop, etc, so for the purposes of this class, just assume NSTimer is a main queue thing.

Of course, when a timer goes off and calls a method, you could dispatch_async to another queue in that method, that's fine. It's just that the actual firing of the timer, that has to be happening in the main queue, for the purposes of this class.

So what's the main method look like in NSTimer? Notice that it's a class method, a static method on the class. So you invoke this by saying NSTimer.scheduled Time With Time Interval. And you just specify how many seconds from now you want this timer to go off for the first time, and then you specify a target or selector.

That's the method in the object that you want to be called. You got this user info, that's basically a cookie. You can put anything you want in there, some context, whatever you can leave it nil if you want. And then repeat is whether it's going to go off again in this many seconds, at the beginning there, and then just keep going off, over and over and over. So it couldn't really be simpler than that.

Now a bit of warning, if we call invalidate on a timer, that timer is no longer valid, and we should not do anything with it. We can't restart it. There's nothing we can do with it. And so it's usually a pretty bad idea to have a strong pointer to an NSTimer. Because we've got the strong pointer, we invalidate it. Now we've got a strong pointer to something that's invalid. So it's much better to make our pointers to NSTimers be weak. And when we do that, if we hit invalidate, no one will have a strong pointer to it anyone. And it'll leave the heap, and our  weak variable will get set to nil. So I recommend using weak pointers to NSTimers. Or not having any at all because remember every time it fires, we get this timer passed back to us as the argument if we want it.

Tolerance

It might help system performance to set a tolerance for "late firing". We can specify in the timer a tolerance, and that's basically how much we're willing to accept some slop in its calculation of when it goes off. Why would we want this tolerance? Because other things are going on in the system, and if we really don't care about getting it right on time, then maybe the system can be more efficient about how it's using its processor and other resources during that time. Notice that this tolerance doesn't cause drift. So if the first time it goes off, it goes off a minute and seven seconds after the next time it's going to go off, try to go off two minutes from the beginning. And the next time, three minutes from the beginning, it's not drifting. If it's late on one, it doesn't start being late on the next one.

What if I wanted to put all my blinking stuff in another class? In other words, I didn't want to put blinking in. We can use inheritance, this is object-oriented programming. It's not uncommon to create a subclass of another MVC's controller to create a controller you want for your MVC.

We didn't make it private. One of the interesting things about swift is that there's no idea of protected. What does protected mean? Private means you can only use it in this class, public means you can use it outside the framework you're in. Everything in swift is internal, which means you can use anything, anywhere, inside the framework you're in, including your app is kind of like a framework. So this view is really available to any class that's inside our app.

That's nice, but it would be maybe better if there were another protection class called protected. And, what that would mean is, only subclasses can use this thing. If we want something to be subclassable, and it's used in a subclass, we have to leave it internal.

So now how are we going to do this thing where wait a moment and open them? Use timer. The target is going to be our self. Now there is a restriction on this self, the same restriction we had with the other. A pound sign selector type of APIs, which is that this class that's receiving this has to be available to the Objective C run time. And so that means it essentially has to inherit from MS Object.

Now luckily, self, no problem because we inherit from faceviewcontroller, which inherit from UIViewController which inherits eventually from NSObjects. So we're all good to go here, but just don't get too confused if you try and do this and it's like it doesn't work. Because the object you send this message to has to be Objective C compatible. So the selector we want here, a method.

Eyes closed for one second, eyes opened for one second. They're two different timers. This has to be an Objective C compatible method.

Why is it making me put Objective C there? And the answer is because I made it private. Private methods get exposed to objective C. So they inject a C run time. So note as well. It has to be public method, or otherwise exposed to Objective C. Which we can do with that sign over J C as well.

I actually don't need this timer. Because I don't have any user info, it's not a repeating timers that I would want to invalidate.