Beim Übergang vom Web-Stack zum iOS-Wunderland fällt es mir schwer zu verstehen, wie ich meine Gedanken für MVC neu strukturiere und meine Benutzeroberfläche auf iOS strukturiere .
Was ist der beste Weg, um Ansichten in meinem self.view mit zu erstellen:
UIView class UIViewController mit einer zugehörigen UIView -Klasse auftritt. UIViewController mit inline UIView vorkommt
A might [self addView:B_view] (Wenn B nur UIView war) A könnte auch [self addView:B_viewController.view] (Wenn B einen View-Controller hätte) A könnte auch [B setChildView:C_view]
B_viewController.delegate = A & amp; %Code%
C_viewController.delegate = A & amp; %Code%
Die Logik ist auf Delegaten, viewControllers und Ansichten verteilt.
Abgesehen von dem Argument "Zusammenfassung gut und Trennung von Bedenken" , die über die Erfahrungen verbessern kann. Ich glaube, es ist das Ausbluten von ViewController und ViewController.view zusammengesetzt, um leicht umfangreiche Kopplung zu verursachen.
Das wird schnell verwirrend und fühlt sich an wie Spaghetti und trotz Anstrengung schwer zu kontrollieren.
Das heißt,
Vielleicht haben Sie es mit dem Dilemma MVC - Massive View Controllers zu tun. Hier ist eine interessante Lektüre, in der Marcus davon spricht, den Code effektiv zu verwalten, indem er den Code wo er hingehört, Netzwerkschicht, Persistenzschicht oder die Darstellungsschicht (im Idealfall der Viewcontroller).
Abgesehen von dem Delegationsmuster haben wir auch einen block- / schließungsbasierten Ansatz, der helfen könnte, den Code zu bereinigen.
Im Allgemeinen könnte Robert C. Martins Clean-Code-Ansatz hier Abhilfe schaffen. Die Art, es durch etwas zu implementieren, das als VIPER-Architektur bezeichnet wird. Hier ist ein Tutorial dazu.
Objective C umfasst als Sprache das Delegationsmuster und es ist eine Standardpraxis, es für die meisten Anliegen zu verwenden.
Willkommen auf der iOS-Plattform.
Ich habe es versäumt, ähnlich große Fragen beim Stackoverflow zu stellen - es scheint, als würde die Community eine spezifischere technische Frage bevorzugen. Aber ich werde es versuchen. Denken Sie daran, dass alle folgenden meine Meinungen und keine harten und schnellen Regeln sind.
Ich habe das Gefühl, dass es sich um eine zusammengesetzte Frage über Nachrichtenweitergabe und Designmuster handelt. In Bezug auf die Komponentenkommunikation (ob es sich um Ansichten oder Controller handelt) gibt es viele Möglichkeiten, um es zu umgehen, jedes hat seine + und - (oder eher Anwendungsfälle). Es gibt: Delegation, Responder-Kette, Blöcke, Benachrichtigungen, reaktives Signal - um nur einige zu nennen.
self.superview oder self.parentViewController (manche sagen sogar self.navigationController ) tut, verletzt sie wahrscheinlich die Kapselung und es gibt einen besseren Weg. Es folgen einige zufällige Beobachtungen, die Sie irgendwo hinführen könnten (oder auch nicht).
MVC ist meiner Meinung nach ein tolles Muster für kleine Projekte (es ist einfach von "einfach gegen einfach"). Aber aus persönlicher Erfahrung gerät es schnell außer Kontrolle, wenn die Komplexität des Bildschirms, an dem Sie arbeiten, wächst. Die Tendenz ist, dass der Controller alles von der Benutzerinteraktion bis zum Netzwerk handhaben kann und es wird schnell ein 1k-langes Monster.
Leider verlässt sich eine Menge in der iOS-Architektur auf UIViewController . Oft wird es unweigerlich zum ersten Kontaktpunkt Ihres Codes mit OS, aber es muss nicht alles intern behandeln. Stattdessen kann es Zuständigkeiten an geeignete Komponenten weiterleiten, d. H.
Ich habe es aus Ihrer Beschreibung nicht bemerkt, aber wenn Sie MVC bevorzugen, ist es eine absolut gültige Option, Controller zu erstellen. Es ist eine sehr häufige Situation, wenn Sie für iPad bauen, aber sogar auf dem iPhone kann jeder Bildschirm leicht völlig unabhängige Teile enthalten, wobei jeder von ihnen eine separate ViewController ist, dann sollten Sie in die sogenannte "UIViewController-Eindämmung" schauen. Meistens ermöglicht es eine bessere Trennung und Wiederverwendung, löst aber wiederum nicht das Hauptproblem.
Wenn Sie dies lesen, sind Sie sehr lernbegierig. In diesem Fall würde ich vorschlagen, nicht bei MVC zu bleiben. Es gibt viele interessante Designmuster, die für Ihre speziellen Bedürfnisse geeignet sein könnten oder auch nicht. MVVM war (ist?) Ziemlich populär. In letzter Zeit scheint die unidirektionale Strömung die neue heiße Sache zu sein. Inspiriert von JS Redux. Es ist eine sehr große Abweichung von MVC und ich schlage vor, dieses Projekt Ссылка zu überprüfen, wenn Sie interessiert sind.
Traurig wie jede architektonische Frage gibt es kein Richtig und Falsch - es gibt nur Dinge, die für Sie und Ihr Team funktionieren oder nicht. Und ich würde gerne andere Perspektiven hören, bevor die Frage als "zu breit" closed geschlossen wird
Tut mir leid, wenn dies nicht das ist, wonach Sie gefragt haben, lassen Sie es mich wissen, wenn es bestimmte Aspekte gibt, die Sie diskutieren möchten.
Sie können einen ViewController
Lassen Sie UIViews zu ViewController getrennt. Es sollte nicht eng mit ViewController gekoppelt sein.
Lassen Sie Ihren View-Benutzer in der UIView-Klasse selbst anmelden. Erstellen Sie eigene Delegaten und Protokolle. und benutze es in jedem Viewcontroller.
viewcontroller zu viewcontroller hinzufügen ist keine gute Lösung.
Sie können auch zu MVVM wechseln, wo jede Ansicht ihren logischen Teil in ihrem Ansichtsmodell hat. Aber das kann zu Beginn verwirrend sein.
Versuchen Sie, UIViews zu ViewControllern zu trennen.
Als jemand, der eine Menge iOS-Programmierung gemacht hat und jetzt viel Zeit mit angular dev verbringt, hier ein paar schnelle Gedanken:
A UIView repräsentiert den grundlegenden Bildschirmbaustein; Das heißt, es kompromittiert eine Ansicht, einige Daten und die Logik, um diese Daten in der Ansicht zu rendern. So kann es zum Zeichnen von Text oder Grafiken verwendet werden oder es kann eine beliebige Anzahl von Unteransichten enthalten, die dieselbe Fähigkeit haben. In der Angular-Welt wäre ein UIView (etwas) äquivalent zu einem Component , das HTML , CSS , JavaScript usw. einkapselt, könnte aber auch andere Komponenten enthalten.
Wie Sie wissen, bietet iOS viele vordefinierte, native UIViews - UILabel , UIButton , UITable usw., die für die meisten Anwendungsanforderungen geeignet sind.
A UIViewController hat eine strukturellere Funktion als UIView . Es integriert sich in das Navigationsframework, sodass der Entwickler den Kontext für den Benutzer schnell ändern kann. Es enthält ein "main" UIView , das als Basisplattform für den Kontext dient und eine beliebige Anzahl von nativen und benutzerdefinierten UIView's enthält. Sein Zweck besteht darin, diese UIViews für den aktuellen App-Kontext zu konfigurieren.
Wenn ein UIViewController eine UIView auf eine Weise konfiguriert, die nicht auf den aktuellen Anwendungskontext beschränkt ist, sollte UIView wahrscheinlich in ein benutzerdefiniertes Objekt erweitert werden. Auf diese Weise kann es sich selbst verwalten und ist leichter in anderen Kontexten wiederzuverwenden.
Eine andere Sache:
Delegaten sind, wenn es angebracht ist, großartig, aber NSNotification ist eine einfache, mächtige Möglichkeit, Änderungen zu beobachten, während die Spaghetti der Objektabhängigkeiten vermieden werden.
Tags und Links ios design cocoa-touch uiview uiviewcontroller