Dostać się do UIViewController z UIView?

Używając przykładu opublikowanego przez Brocka, zmodyfikowałem go tak, aby był kategorią UIView zamiast UIViewController i uczynił go rekurencyjnym, aby każdy subview mógł (miejmy nadzieję) znaleźć macierzysty UIViewController.

@interface UIView (FindUIViewController)
- (UIViewController *) firstAvailableUIViewController;
- (id) traverseResponderChainForUIViewController;
@end

@implementation UIView (FindUIViewController)
- (UIViewController *) firstAvailableUIViewController {
    // convenience function for casting and to "mask" the recursive function
    return (UIViewController *)[self traverseResponderChainForUIViewController];
}

- (id) traverseResponderChainForUIViewController {
    id nextResponder = [self nextResponder];
    if ([nextResponder isKindOfClass:[UIViewController class]]) {
        return nextResponder;
    } else if ([nextResponder isKindOfClass:[UIView class]]) {
        return [nextResponder traverseResponderChainForUIViewController];
    } else {
        return nil;
    }
}
@end

Aby użyć tego kodu, dodaj go do nowego pliku klasy (nazwałem mój" UIKitCategories") i usuń dane klasy... skopiuj interfejs @do nagłówka, a implementację @do .plik M. Następnie w projekcie# import " UIKitCategories.h " i używać w ramach UIView kod:

// from a UIView subclass... returns nil if UIViewController not available
UIViewController * myController = [self firstAvailableUIViewController];

UIView jest podklasą UIResponder. UIResponder określa metodę {[4] } z implementacją, która zwraca nil. UIView nadpisuje tę metodę, jak opisano w UIResponder (z jakiegoś powodu zamiast w UIView) w następujący sposób: jeśli Widok ma kontroler widoku, jest zwracany przez -nextResponder. Jeśli nie ma kontrolera widoku, metoda zwróci superview.

Dodaj to do swojego projektu i jesteś gotowy do pracy.

@interface UIView (APIFix)
- (UIViewController *)viewController;
@end

@implementation UIView (APIFix)

- (UIViewController *)viewController {
    if ([self.nextResponder isKindOfClass:UIViewController.class])
        return (UIViewController *)self.nextResponder;
    else
        return nil;
}
@end

Teraz UIView ma roboczą metodę zwracania widoku kontroler.

Sugerowałbym bardziej lekkie podejście do przechodzenia całego łańcucha odpowiedzi bez konieczności dodawania kategorii na UIView:

@implementation MyUIViewSubclass

- (UIViewController *)viewController {
    UIResponder *responder = self;
    while (![responder isKindOfClass:[UIViewController class]]) {
        responder = [responder nextResponder];
        if (nil == responder) {
            break;
        }
    }
    return (UIViewController *)responder;
}

@end

Łącząc kilka już udzielonych odpowiedzi, wysyłam na nią również swoją implementację:

@implementation UIView (AppNameAdditions)

- (UIViewController *)appName_viewController {
    /// Finds the view's view controller.

    // Take the view controller class object here and avoid sending the same message iteratively unnecessarily.
    Class vcc = [UIViewController class];

    // Traverse responder chain. Return first found view controller, which will be the view's view controller.
    UIResponder *responder = self;
    while ((responder = [responder nextResponder]))
        if ([responder isKindOfClass: vcc])
            return (UIViewController *)responder;

    // If the view controller isn't found, return nil.
    return nil;
}

@end

Kategoria jest częścią mojej biblioteki statycznejz obsługą ARC , którą wysyłam w każdej tworzonej aplikacji. Był testowany kilka razy i nie znalazłem żadnych problemów ani wycieków.

P. S.: nie musisz używać kategorii jak ja, jeśli dany widok jest twoją podklasą. W tym drugim przypadku po prostu umieść metodę w swojej podklasie i możesz iść.

Mimo, że technicznie można to rozwiązać jako pgb zaleca, IMHO, jest to wada projektowa. Widok nie powinien być świadomy kontrolera.

Zmodyfikowałem de odpowiedź, więc mogę przekazać dowolny widok, przycisk, Etykietę itp. aby uzyskać to rodzic UIViewController. Oto Mój kod.

+(UIViewController *)viewController:(id)view {
    UIResponder *responder = view;
    while (![responder isKindOfClass:[UIViewController class]]) {
        responder = [responder nextResponder];
        if (nil == responder) {
            break;
        }
    }
    return (UIViewController *)responder;
}

Edit Swift 3 Version

class func viewController(_ view: UIView) -> UIViewController {
        var responder: UIResponder? = view
        while !(responder is UIViewController) {
            responder = responder?.next
            if nil == responder {
                break
            }
        }
        return (responder as? UIViewController)!
    }

Edit 2: - Swift Extention

extension UIView
{
    //Get Parent View Controller from any view
    func parentViewController() -> UIViewController {
        var responder: UIResponder? = self
        while !(responder is UIViewController) {
            responder = responder?.next
            if nil == responder {
                break
            }
        }
        return (responder as? UIViewController)!
    }
}

Nie zapomnij, że możesz uzyskać dostęp do kontrolera widoku głównego dla okna, którego widok jest podglądem podrzędnym. Stamtąd, jeśli np. używasz kontrolera widoku nawigacyjnego i chcesz wypchnąć na niego nowy Widok:

    [[[[self window] rootViewController] navigationController] pushViewController:newController animated:YES];

Najpierw musisz jednak poprawnie skonfigurować właściwość rootviewcontroller okna. Zrób to, gdy po raz pierwszy utworzysz kontroler, np. w delegacie aplikacji:

-(void) applicationDidFinishLaunching:(UIApplication *)application {
    window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    RootViewController *controller = [[YourRootViewController] alloc] init];
    [window setRootViewController: controller];
    navigationController = [[UINavigationController alloc] initWithRootViewController:rootViewController];
    [controller release];
    [window addSubview:[[self navigationController] view]];
    [window makeKeyAndVisible];
}

Chociaż te odpowiedzi są poprawne technicznie, w tym Ushox, myślę, że zatwierdzony Sposób jest wdrożenie nowego protokołu lub ponowne wykorzystanie istniejącego. Protokół izoluje obserwatora od obserwowanego, coś w rodzaju umieszczania gniazda poczty między nimi. W efekcie Gabriel robi to za pomocą wywołania metody pushViewController; widok "wie", że właściwym protokołem jest grzeczne poproszenie navigationController o wypchnięcie widoku, ponieważ viewController jest zgodny z protokół navigationController. Chociaż możesz utworzyć własny protokół, wystarczy użyć przykładu Gabriela i ponownie użyć protokołu UINavigationController.

Nie sądzę, aby to był" zły " pomysł, aby dowiedzieć się, kto jest kontrolerem widoku w niektórych przypadkach. Co może być złym pomysłem jest, aby zapisać odniesienie do tego kontrolera, ponieważ może się zmienić tak jak superviews zmienić. W moim przypadku mam gettera, który przemierza łańcuch odpowiedzi.

//.h

@property (nonatomic, readonly) UIViewController * viewController;

//.m

- (UIViewController *)viewController
{
    for (UIResponder * nextResponder = self.nextResponder;
         nextResponder;
         nextResponder = nextResponder.nextResponder)
    {
        if ([nextResponder isKindOfClass:[UIViewController class]])
            return (UIViewController *)nextResponder;
    }

    // Not found
    NSLog(@"%@ doesn't seem to have a viewController". self);
    return nil;
}

Najprostsza pętla do while do znalezienia kontrolera viewcontrollera.

-(UIViewController*)viewController
{
    UIResponder *nextResponder =  self;

    do
    {
        nextResponder = [nextResponder nextResponder];

        if ([nextResponder isKindOfClass:[UIViewController class]])
            return (UIViewController*)nextResponder;

    } while (nextResponder != nil);

    return nil;
}

Natknąłem się na sytuację, w której mam mały komponent, który chcę ponownie wykorzystać, i dodałem trochę kodu w widoku wielokrotnego użytku (to naprawdę niewiele więcej niż przycisk otwierający PopoverController).

Chociaż działa to dobrze na iPadzie (UIPopoverController prezentuje się sam, dlatego nie wymaga odniesienia do UIViewController), uzyskanie tego samego kodu do pracy oznacza nagle odwołanie się do twojego presentViewController z twojego UIViewController. Trochę niekonsekwentne, prawda?

Jak wspomniano wcześniej, nie jest to najlepsze podejście, aby mieć logikę w swoim UIView. Ale zawieranie kilku linii kodu w osobnym kontrolerze wydawało się naprawdę bezużyteczne.

Tak czy inaczej, oto szybkie rozwiązanie, które dodaje nową właściwość do dowolnego UIView:

extension UIView {

    var viewController: UIViewController? {

        var responder: UIResponder? = self

        while responder != nil {

            if let responder = responder as? UIViewController {
                return responder
            }
            responder = responder?.nextResponder()
        }
        return nil
    }
}

To nie odpowiada bezpośrednio na pytanie, ale raczej zakłada intencję pytania.

Jeśli masz widok i w tym widoku musisz wywołać metodę na innym obiekcie, jak np. kontroler widoku, możesz zamiast tego użyć NSNotificationCenter.

Najpierw Utwórz łańcuch powiadomień w pliku nagłówkowym

#define SLCopyStringNotification @"ShaoloCopyStringNotification"

W Twoim odczuciu call postNotificationName:

- (IBAction) copyString:(id)sender
{
    [[NSNotificationCenter defaultCenter] postNotificationName:SLCopyStringNotification object:nil];
}

Następnie w kontrolerze widoku dodajesz obserwatora. Robię to w viewDidLoad

- (void)viewDidLoad
{
    [[NSNotificationCenter defaultCenter] addObserver:self
                                             selector:@selector(copyString:)
                                                 name:SLCopyStringNotification
                                               object:nil];
}

Teraz (również w tym samym kontrolerze widoku) zaimplementuj swoją metodę copyString: jak pokazano na powyższym selektorze@.

- (IBAction) copyString:(id)sender
{
    CalculatorResult* result = (CalculatorResult*)[[PercentCalculator sharedInstance].arrayTableDS objectAtIndex:([self.viewTableResults indexPathForSelectedRow].row)];
    UIPasteboard *gpBoard = [UIPasteboard generalPasteboard];
    [gpBoard setString:result.stringResult];
}

To z pewnością zły pomysł i zły projekt, ale jestem pewien, że wszyscy możemy cieszyć się szybkim rozwiązaniem najlepszej odpowiedzi zaproponowanej przez @Phil_M:

static func firstAvailableUIViewController(fromResponder responder: UIResponder) -> UIViewController? {
    func traverseResponderChainForUIViewController(responder: UIResponder) -> UIViewController? {
        if let nextResponder = responder.nextResponder() {
            if let nextResp = nextResponder as? UIViewController {
                return nextResp
            } else {
                return traverseResponderChainForUIViewController(nextResponder)
            }
        }
        return nil
    }

    return traverseResponderChainForUIViewController(responder)
}

Jeśli twoim zamiarem jest robienie prostych rzeczy, takich jak Pokazywanie modalnego okna dialogowego lub śledzenie danych, nie uzasadnia to użycia protokołu. Osobiście przechowuję tę funkcję w obiekcie użyteczności, możesz jej używać z wszystkiego, co implementuje protokół UIResponder jako:

if let viewController = MyUtilityClass.firstAvailableUIViewController(self) {}

All credit to @ Phil_M

Do odpowiedzi Phila:

W linii: id nextResponder = [self nextResponder]; jeśli self(UIView) nie jest podglądem widoku Viewcontrollera, jeśli znasz hierarchię self (UIView) możesz użyć również: id nextResponder = [[self superview] nextResponder];...

Może się spóźniłem. Ale w tej sytuacji nie lubię kategorii (zanieczyszczenia). Kocham ten sposób:

#define UIViewParentController(__view) ({ \
UIResponder *__responder = __view; \
while ([__responder isKindOfClass:[UIView class]]) \
__responder = [__responder nextResponder]; \
(UIViewController *)__responder; \
})

Moje rozwiązanie prawdopodobnie byłoby uznane za fałszywe, ale miałem podobną sytuację jak mayoneez( chciałem zmienić widoki w odpowiedzi na gest w EAGLView), i dostałem kontroler widoku EAGL w ten sposób:

EAGLViewController *vc = ((EAGLAppDelegate*)[[UIApplication sharedApplication] delegate]).viewController;

Myślę, że jest przypadek, kiedy obserwowany musi poinformować obserwatora.

Widzę podobny problem, gdy UIView w UIViewController reaguje na sytuację i musi najpierw powiedzieć swojemu nadrzędnemu kontrolerowi widoku, aby ukrył przycisk Wstecz, a następnie po zakończeniu powiedzieć nadrzędnemu kontrolerowi widoku, że musi sam wyskoczyć ze stosu.

Próbowałem tego z delegatami bez powodzenia.

Nie rozumiem dlaczego to ma być zły pomysł?

Innym łatwym sposobem jest posiadanie własnej klasy widoku i dodanie właściwości kontrolera widoku do klasy widoku. Zwykle kontroler widoku tworzy widok i wtedy kontroler może ustawić się na właściwość. Zasadniczo zamiast szukać kontrolera (z odrobiną hakowania), kontroler ustawia się na widok - jest to proste, ale ma sens, ponieważ to kontroler "kontroluje" widok.

Zaktualizowana wersja dla swift 4: dzięki dla @ Phil_M i @ paul-slm

static func firstAvailableUIViewController(fromResponder responder: UIResponder) -> UIViewController? {
    func traverseResponderChainForUIViewController(responder: UIResponder) -> UIViewController? {
        if let nextResponder = responder.next {
            if let nextResp = nextResponder as? UIViewController {
                return nextResp
            } else {
                return traverseResponderChainForUIViewController(responder: nextResponder)
            }
        }
        return nil
    }

    return traverseResponderChainForUIViewController(responder: responder)
}

Wersja Swift 4

extension UIView {
var parentViewController: UIViewController? {
    var parentResponder: UIResponder? = self
    while parentResponder != nil {
        parentResponder = parentResponder!.next
        if let viewController = parentResponder as? UIViewController {
            return viewController
        }
    }
    return nil
}

}

Przykład użycia

 if let parent = self.view.parentViewController{

    }

Swiftier solution

extension UIView {
    var parentViewController: UIViewController? {
        for responder in sequence(first: self, next: { $0.next }) {
            if let viewController = responder as? UIViewController {
                return viewController
            }
        }
        return nil
    }
}

Jeśli twoim rootviewcontrollerem jest UINavigationViewController, który został ustawiony w klasie AppDelegate, to

    + (UIViewController *) getNearestViewController:(Class) c {
NSArray *arrVc = [[[[UIApplication sharedApplication] keyWindow] rootViewController] childViewControllers];

for (UIViewController *v in arrVc)
{
    if ([v isKindOfClass:c])
    {
        return v;
    }
}

return nil;}

Gdzie C wymaga klasy kontrolerów widoku.

Użycie:

     RequiredViewController* rvc = [Utilities getNearestViewController:[RequiredViewController class]];

Nie ma mowy.

To, co robię, to przekazywanie wskaźnika UIViewController do UIView (lub odpowiedniego dziedziczenia). Przykro mi, że nie mogę pomóc w podejściu IB do problemu, ponieważ nie wierzę w IB.

Aby odpowiedzieć pierwszemu komentatorowi: czasami musisz wiedzieć, kto do ciebie zadzwonił, ponieważ to decyduje, co możesz zrobić. Na przykład w bazie danych możesz mieć tylko dostęp do odczytu lub odczyt/zapis ...