UIViewController Category auf alle subclasses von UIViewController?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • bachelor schrieb:

    Ist es möglich eine UIViewController category auch auf alle subclasses von UIViewControllerwirken zu lassen?
    Wie schon gesagt, ja. Dazu sind Categories ja auch da.

    Aaaaaber… Kann es sein, daß Du eine schon bestehende Methode _überschreiben_ willst?

    Ich bin mir jetzt nicht ganz sicher, wie sich das genau in Objective-C verhält. In Swift zumindest scheint das etwas 'tricky' zu sein und von der Deklarationsreihenfolge abzuhängen…
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • Kategorien sollte man besser nicht zum Überschreiben verwenden. Das ist in Objective-C und wahrscheinlich auch in Swift schon immer eine unsaubere Geschichte gewesen, insbesondere wenn man darin auch noch Super-Zugriffe hat. Lieber eine Unterklasse erstellen, die die anderen Klassen als Oberklasse verwenden.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    Kategorien sollte man besser nicht zum Überschreiben verwenden. Das ist in Objective-C und wahrscheinlich auch in Swift schon immer eine unsaubere Geschichte gewesen, insbesondere wenn man darin auch noch Super-Zugriffe hat. Lieber eine Unterklasse erstellen, die die anderen Klassen als Oberklasse verwenden.
    Das ist der saubere Weg.

    Wenn du ganz böse Methoden überschreiben willst, nimm Method Swizzling *duck und weg*

  • Bei meinem Vorhaben geht es um die Statusbar. Ich möchte in allen ViewControllern meiner App die Statusbar ausblenden ausser wenn es ein iPhone X ist.
    Über Plist-Einträge bekommt man sowas nicht hin. Ich möchte aber nicht in jedem Controller das selbe machen um das zu managen.

    Für den UIImagePickerController funktioniert das hier:

    Quellcode

    1. @implementation UIImagePickerController (HideStatusBar)
    3. - (BOOL)prefersStatusBarHidden
    4. {
    5. UIEdgeInsets safeArea = [Helpfunctions getSafeAreaInsets: self.view];
    6. if(safeArea.top > 0)
    7. {
    8. return NO;
    9. }
    10. return YES;
    11. }
    13. - (UIViewController *)childViewControllerForStatusBarHidden
    14. {
    15. return nil;
    16. }
    17. @end
    Alles anzeigen
    Der Code wird aufgerufen und funktioniert ohne, dass ich den Header in UIImagePickerController eigefügt habe. (Kann ich ja auch nicht einfügen)

    Jetzt das Ganze für UIViewController.


    UIViewController+StatusBarManager.h:

    Quellcode

    1. #import <UIKit/UIKit.h>
    2. #import "Helpfunctions.h"
    4. @interface UIViewController (StatusBarManager)
    6. @end

    UIViewController+StatusBarManager.m:

    Quellcode

    1. #import "UIViewController+StatusBarManager.h"
    3. @implementation UIViewController (StatusBarManager)
    5. - (BOOL)prefersStatusBarHidden
    6. {
    7. UIEdgeInsets safeArea = [Helpfunctions getSafeAreaInsets: self.view];
    8. if(safeArea.top > 0)
    9. {
    10. return NO;
    11. }
    12. return YES;
    13. }
    15. - (UIViewController *)childViewControllerForStatusBarHidden
    16. {
    17. return nil;
    18. }
    20. @end
    Alles anzeigen


    Bei der Verwendung funktioniert es nicht:


    Quellcode

    1. #import "UIViewController+StatusBarManager.h"
    3. @interface VSSettingsViewController : UIViewController <GADBannerViewDelegate>
    5. //---
    7. @end

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von bachelor ()

  • @bachelor Dein Code bestätigt meine Annahme, daß Du eine bestehende Methode eines externen Frameworks überschreiben willst und daß da das Problem liegt. Wie @macmoonshine treffend bemerkt hat ist das wohl "immer eine unsaubere Geschichte".

    Ich habe interessehalber inzwischen ein paar Experimente in Swift auf diesem Feld gemacht. Bei relativ einfachen Konstellationen scheint dieser Ansatz durchaus zu funktionieren. Aber die Grenzen sind schnell erreicht. Wenn in einem externen Framework z.B. eine Subklasse die entsprechende Methode/ Property einer Basisklasse überschreibt, dann meckert der Swift-Compiler schnell über Amgiguität oder "Declarations in extensions cannot override yet".

    Das ist also offensichtlich 'unsauber'. Das Grundproblem dürfte das gleiche sein, ob nun Obj-C oder Swift…

    Wenn es Dir hauptsächlich um Vermeidung redundanten Codes geht, kannst Du dann nicht eine zusätzliche Methode in die Extension packen, die sich nicht mit bestehbendem Code beißt, und auf die Du dann jeweils nur mit einem Einzeiler in den jeweiligen Subklassen zugreifen kannst…?

    Was mich an Deinem Code noch irritiert, ist daß es einmal (HideStatusBar) und ein andernmal (StatusBarManager) heißt???
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • Wie ich an anderer Stelle schon schrieb, sollte man die Statusbar nicht leichtfertig ausblenden. Das Ding hat einen Sinn. Die Standadviewcontroller funktionieren alle wunderbar mit der Statusleiste, und kein Mensch will eine App verlassen, um WLAN- bzw. Batteriestatus oder die Uhrzeit zu sehen.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    BTW. Soweit ich weiß, lässt sich die Statusleiste auch applikationsweit über die Info.plist ausschalten.
    Ja, die lässt sich komplett ausschalten. Aber mit dem iPhone X ist der Platz dann verschwendet. Ich würde gerne auf dem iPad und iPhones 6,7,8 die Statusleiste gerne ausblenden und auf dem iPhone X einblenden.
    Das geht aber nicht so einfach.

  • bachelor schrieb:

    Das passt nicht zum Design der Foto-App. Bei den Apps bei denen es zum Design passt, zeige ich die dauerhaft an.
    Dann überdenk dein Design. Eine App, ohne Statusbar, würde bei mir nur eins. Vom Gerät fliegen. Ich will immer! Den Status meines Gerätes einsehen können. Dazu ist das Ding da. Ganz egal ob es um die Akku Anzeige oder das Netzwerk geht.
    Man kann alles schaffen. Man muss es nur wollen ;)
    www.regetskcob.github.io