Responder Chain: Was es ist, Funktionsprinzip und Responder-Kette

Was ist Responder Chain

Responder Chain ist eine Abfolge von UIResponder-Objekten, über die iOS Eingabeereignisse wie Berührungen, Tastendrücke und Beschleunigungsmesserdaten weiterleitet. Jedes Objekt in dieser Kette hat die Fähigkeit, das Ereignis zu verarbeiten oder über die next-Eigenschaft an das nächste Responder-Objekt weiterzugeben.

Der Mechanismus basiert auf der View-Hierarchie: Wenn eine Berührung auftritt, bestimmt iOS zunächst, welche View berührt wurde (durch Hit-Testing), und erstellt eine Kette, die bei dieser View beginnt und bis zu UIApplication reicht. UIApplication ist das letzte Glied der Kette — wenn ein Ereignis es erreicht und nicht verarbeitet wird, wird es einfach verworfen.

Laut Apple ist dieses Muster entscheidend für die Kapselung der Ereignisbehandlungslogik. Ein Entwickler kann das Verhalten einer bestimmten View überschreiben, ohne andere Elemente in der Hierarchie zu beeinträchtigen. Beispielsweise wird UITextField beim Erhalt des Fokus zum first responder und empfängt Tastaturereignisse, ohne dass Änderungen im übergeordneten UIViewController erforderlich sind.

Wie Responder Chain Ereignisse verarbeitet

Die Ereignisbehandlung über die Responder Chain erfolgt in zwei Schritten: Zunächst bestimmt iOS, welche View das Ereignis erhalten hat (Hit-Testing), dann führt es die Responder-Kette aus, um es zu verarbeiten. Wenn ein Objekt die entsprechende Methode nicht implementiert, wird das Ereignis weitergegeben.

Die Kette wird dynamisch basierend auf dem aktuellen first responder und der View-Hierarchie gebildet. Die Standardreihenfolge ist: first responder → seine View → Superview → UIViewController → Root-View → UIWindow → UIApplication. Wenn eines dieser Objekte beispielsweise touchesBegan implementiert, wird das Ereignis auf dieser Ebene verarbeitet und nicht weitergegeben.

import UIKit

class CustomView: UIView {
    override func touchesBegan(
        _ touches: Set<UITouch>,
        with event: UIEvent?
    ) {
        // Berührung auf dieser View-Ebene behandelt
        print("CustomView hat Berührung behandelt")
        
        // Ereignis entlang der Kette weiterleiten
        super.touchesBegan(touches, with: event)
    }
}

Ein wesentliches Merkmal ist, dass der Aufruf von super.touchesBegan nicht zwingend erforderlich ist. Wenn er nicht aufgerufen wird, wird das Ereignis nur auf der aktuellen Ebene verarbeitet und nicht entlang der Responder Chain weitergeleitet. Dies gibt dem Entwickler die vollständige Kontrolle darüber, welche Objekte an der Verarbeitung beteiligt sind.

Weiterleitung von Ereignissen zwischen Responder-Objekten

Wenn ein Objekt ein Ereignis empfängt, es aber nicht verarbeitet (die Methode nicht überschreibt), leitet iOS das Ereignis automatisch über die next-Eigenschaft an das nächste Responder-Objekt weiter. Diese Eigenschaft bildet eine einfach verkettete Liste, die als Responder Chain bezeichnet wird.

UIViewController befindet sich zwischen seiner View und UIWindow: Wenn die View das Ereignis nicht verarbeitet, erhält der Controller die Möglichkeit, dies zu tun. Dies ist besonders nützlich für gemeinsame Logik — beispielsweise die Behandlung einer Geste, die auf der gesamten Szene funktionieren soll, unabhängig davon, welche View sich unter dem Finger des Benutzers befindet.

Hit-Testing: Von der Berührung zum ersten Responder

Hit-Testing ist der Prozess, mit dem iOS bestimmt, welche View sich unter dem Berührungspunkt befindet. Die Methode hitTest:withEvent: durchläuft die View-Hierarchie von UIWindow abwärts und prüft, welche Child-View den Berührungspunkt enthält und nicht ausgeblendet ist.

Der Algorithmus arbeitet rekursiv: Für jede Ebene überprüft iOS die Views in umgekehrter Reihenfolge des Hinzufügens (zuerst die oberste). Wenn eine View nicht ausgeblendet ist, nicht transparent ist und der Punkt innerhalb ihrer Grenzen liegt, wird hitTest rekursiv für alle ihre Subviews ausgeführt. Die tiefste View, die alle Bedingungen erfüllt, wird zur Hit-Test-View — dem ersten Objekt in der Responder Chain.

override func hitTest(
    _ point: CGPoint,
    with event: UIEvent?
) -> UIView? {
    if isUserInteractionEnabled &&
        isHidden == false &&
        alpha > 0.01 &&
        point(inside: point, with: event) {
        return super.hitTest(point, with: event)
    }
    return nil
}

Entwickler können hitTest überschreiben, um das Standardverhalten zu ändern. Beispielsweise um den Berührungsbereich eines kleinen Buttons zu erweitern oder das Ereignis an eine andere View umzuleiten, die sich physisch nicht unter dem Finger befindet. Dies ist ein leistungsstarkes Werkzeug zur Erstellung benutzerdefinierter interaktiver Elemente.

UIResponder-Methoden für die Responder-Kette

UIResponder ist die Basisklasse für alle Objekte, die in iOS Ereignisse verarbeiten können. UIView, UIViewController, UIApplication und UIWindow erben von UIResponder. Die Klasse stellt eine Reihe von Methoden bereit, die überschrieben werden können, um verschiedene Arten von Ereignissen zu verarbeiten.

Die wichtigsten Methodengruppen umfassen touchesBegan, touchesMoved, touchesEnded, touchesCancelled für Berührungen; pressesBegan, pressesEnded für physische Tasten; und motionBegan, motionEnded für Beschleunigungsmesser-Ereignisse. Jede Methode erhält eine Reihe von UITouch- oder UIPress-Objekten und einen Verweis auf UIEvent, das zusätzliche Metadaten über das Ereignis enthält.

Es ist wichtig zu verstehen, dass iOS diese Methoden nur für den first responder und nachfolgende Objekte in der Kette aufruft. Wenn kein Objekt die Methode überschrieben hat, erzeugt das Ereignis keinen Fehler — es wird einfach ignoriert. Zum Debuggen der Ereignisbehandlung verwenden Sie einen symbolischen Haltepunkt bei UIResponder touchEvent.

Responder Chain und UIKit-Elemente

Standardmäßige UIKit-Komponenten nutzen die Responder Chain aktiv für ihre Funktion. UITextField wird beim Erhalt des Fokus zum first responder, was automatisch die Tastatur öffnet. UIButton verarbeitet Berührungen über den UIControl-Mechanismus, der ebenfalls auf der Responder Chain basiert.

UITableView und UICollectionView verwenden die Responder-Kette für die Behandlung von Zellenauswahl und Scroll-Gesten. Wenn ein Benutzer eine Zelle berührt, erreicht das Ereignis zuerst die Zelle selbst, dann UITableView und erst danach UIViewController. UIGestureRecognizer hat eine höhere Priorität als touchesBegan — wenn einer View ein Gestenerkenner hinzugefügt wird, erhält dieser das Ereignis zuerst.

Laut Apple ist die korrekte Verwendung der Responder Chain entscheidend für die Barrierefreiheit der App. VoiceOver und andere unterstützende Technologien nutzen die Responder-Kette zur Navigation zwischen Schnittstellenelementen. Wenn die Kette unterbrochen ist, können Benutzer mit Behinderungen nicht mit der Anwendung interagieren.

UIMenuController und Responder Chain

UIMenuController zur Anzeige von Kontextmenüs verwendet ebenfalls die Responder Chain. Wenn ein Benutzer das Menü aufruft, sucht das System nach einem first responder, der die Methoden canPerformAction und die entsprechenden Aktionsmethoden implementiert. Das Menü wird nur für Aktionen angezeigt, die der aktuelle Responder unterstützt.

Dies ermöglicht es beispielsweise, die Befehle Ausschneiden, Kopieren, Einfügen nur anzuzeigen, wenn UITextField fokussiert ist, und sie bei der Arbeit mit UILabel auszublenden. Ein Entwickler kann benutzerdefinierte Aktionen zum Kontextmenü hinzufügen, indem er sie in einer UIResponder-Unterklasse implementiert und true von canPerformAction zurückgibt.

Benutzerdefinierte Responder-Objekte in iOS

Ein benutzerdefiniertes Responder-Objekt zu erstellen, gibt dem Entwickler die vollständige Kontrolle über die Ereignisbehandlung. Dazu muss eine Unterklasse von UIResponder (oder UIView/UIViewController) erstellt und die erforderlichen Ereignisbehandlungsmethoden überschrieben werden.

Benutzerdefinierte Responder-Objekte werden häufig zur Behandlung spezifischer Gesten verwendet, die nicht von standardmäßigen UIGestureRecognizer abgedeckt werden. Beispielsweise das Erkennen von Formzeichnungen, komplexen Multi-Touch-Kombinationen oder proprietären Eingabemustern. Ein benutzerdefinierter Responder kann Ereignisse von mehreren Fingern sammeln und Entscheidungen basierend auf deren Kombination treffen.

class DrawingResponder: UIResponder {
    private var activeTouches: [UITouch: CGPoint] = [:]
    
    override func touchesBegan(
        _ touches: Set<UITouch>,
        with event: UIEvent?
    ) {
        for touch in touches {
            activeTouches[touch] = touch.location(in: self)
        }
    }
    
    override func touchesMoved(
        _ touches: Set<UITouch>,
        with event: UIEvent?
    ) {
        for touch in touches {
            let currentPoint = touch.location(in: self)
            activeTouches[touch] = currentPoint
            drawLine(from: activeTouches[touch]!, to: currentPoint)
        }
    }
}

Beim Erstellen eines benutzerdefinierten Responders ist es wichtig, die next-Kette korrekt zu konfigurieren. Wenn Ihr Objekt nicht Teil der standardmäßigen UIKit-Hierarchie ist, müssen Sie explizit angeben, welches Objekt sein next responder sein soll. Dies stellt sicher, dass nicht verarbeitete Ereignisse weiter entlang der Responder Chain wandern.