views:

112

answers:

2

In in my app, say it count downs to something and at the end just beeps forever until the user quits the app, is it safe to say have an NSTimer and never release (or in NSTimer's case, invalidate it) it, since it will need to stay until the user quits the app?

+1  A: 

Yes you can! If I were you though, I would initialize it in the app delegate, in applicationDidFinishLoading and invalidate it in applicationWillTerminate.

notnoop
Problem is then I have to make ivars for the 3 objects that will stay until the app quits.. because those 3 objects are made in the view controller.
Mk12
What would be the difference between releasing/invalidating in applicationWillTerminate and dealloc of the viewController?
Mk12
not much, if the viewController is the root view controller. Any case, you should always release an object in the dealloc of where it is initalized. While it doesn't matter now, it may save you some debugging time when you change the view controllers order.
notnoop
It is best to invalidate, release and set to nil in the -dealloc as a matter of habit. In most cases, the app controller's -dealloc will never actually run (ObjC doesn't guarantee the running of -dealloc on program termination), but it's still a very good habit to get into as msaeed points out. There is no danger in "leaking" memory this way because Unix will recover all memory when the application terminates (unlike some mobile operating systems where this is a serious problem).
Rob Napier
You're not supposed to release timers created with NSTimer's scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:, like I'm using, only invalidate. But if it is an ivar, does that mean you need to release still? And why set to nil?
Mk12
It just makes everything so much simpler if I don't maker ivars out of the timers, because they won't ever be created unless the user lets the app run until the countdown finishes, so if dealloc gets called before then, the timer ivars are invalidated and released (because the properties retained them) when they never got created... but in the end it doesn't matter because the app will quit anyway..
Mk12
I mean, the main view controller never gets deallocated, so why deallocate its timer when the app quits?
Mk12
+2  A: 

Technically, yes, but I've found two things to be true:

  • This is an easy habit to get in to, convincing yourself that X doesn't need to be released because you've convinced yourself it needs to live forever when it doesn't and leaks, or
  • At some point in the future you'll realize you really want to be able to control that timer after all, and setting up the ivar now will save you a heap of trouble down the road (no pun intended)
fbrereto
Someone suggested using applicationWillTerminate. What's the point of using that method? Why don't I release everything (the window, the view controller) that needs to stay there? Do you think I should just release it in its own dealloc?
Mk12
Not quite sure what you mean by releasing an item in its own dealloc; dealloc is only called when the item is released, so if you release it (in dealloc) only after its been released (why dealloc got called) you'll never release it :) I'll second the move to use applicationWillTerminate -- the OS will call this routine for your application delegate right before the application terminates, giving you a chance to do any memory cleanup, etc., that needs to be done before your app finally quits.
fbrereto
What I mean is I'd have to make ivars out of the timers (they're in the root view controller class) and then shouldn't I release those ivars in dealloc of the root view controller?.. I mean a lot of things need to stay until the user quits in apps. Why don't you release the view controller and everything else in applicationWillTerminate?
Mk12
And the timer may have never even been started when the application terminates..
Mk12
By its own dealloc I meant in the class its used in, since it will need to be an ivar for it to be released in anything other than the method it is declared in.
Mk12