Mam teoretyczne pytanie. Teraz czytam przewodnik Apple ViewController .

Oni napisali:

Kiedy przychodzi czas na odrzucenie kontrolera widoku prezentowanego, preferowanym podejściem jest pozwolenie kontrolerowi widoku prezentacji na odrzucenie go. Innymi słowy, gdy tylko jest to możliwe, ten sam kontroler widoku, który przedstawił kontrolera widoku, powinien również wziąć odpowiedzialność za jego odwołanie. Chociaż istnieje kilka technik powiadamiania kontrolera widoku prezentującego, że jego kontroler widoku prezentowanego powinien zostać odrzucony, preferowaną techniką jest delegowanie.

Ale nie potrafię wyjaśnić, dlaczego muszę stworzyć protokół w przedstawionym VC i dodać zmienną delegata, stworzyć metodę delegata w prezentacji VC dla odrzucenia prezentowanego VC, zamiast prostego wywołania w przedstawionym widoku metoda kontrolera

[self dismissViewControllerAnimated:NO completion:nil]?

Dlaczego pierwszy wybór jest lepszy? Dlaczego Apple to poleca?

Myślę, że Apple zakrywa trochę swoje plecy, aby uzyskać potencjalnie niezdarny kawałek API.

  [self dismissViewControllerAnimated:NO completion:nil]

Właściwie to trochę skrzypce. Chociaż możesz - słusznie - wywołać to na kontrolerze prezentowanego widoku, wszystko, co robi, to przekazuje wiadomość do kontrolera widoku prezentacji. Jeśli chcesz zrobić coś więcej niż tylko odrzucenie VC, musisz to wiedzieć i musisz traktować to w taki sam sposób, jak metodę delegata - ponieważ to jest prawie to, co jest, nieco nieelastyczne metoda delegata.

Być może natknęli się na mnóstwo złego kodu przez ludzi, którzy tak naprawdę nie rozumieli, jak to się robi, stąd ich ostrożność.

Ale oczywiście, jeśli wszystko, co musisz zrobić, to odrzucić sprawę, śmiało.

Moje własne podejście jest kompromisem, przynajmniej przypomina mi o co chodzi:

  [[self presentingViewController] dismissViewControllerAnimated:NO completion:nil]

[Szybki]

  self.presentingViewController?.dismiss(animated: false, completion:nil)

Zaktualizowano dla Swift 3

Przyszedłem tutaj, chcąc odrzucić obecny (przedstawiony) kontroler widoku. Podaję tę odpowiedź każdemu, kto przyjeżdża tutaj w tym samym celu.

Kontroler nawigacji

Jeśli używasz kontrolera nawigacyjnego, jest to dość łatwe.

Wróć do poprzedniego kontrolera widoku:

// Swift
self.navigationController?.popViewController(animated: true)

// Objective-C
[self.navigationController popViewControllerAnimated:YES];

Wróć do głównego kontrolera widoku:

// Swift
self.navigationController?.popToRootViewController(animated: true)

// Objective-C
[self.navigationController popToRootViewControllerAnimated:YES];

(Dzięki tej odpowiedzi dla Objective-C.)

Kontroler widoku modalnego

Gdy kontroler widoku jest prezentowany modalnie, możesz go odrzucić (z drugiego kontrolera widoku), wywołując

// Swift
self.dismiss(animated: true, completion: nil)

// Objective-C
[self dismissViewControllerAnimated:YES completion:nil];

Dokumentacja mówi,

Kontroler widoku prezentacji jest odpowiedzialny za odrzucenie kontrolera widoku, który przedstawił. Jeśli wywołasz tę metodę na samym kontrolerze widoku prezentowanego, UIKit prosi kontroler widoku prezentacji o obsługę odrzucenia.

Tak więc działa, aby kontroler widoku przedstawionego wywoływał go sam. Oto pełny przykład.

Delegaci

Pytanie PO dotyczyło złożoności wykorzystania delegatów do odrzucenia opinii.

• Ta odpowiedź Objective-C jest dość obszerna.
• Oto przykład Swift.

Do tej pory nie potrzebowałem używać delegatów, ponieważ zwykle mam kontroler nawigacji lub kontrolery widoku modalnego, ale jeśli będę musiał używać wzorca delegata w przyszłości, dodam aktualizację.

Służy to do ponownego wykorzystania kontrolera widoku.

Twój kontroler widoku nie powinien przejmować się tym, czy jest prezentowany jako modalny, wypychany na kontrolerze nawigacji czy cokolwiek innego. Jeśli kontroler widoku sam się odrzuca, to zakładasz, że jest prezentowany modalnie. Nie będzie można wypchnąć tego kontrolera widoku na kontroler nawigacyjny.

Implementując protokół, pozwalasz nadrzędnemu kontrolerowi widoku zdecydować, w jaki sposób ma być prezentowany / wypychany i odrzucany / otwierany.

Spróbuj tego:

[self dismissViewControllerAnimated:true completion:nil];

Z mojego doświadczenia wynika, że ​​przydaje się, gdy trzeba usunąć go z dowolnego kontrolera ViewController i wykonać różne zadania dla każdego kontrolera widoku, który go odrzuca. Każdy kontroler viewController, który przyjmuje protokół, może odrzucić widok na swój własny sposób. (iPad vs iPhone lub przekazywanie różnych danych podczas zamykania z różnych widoków, wywoływanie różnych metod podczas zamykania itp.)

Edytować:

Tak więc, aby wyjaśnić, jeśli wszystko, co kiedykolwiek chcesz zrobić, to odrzucić widok, nie widzę potrzeby konfigurowania protokołu delegata. Jeśli musisz zrobić inne rzeczy po usunięciu go z różnych kontrolerów widoku prezentacji, najlepszym sposobem byłoby skorzystanie z delegata.

Cytuj z Przewodnika programowania kontrolerów firmy View , „Jak kontrolery przedstawiają inne kontrolery widoku”.

Każdy kontroler widoku w łańcuchu kontrolerów widoku prezentowanego ma wskaźniki do innych obiektów otaczających go w łańcuchu. Innymi słowy, prezentowany kontroler widoku, który przedstawia inny kontroler widoku, ma prawidłowe obiekty we właściwościach PresentViewController i PresentViewController. W razie potrzeby można użyć tych relacji do prześledzenia łańcucha kontrolerów widoku. Na przykład, jeśli użytkownik anuluje bieżącą operację, możesz usunąć wszystkie obiekty w łańcuchu, odrzucając pierwszy przedstawiony kontroler widoku. Odrzucenie kontrolera widoku odrzuca nie tylko ten kontroler widoku, ale także wszystkie kontrolery widoku, które przedstawił.

Z jednej strony zapewnia to ładną, wyważoną konstrukcję, dobre odsprzęganie itp. Ale z drugiej strony jest to bardzo praktyczne, ponieważ można szybko wrócić do określonego punktu w nawigacji.

Chociaż osobiście wolałbym raczej używać rozwijania segmentów niż próbować przechodzić wstecz przez drzewo kontrolerów widoku prezentacji , o czym Apple mówi w tym rozdziale, skąd pochodzi cytat.

Po pierwsze, jest to dobre podejście do kodowania. Spełnia wiele OOPzasad, np. SRP, Separacja problemów itp.

Zatem kontroler widoku prezentujący widok powinien być tym, który go odrzuca.

Na przykład firma zajmująca się obrotem nieruchomościami, która daje dom do wynajęcia, powinna być upoważniona do jego zwrotu.

Swift 3.0 // Szybko zamknij kontroler widoku

self.navigationController?.popViewController(animated: true)
dismiss(animated: true, completion: nil)

Oprócz odpowiedzi Michaela Enriqueza przychodzi mi do głowy jeszcze jeden powód, dla którego może to być dobry sposób na ochronę przed nieokreślonym stanem:

Powiedz, że ViewControllerA przedstawia ViewControllerB modalnie. Ale ponieważ być może nie napisałeś kodu dla ViewControllerA, nie znasz cyklu życia ViewControllerA. Może odrzucić 5 sekund (powiedzmy) po zaprezentowaniu kontrolera widoku, ViewControllerB.

W tym przypadku, jeśli po prostu używasz dismissViewController ViewControllerB do odrzucenia samego siebie, skończyłbyś w niezdefiniowanym stanie - być może nie awarią lub czarnym ekranem, ale stan niezdefiniowany z twojego punktu widzenia.

Gdybyś zamiast tego używał wzorca delegata, byłbyś świadomy stanu ViewControllerB i możesz zaprogramować przypadek taki jak ten, który opisałem.

Szybki

let rootViewController:UIViewController = (UIApplication.shared.keyWindow?.rootViewController)!

        if (rootViewController.presentedViewController != nil) {
            rootViewController.dismiss(animated: true, completion: {
                //completion block.
            })
        }

Jeśli używasz modalnego widoku, odrzuć.

[self dismissViewControllerAnimated:NO completion:nil];

To dużo bzdur. Delegacja jest w porządku, gdy jest potrzebna, ale jeśli sprawia, że ​​kod jest bardziej złożony - a tak się dzieje - musi być ku temu powód.

Jestem pewien, że Apple ma swoje powody. Ale jaśniejsze i bardziej zwięzłe jest po prostu zlecenie przedstawionego VC odrzucenia, chyba że istnieje prawdziwy powód, by postąpić inaczej i nikt tutaj do dziś nie przedstawił takiego, który widzę.

Protokoły są doskonałe, gdy są potrzebne, ale w projektowaniu zorientowanym obiektowo nigdy nie chodziło o niepotrzebną komunikację modułów ze sobą.

Tom Love (współtwórca Objective C) powiedział kiedyś, że Objective C jest „elegancki”, „mały”, „ostry” i „dobrze zdefiniowany” (w porównaniu z C ++). Łatwo mu powiedzieć. Delegowanie to przydatna funkcja, która wydaje się być nadużywana „tylko dlatego”, i chociaż lubię pracować w języku, obawiam się, że będę zmuszony używać niepotrzebnej składni, aby uczynić rzeczy bardziej złożonymi, niż jest to konieczne.

Możesz zamknąć okno super widoku

self.view.superview?.window?.close()