Cel-C: Gdzie usunąć obserwatora do NSNotification?

Mam obiektywną klasę C. W nim stworzyłem metodę init i ustawiłem w niej NSNotification

//Set up NSNotification
[[NSNotificationCenter defaultCenter] addObserver:self 
                                         selector:@selector(getData)
                                             name:@"Answer Submitted"
                                           object:nil];

Gdzie mam ustawić [[NSNotificationCenter defaultCenter] removeObserver:self]w tej klasie? Wiem, że w przypadku a UIViewControllermogę dodać to do viewDidUnloadmetody. Co więc należy zrobić, jeśli właśnie utworzyłem obiektywną klasę c?

Ogólna odpowiedź brzmiałaby: „gdy tylko nie będziesz już potrzebować powiadomień”. To oczywiście nie jest satysfakcjonująca odpowiedź.

Poleciłbym dodać wywołanie [notificationCenter removeObserver: self]w metodzie dealloctych klas, których zamierzasz używać jako obserwatorów, ponieważ jest to ostatnia szansa na czyste wyrejestrowanie obserwatora. To jednak ochroni Cię tylko przed awariami, ponieważ centrum powiadomień powiadamia o martwych obiektach. Nie może chronić Twojego kodu przed otrzymywaniem powiadomień, gdy Twoje obiekty nie są jeszcze / nie są w stanie, w którym mogą poprawnie obsłużyć powiadomienie. Do tego ... Patrz wyżej.

Edytuj (ponieważ odpowiedź wydaje się przyciągać więcej komentarzy, niż bym myślał) Wszystko, co próbuję tutaj powiedzieć, to: naprawdę trudno jest udzielić ogólnej porady, kiedy najlepiej usunąć obserwatora z centrum powiadomień, ponieważ to zależy:

• W Twoim przypadku użycia (Które powiadomienia są obserwowane? Kiedy są wysyłane?)
• Realizacja obserwatora (Kiedy jest gotowy do otrzymywania powiadomień? Kiedy nie jest już gotowy?)
• Planowany czas życia obserwatora (czy jest powiązany z jakimś innym obiektem, powiedzmy, widokiem lub kontrolerem widoku?)
• ...

A więc najlepsza ogólna rada, jaką mogę wymyślić: ochrona aplikacji. przeciwko przynajmniej jednej możliwej awarii, removeObserver:zatańcz dealloc, ponieważ to ostatni punkt (w życiu obiektu), w którym możesz to zrobić czysto. Nie oznacza to: „po prostu odłóż usunięcie do momentu deallocwywołania, a wszystko będzie dobrze”. Zamiast tego usuń obserwatora, gdy tylko obiekt nie jest już gotowy (lub wymagany) do otrzymywania powiadomień . To jest właściwy moment. Niestety, nie znając odpowiedzi na którekolwiek z powyższych pytań, nie potrafię nawet zgadnąć, kiedy to nastąpi.

Zawsze możesz bezpiecznie removeObserver:obiekt wiele razy (i wszystkie oprócz pierwszego wywołania z danym obserwatorem to nops). A więc: pomyśl o zrobieniu tego (ponownie) deallocdla pewności, ale przede wszystkim: zrób to w odpowiednim momencie (który jest określony przez twój przypadek użycia).

Uwaga: to zostało przetestowane i działa w 100%

Szybki

override func viewWillDisappear(animated: Bool){
    super.viewWillDisappear(animated)

    if self.navigationController!.viewControllers.contains(self) == false  //any other hierarchy compare if it contains self or not
    {
        // the view has been removed from the navigation stack or hierarchy, back is probably the cause
        // this will be slow with a large stack however.

        NSNotificationCenter.defaultCenter().removeObserver(self)
    }
}

PresentedViewController

override func viewWillDisappear(animated: Bool){
    super.viewWillDisappear(animated)

    if self.isBeingDismissed()  //presented view controller
    {
        // remove observer here
        NSNotificationCenter.defaultCenter().removeObserver(self)
    }
}

Cel C

W programie iOS 6.0 > versionlepiej jest usunąć obserwatora, viewWillDisappearponieważ viewDidUnloadmetoda jest przestarzała.

 [[NSNotificationCenter defaultCenter] removeObserver:observerObjectHere];

Wiele razy lepiej jest, remove observergdy widok został usunięty z pliku navigation stack or hierarchy.

- (void)viewWillDisappear:(BOOL)animated{
 if (![[self.navigationController viewControllers] containsObject: self]) //any other hierarchy compare if it contains self or not
    {
        // the view has been removed from the navigation stack or hierarchy, back is probably the cause
        // this will be slow with a large stack however.

        [[NSNotificationCenter defaultCenter] removeObserver:observerObjectHere];
    }
}

PresentedViewController

- (void)viewWillDisappear:(BOOL)animated{
    if ([self isBeingDismissed] == YES) ///presented view controller
    {
        // remove observer here
        [[NSNotificationCenter defaultCenter] removeObserver:observerObjectHere];
    }
}

Od iOS 9 nie trzeba już usuwać obserwatorów.

W OS X 10.11 i iOS 9.0 NSNotificationCenter i NSDistributedNotificationCenter nie będą już wysyłać powiadomień do zarejestrowanych obserwatorów, którzy mogą zostać zwolnieni.

https://developer.apple.com/library/mac/releasenotes/Foundation/RN-Foundation/index.html#10_11NotificationCenter

Jeśli obserwator jest dodany do kontrolera widoku , zdecydowanie polecam dodanie go viewWillAppeari usunięcie go viewWillDisappear.

-(void) dealloc {
      [[NSNotificationCenter defaultCenter] removeObserver:self];
      [super dealloc];
}

Generalnie umieściłem to w deallocmetodzie.

W szybkim użyciu deinit, ponieważ dealloc jest niedostępny:

deinit {
    ...
}

Szybka dokumentacja:

Deinitializer jest wywoływany bezpośrednio przed cofnięciem przydziału instancji klasy. Piszesz deinicjalizatory za pomocą słowa kluczowego deinit, podobnie jak w przypadku pisania intializatorów za pomocą słowa kluczowego init. Deinicjatory są dostępne tylko dla typów klas.

Zazwyczaj nie ma potrzeby ręcznego czyszczenia, gdy Twoje instancje są zwalniane. Jednak podczas pracy z własnymi zasobami może być konieczne samodzielne wykonanie dodatkowych czynności porządkowych. Na przykład, jeśli utworzysz klasę niestandardową w celu otwarcia pliku i zapisania w nim danych, może być konieczne zamknięcie pliku przed zwolnieniem instancji klasy.

* edycja: ta rada dotyczy iOS <= 5 (nawet tam powinieneś dodawać viewWillAppeari usuwać viewWillDisappear- jednak rada ma zastosowanie, jeśli z jakiegoś powodu dodałeś obserwatora viewDidLoad)

Jeśli dodałeś obserwatora w viewDidLoad, powinieneś usunąć go z obu dealloci viewDidUnload. W przeciwnym razie dodasz go dwukrotnie, gdy viewDidLoadzostanie wywołany po viewDidUnload(stanie się to po ostrzeżeniu dotyczącym pamięci). Nie jest to konieczne w iOS 6, gdzie viewDidUnloadjest przestarzałe i nie zostanie wywołane (ponieważ widoki nie są już automatycznie zwalniane).

Moim zdaniem poniższy kod nie ma sensu w ARC :

- (void)dealloc
{
      [[NSNotificationCenter defaultCenter] removeObserver:self];
      [super dealloc];
}

W iOS 6 również nie ma sensu usuwać obserwatorów viewDidUnload, ponieważ jest teraz przestarzały.

Podsumowując, zawsze to robię viewDidDisappear. Zależy to jednak również od twoich wymagań, tak jak powiedział @Dirk.

Myślę, że znalazłem wiarygodną odpowiedź ! Musiałem, ponieważ powyższe odpowiedzi są niejednoznaczne i wydają się sprzeczne. Przejrzałem książki kucharskie i przewodniki programowania.

Po pierwsze, styl addObserver: in viewWillAppear:i removeObserver:in viewWillDisappear:nie działa dla mnie (przetestowałem go), ponieważ wysyłam powiadomienie w kontrolerze widoku podrzędnego, aby wykonać kod w kontrolerze widoku nadrzędnego. Użyłbym tego stylu tylko wtedy, gdybym publikował i nasłuchiwał powiadomienia w tym samym kontrolerze widoku.

Odpowiedź, na której będę polegać najbardziej, znalazłem w iOS Programming: Big Nerd Ranch Guide 4. Ufam chłopakom z BNR, ponieważ mają centra szkoleniowe iOS i nie piszą tylko kolejnej książki kucharskiej. Dokładność prawdopodobnie leży w ich najlepszym interesie.

Przykład pierwszy BNR: addObserver: in init:, removeObserver:indealloc:

BNR, przykład drugi: addObserver: in awakeFromNib:, removeObserver:indealloc:

… Po usunięciu obserwatora dealloc:nie używają[super dealloc];

Mam nadzieję, że pomoże to następnej osobie…

Aktualizuję ten post, ponieważ Apple prawie całkowicie odszedł od Storyboardów, więc powyższe może nie dotyczyć wszystkich sytuacji. Ważną rzeczą (i powodem, dla którego dodałem ten post w pierwszej kolejności) jest zwracanie uwagi, jeśli ktoś viewWillDisappear:dzwoni. To nie dla mnie, gdy aplikacja weszła w tło.

Zaakceptowana odpowiedź nie jest bezpieczna i może spowodować wyciek pamięci. Proszę zostawić wyrejestrowanie w dealloc, ale także wyrejestrowanie w widoku Zniknie (to jest oczywiście, jeśli zarejestrujesz się w viewWillAppear) .... TO CO ZROBIŁEM I DZIAŁA WSPANIAŁE! :)

Należy również to zauważyć viewWillDisappear jest to wywoływane również wtedy, gdy kontroler widoku przedstawia nowy UIView. Ten delegat po prostu wskazuje, że główny widok kontrolera widoku nie jest widoczny na wyświetlaczu.

W takim przypadku cofnięcie przydziału powiadomienia w viewWillDisappear może być niewygodne, jeśli używamy powiadomienia, aby umożliwić komunikację interfejsu użytkownika z nadrzędnym kontrolerem widoku.

Jako rozwiązanie zwykle usuwam obserwatora jedną z tych dwóch metod:

- (void)viewWillDisappear:(BOOL)animated {
    NSLog(@"viewController will disappear");
    if ([self isBeingDismissed]) {
        NSLog(@"viewController is being dismissed");
        [[NSNotificationCenter defaultCenter] removeObserver:self name:@"actionCompleted" object:nil];
    }
}

-(void)dealloc {
    NSLog(@"viewController is being deallocated");
    [[NSNotificationCenter defaultCenter] removeObserver:self name:@"actionCompleted" object:nil];
}

Z podobnych powodów przy pierwszym zgłoszeniu muszę liczyć się z tym, że ilekroć widok z pojawi się nad kontrolerem viewWillAppearto odpalana jest metoda. To z kolei spowoduje wygenerowanie wielu kopii tego samego powiadomienia. Ponieważ nie ma sposobu, aby sprawdzić, czy powiadomienie jest już aktywne, rozwiązuję problem, usuwając powiadomienie przed dodaniem:

- (void)viewWillAppear:(BOOL)animated {
    NSLog(@"viewController will appear");
    // Add observers
    [[NSNotificationCenter defaultCenter] removeObserver:self name:@"imageGenerated" object:nil]; // This is added to avoid duplicate notifications when the view is presented again
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(receivedImageFromCameraOrPhotolibraryMethodOnListener:) name:@"actionCompleted" object:nil];

}

SWIFT 3

Istnieją dwa przypadki użycia powiadomień: - są potrzebne tylko wtedy, gdy kontroler widoku jest na ekranie; - są potrzebne zawsze, nawet jeśli użytkownik otworzył inny ekran nad prądem.

W pierwszym przypadku poprawne miejsce do dodania i usunięcia obserwatora to:

/// Add observers
///
/// - Parameter animated: the animation flag
override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    NotificationCenter.default.addObserver(...)
}

/// Remove observers
///
/// - Parameter animated: the animation flag
override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    NotificationCenter.default.removeObserver(self)
}

w drugim przypadku prawidłowy sposób to:

/// Add observers
override func viewDidLoad() {
    super.viewDidLoad()
    NotificationCenter.default.addObserver(...)
}

/// Remove observers
///
/// - Parameter animated: the animation flag
override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    if self.isBeingDismissed // remove only when view controller is removed disappear forever
    || !(self.navigationController?.viewControllers.contains(self) ?? true) {
        NotificationCenter.default.removeObserver(self)
    }
}

I nigdy nie umieścić removeObserverw deinit{ ... }- to błąd!

override func viewDidLoad() {   //add observer
  super.viewDidLoad()
  NotificationCenter.default.addObserver(self, selector:#selector(Yourclassname.method), name: NSNotification.Name(rawValue: "NotificationIdentifier"), object: nil)
}

override func viewWillDisappear(_ animated: Bool) {    //remove observer
    super.viewWillDisappear(true)
    NotificationCenter.default.removeObserver(self, name: NSNotification.Name(rawValue: "NotificationIdentifier"), object: nil)
}