#retain cycle

If you've done any coding with NSTimer and ARC you'll know the pain of having to manually invalidate your timer before its owner can be deallocated.

Typically, you'll have to have your object's parent reach into the object's inner workings and invalidate the timer at the appropriate time. This is inconvenient and breaks encapsulation.

I have a UITableViewCell which utilizes a NSTimer to keep track of energy regeneration, and I was determined to make it work without any outside intervention.

My solution was to utilize the UITableViewCell's willMoveToWindow: method like so:

- (void)willMoveToWindow:(UIWindow *)newWindow { [super willMoveToWindow:newWindow]; if (newWindow == (id)[NSNull null] || newWindow == nil) { [self stopTimer]; } else { [self refreshEnergy]; } } - (void)stopTimer { [timer invalidate]; timer = nil; } - (void)refreshEnergy { if (timer == nil) { timer = [NSTimer scheduledTimerWithTimeInterval:1.0f target:self selector:@selector(refreshEnergy) userInfo:nil repeats:YES]; } ... }

Now the UITableVIewCell automatically starts and stops the repeating timer as needed and deallocates correctly.

A note: You might try to simple use a weak reference to self in the NSTimer constructor but you'll find that the timer must be invalidated to deallocate correctly. This WON'T work:

Today was another day propelled more by caffeine than sleep.  Working on the Asteroids app until 4 in the morning was a lot of fun, and definitely worth it, but I felt it today.  Despite getting to sleep at such a late hour, I woke early and continued working on the app.  I was just having way too much fun with it.  Most of my preclass time was spent chasing down memory leaks. The game’s responsiveness was seriously decreasing as the  length of time playing it increased.  I found and zapped a few retain cycles which solved about 90% of the responsiveness issue.  Then after class I spent an extra hour on it and finally got it to 100% responsive all the time. 

During class we worked on a new app.  Robert and I were paired for this first time and we set to work on building an instagram clone.  This was my first experience controlling the iPhone's camera with objective C which proved to be fairly easy. We also got to learn about and experience modal views for the first time.   And Ned gave a very short lecture with one important imperative: Do not try to set another view's properties.  Set the view's model properties instead.  I had actually tried to do just that the other day, and had learned the long and hard way that doing so doesn't usually work.  The view properties you're trying to set probably haven't been instantiated yet, and are thus nil even after you set them.  Even if you know the view already has been instantiated, it's a bad idea because you can never be guaranteed that the view will still exist when you're trying to set it's properties.  If the iPhone is running low on memory, it will free some up by destroying views that aren't visible.  

The fact that Valve released a Portal 2 OST with Lisp references in song titles alone, explains why Valve is an unique place to work at. You don’t tile Mecca with the finest marble, though. Vestiges of greatness always simmer through the product.

Ship great, but don’t take forever. Make awesomely great products. Some people never get this, and get lost in a sea of mediocrity, others, perhaps, are complacent with meritocracy. Some are trapped in the netherlands, others are zombies from the stone age.