• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Right place to unobserve notifications in a document
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Right place to unobserve notifications in a document


  • Subject: Re: Right place to unobserve notifications in a document
  • From: Negm-Awad Amin <email@hidden>
  • Date: Mon, 18 Aug 2008 18:49:45 +0200


Am Mo,18.08.2008 um 18:18 schrieb Andy Lee:

On Aug 18, 2008, at 11:51 AM, Negm-Awad Amin wrote:
But anyway I do not think, that doing something else then memory management in -dealloc is good design. Normally I unregister observation in delegate methods like -applicationWillTerminate:.

I understand your concern -- you meant "functional overhead" in the sense of a design taboo, not a performance cost
Oh, yes, sorry for the ambigious statement.

I'm a fan of Knuths phrase, so I talk about performance very rarely.

-- but in this case I think -dealloc is not only okay, but sometimes the only correct place to unregister a notification. Suppose an invariant of your design is that an object should receive notifications as long as, and only as long as, the object exists. If you unregister too soon, you may have an "alive" object that fails to get a notification.
This is little bit a circular argumentation: I need it the whole lifetime, so i manage it the whole lifetime. Why do you need it until the instance becomes deconstructed?

I think this is the right pattern:
1. Construct and init the object
2. Let them work (register observations, handling threads, $whatever … )
3. Stop them
4. Deconstruct them

So there are 4 steps, not 2.

In former times I often finished functional work in -dealloc. This ofen works, no problem. But it is a poor design. Sure, you shouldn't develop for garbage collection and reference counting in the same code. But thinking about this can sometimes focus a problem with design. No design should depend on the memory management model accept of the memory managing itself, should it?

If unregister too late, the notification center will send the notification to a dangling pointer and your app will crash.
Of course you have to stop functional work before decnstrcuting the instance.

I think it's okay to unregister in -dealloc because conceptually it's related to releasing your ivars. You're explicitly dissolving a relationship between the object being dealloced and some other object -- a relationship you have to manually manage in the absence of garbage collection.
In this case it seems to be ok. Maybe this is the reason for the weak reference.

Thanks for your thoughts.

Cheers,
Amin



--Andy



Amin Negm-Awad email@hidden




_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Right place to unobserve notifications in a document
      • From: Andy Lee <email@hidden>
References: 
 >Right place to unobserve notifications in a document (From: Negm-Awad Amin <email@hidden>)
 >Re: Right place to unobserve notifications in a document (From: "Michael Ash" <email@hidden>)
 >Re: Right place to unobserve notifications in a document (From: Negm-Awad Amin <email@hidden>)
 >Re: Right place to unobserve notifications in a document (From: Andy Lee <email@hidden>)

  • Prev by Date: Address Book: updating a person's phone number info...
  • Next by Date: Re: Right place to unobserve notifications in a document
  • Previous by thread: Re: Right place to unobserve notifications in a document
  • Next by thread: Re: Right place to unobserve notifications in a document
  • Index(es):
    • Date
    • Thread