Take the 2-minute tour ×

I am using the following NSNotifications within a UIView so that the view can be notified when a UIKeyboard appears and adjust its position (frame) on screen:


The two notifications above are being subscribed to within the -init method of the UIView. Where is the best place to unsubscribe from these notifications once the view has disappeared off-screen? At the moment the app is crashing whenever the UIKeyboard appears in another view, presumably because a notification is still being sent to the then released UIView.

Also, is there a better place to be subscribing to the notifications, apart from within the -init method?

Thanks for any assistance.

share|improve this question
add comment

7 Answers

up vote 10 down vote accepted

-[UIView willMoveToWindow:] and -[UIView didMoveToWindow] are called even when a view is removed from a window. The window argument (or the window property in the case of -didMoveToWindow) will be nil in that case, i. e.:

- (void)willMoveToWindow:(UIWindow *)newWindow {
    if (newWindow == nil) {
        // Will be removed from window, similar to -viewDidUnload.
        // Unsubscribe from any notifications here.

- (void)didMoveToWindow {
    if (self.window) {
        // Added to a window, similar to -viewDidLoad.
        // Subscribe to notifications here.

Except for a few edge cases this is a safe way to do it. If you need more control, you can observe the hidden property of the window to which your view belong.

share|improve this answer
I like this method as it suits my use-case much better. Can anyone see any downsides? I am also removing the observer in the -dealloc method as a fail safe. –  Skoota Nov 21 '11 at 10:38
add comment

I put my removeObserver: calls in -dealloc.

Haven't had any problems so far.

share|improve this answer
Thanks, that's what I was thinking but wasn't sure whether it was the most suitable place - although if you haven't had any problems then it might be the best. –  Skoota Nov 20 '11 at 10:17
My thinking is dealloc is the last thing that should be called on an object, so it's best to put it there. –  Tom Irving Nov 20 '11 at 11:04
add comment

The definitive answer (e.g. ensure that an object is no longer reference by NSNotificationCenter when its lifecycle ends) is to do as @Tom suggests and remove itself as an observer in dealloc.

The subjective answer is it is also good practice to stop observing whenever the notifications are no longer relevant to the object. This is completely up to you to decide based on the design of your app. For example, if you have views that stay alive but come in and out of view you may decide to start observing when they are added to a subview and stop observing when they are removed.

WRT where the notification logic should reside (in a view vs in a controller), that's also up to you, obviously it can work both ways. I would make the decision based on the circumstances. If handling the notification in the view requires pushing app logic into the view (i.e. treating the view like a controller) then that's a red flag.

share|improve this answer
add comment

You can create a seperate function for adding and removing observes and then later you can all those functions from the view's instance. By the way for your question's answer I would have remove the observers before removing the view itself from superview. I hope you understand.

share|improve this answer
Thanks for your reply - I was hopping for a neater way than manually having to call those methods from the superview (i.e. view controller class) so I am thinking that the -dealloc method mentioned by Tom might be the best. –  Skoota Nov 20 '11 at 10:19
add comment

First, you should consider when you want to stop receiving notifications:

  1. When view is deallocated
  2. When view is disappeared

You should always check if your view observes notifications and call -removeObserver: in -dealloc. In addition if you consider 2, override -viewWillDisappear or -viewDidDisappear or any other point where you manipulate view hierarchy of view's UIViewController.

I recommend you to put the logic into UIViewController because in terms of relationships UIView doesn't own its frame.

share|improve this answer
add comment

To unsubscribe you can use

- (void)removeObserver:(id)notificationObserver


- (void)removeObserver:(id)notificationObserver name:(NSString *)notificationName object:(id)notificationSender

Both methods are NSNotificationCenter's instance methods.

Take a look at NSNotificationCenter Class Reference

share|improve this answer
Thanks, but I am already aware of the methods to unsubscribe. I am mainly interested in the best-practice placement of these methods within a UIView class. –  Skoota Nov 20 '11 at 10:16
add comment

As a practice for keyboard notifications, I normally use








works great for me everytime and it ensures that no keyboard notification is passed to a view which is not on screen which keeps the app safe from crashing due to false keyboard notofications.

share|improve this answer
Thanks, but those are only methods in a UIViewController. I am purely using a UIView. –  Skoota Nov 20 '11 at 10:16
no issues. you can create a custom class extending UIView and then override viewWillAppear and viewWillDisappear and make this implementation. Then use this class instead or Native UIview.. –  samfisher Nov 20 '11 at 10:17
as for keeping remove observer in dealloc is little more unsafe than keeping it in viewWillDisappear –  samfisher Nov 20 '11 at 10:19
add comment

Your Answer


