views:

34

answers:

1

Example: I have an warning triangle icon, which is a UIImageView subclass. That warning is blended in with an animation, pulses for 3 seconds and then fades out.

  • it always has a parent view!

  • it's always only used this way: alloc, init, add as subview, kick off animation, when done:remove from superview.

So I want this:

[WarningIcon warningAtPosition:CGPointMake(50.0f, 100.0f) parentView:self];

BANG!

That's it. Call and forget.

The view adds itself as subview to the parent, then does it's animations. And when done, it cuts itself off from the branch with [self removeFromSupeview];. And to make sure the procedure can finish really after this, make a nifty -retain and -autorelease couple so the whole thing can complete and return before it really gets trashed.

Now some nerd a year ago told me: "Never cut yourself off from your own branch". In other words: A view should never ever remove itself from superview if it's no more referenced anywhere.

I want to get it, really. WHY? Think about this: The hard way, I would do actually the exact same thing. Create an instance and hang me in as delegate, kick off the animation, and when the warning icon is done animating, it calls me back "hey man i'm done, get rid of me!" - so my delegate method is called with an pointer to that instance, and I do the exact same thing: [thatWarningIcon removeFromSuperview]; - BANG.

Now I'd really love to know why this sucks. Life would be so easy.

+1  A: 

I have no objections to your solution—especially with the [[self retain] autorelease]. I'm using the same approach from time to time myself.

You should go and ask the no-branch-cutter-nerd about his reasoning (and post this information here).

Nikolai Ruhe
+1 on that. Sometimes, like here, you *want* to "cut yourself off from your own branch". Typical trick of the trade.
Joseph Beckenbach