2

Say I have an object that should exist as a singleton for the whole life of the app. Is it okay for this object to contain, say, a strong reference to an NSTimer with itself as the timer's target? This will be a retain cycle, but I don't see any downside. When the OS tries to free memory, it doesn't necessary call dealloc anyway.

jscs
  • 63,694
  • 13
  • 151
  • 195
Bradley Thomas
  • 4,060
  • 6
  • 33
  • 55
  • I'm wondering: Do you eventually invalidate the timer? Do you eventually set the timer reference to nil? In other words, I understand the point of a singleton object that lives forever, but is there a point to having an NSTimer object that lives forever? – matt Mar 29 '14 at 21:20
  • If the timer is meant to run for the life of the application, I wonder why would I ever need to invalidate or set to nil... is there any reason other than just to cleanup? What would be the purpose of such a cleanup? – Bradley Thomas Mar 29 '14 at 21:23
  • NSTimer shouldn't be retained by you. It is retained by the system when it is added to NSRunLoop. – Rafał Augustyniak Mar 29 '14 at 21:27
  • 1
    @Rafal There's nothing wrong with retaining NSTimer. – matt Mar 29 '14 at 21:30
  • If the object exists for the whole life of the app, then is perfectly ok to have a retain cycle. Since you never need it to be deallocated, a retain cycle won't hurt in any way. – Ramy Al Zuhouri Mar 29 '14 at 21:33

2 Answers2

3

It sounds fine. You have a singleton object, meaning that once created it will persist for the lifetime of the app. To accompany it, you have a timer that will also persist for the lifetime of the app. So once you have ensured their persistence (i.e. they are both retained), there is no memory to manage. They will both live as long as the app does and in this case that is exactly what you want. The fact that there is a retain cycle in the story (because of NSTimer's peculiarities) is, as your question implies, almost secondary.

matt
  • 515,959
  • 87
  • 875
  • 1,141
0

There is no retain cycle. The timer releases its target once it has finished firing.

A retain cycle is when two objects retain each other forever. Not when it's temporary.

Abhi Beckert
  • 32,787
  • 12
  • 83
  • 110
  • OP's comment under the question strongly implies that this is a repeating timer. – jscs Mar 30 '14 at 01:32
  • @JoshCaswell yeah but if it's a repeating timer then it must be needed for some reason? And once you stop it from repeating, it will release it's target. – Abhi Beckert Mar 30 '14 at 01:33
  • @AbhiBeckert Read what I asked him and what he said, in the comments. Timer never stops (it's like a jazz drum solo :) – matt Mar 30 '14 at 01:35
  • Right; what's obvious to you and me (if you need it to stick around, it must be retained) doesn't seem to be obvious to the asker. Hence the question. – jscs Mar 30 '14 at 01:36
  • @JoshCaswell and hence my answer, which is different to matt's one - he avoids the NSTimer component altogether. A retain cycle is fine when one object is a singleton but that doesn't change the fact that this is not a retain cycle. – Abhi Beckert Mar 30 '14 at 03:19