When I execute this code:
[NSTimer scheduledTimerWithTimeInterval:0.5 target:self selector:@selector(showButtons) userInfo:nil repeats:NO];
do I need to nil it or release it, ot whatever for memory management?
I am using ARC
When I execute this code:
[NSTimer scheduledTimerWithTimeInterval:0.5 target:self selector:@selector(showButtons) userInfo:nil repeats:NO];
do I need to nil it or release it, ot whatever for memory management?
I am using ARC
Yes, you can use:
myTimer=[NSTimer scheduledTimerWithTimeInterval:0.5 target:self selector:@selector(showButtons) userInfo:nil repeats:NO];
And then in your viewDidDisappear[myTimer invalidate]
If you are saving it in a property, then yes, you do need to set it to nil after it fired the selector.
It's also safe to save it in case your class gets deallocated for whatever reason, so that you can
[timer invalidate]
if you need to.Yes,
NSTimer
will maintain a strong reference to thetarget
, which can cause (especially in repeating timers) strong reference cycles (a.k.a. retain cycles). In your example, though, the timer does not repeat, and is delayed only 0.5, so worst case scenario, you will have a strong reference cycle that will automatically resolve itself in 0.5 seconds.But a common example of an unresolved strong reference cycle would be to have a
UIViewController
with aNSTimer
property that repeats, but because theNSTimer
has a strong reference to theUIViewController
, the controller will end up being retained.So, if you're keeping the
NSTimer
as an instance variable, then, yes, you shouldinvalidate
it, to resolve the strong reference cycle. If you're just calling thescheduledTimerWithTimeInterval
, but not saving it to an instance variable (as one might infer from your example), then your strong reference cycle will be resolved when theNSTimer
is complete.And, by the way, if you're dealing with repeating
NSTimers
, don't try toinvalidate
them indealloc
of the owner of theNSTimer
because thedealloc
obviously will not be called until the strong reference cycle is resolved. In the case of aUIViewController
, for example, you might do it inviewDidDisappear
.By the way, the Advanced Memory Management Programming Guide explains what strong reference cycles are. Clearly, this is in a section where they're describing the proper use of weak references, which isn't applicable here (because you have no control over the fact that
NSTimer
uses strong references to the target), but it does explain the concepts of strong reference cycles nicely.If you don't want your
NSTimer
to keep a strong reference toself
, in macOS 10.12 and iOS 10, or later, you can use the block rendition and then use theweakSelf
pattern:By the way, I notice that you're calling
showButtons
. If you're trying to just show some controls on your view, you could eliminate the use of theNSTimer
altogether and do something like:This doesn't suffer the retain issues of
NSTimer
objects, and performs both the delay as well as the graceful showing of the button(s) all in one statement. If you're doing additional processing in yourshowButtons
method, you can put that in thecompletion
block.