Dev Diary: Risiken und Nebenwirkungen von setHidesBarsOnSwipe

Viele kennen es von der Facebook- und anderen Apps, dass die Navigationbar in Apps sich langsam ausblendet, wenn der Nutzer nach unten scrollt. Beim Zurückscrollen taucht sie dann rasch wieder auf, so dass die Bedienelemente stets schnell erreichbar sind.

Seit iOS 8 existiert eine einfache und komfortable Möglichkeit, den Bildschirm auf diese Weise in Apps effizienter auszunutzen:

[self.navigationController setHidesBarsOnSwipe:YES];

Die Sache hat nur einen Haken. Bislang hatte ich in meiner App eine Funktion implementiert, die Wischgesten nach rechts in eine Art Zurück-Funktion übersetzt:

UISwipeGestureRecognizer *recognizer;
recognizer = [[UISwipeGestureRecognizer alloc] initWithTarget:self action:@selector(pageTurnLeft:)];
[recognizer setDirection:(UISwipeGestureRecognizerDirectionRight)];
[[self view] addGestureRecognizer:recognizer];

Die Funktion löst seit dem Aktivieren von setHidesBarOnSwipe nicht mehr aus. Wie sich herausstellte, zieht die Funktion alle Gesten auf sich. Es ist aber durchaus möglich, sich dem GestureRecognizer anzuschließen:

[self.navigationController.barHideOnSwipeGestureRecognizer addTarget:self action:@selector(swipeGesture:)];

Ein GestureRecognizer für alles – das klingt zu schön, um wahr zu sein. Und das ist es auch. Denn bislang konnte ich dem Recognizer gleich die gewünschte Swipe-Richtung mit auf den Weg geben (setDirection), was hier nicht geht. Mehr noch: Wir haben es bei der ausgelösten Funktion auch nicht mit einem Übergabewert des Typs UISwipeGestureRecognizer zu tun, dessen Direction wir einfach auslesen könnten, sondern mit einem anderen Vertreter:

- (void)swipeGesture:(UIPanGestureRecognizer*)gesture

Der UIPanGestureRecognizer ist leider kein so freundlicher Typ. Das Bestimmen der Richtung gestaltet sich weitaus aufwendiger. Und bislang habe ich noch keine zufriedenstellende Lösung gefunden, neue und alte Funktion in Einklang zu bringen.

Kommentar verfassen