Ich bin neu in der iOS-Entwicklung. Ich habe den Quellcode gelesen, den ich online gefunden habe, und viele von ihnen enthalten keine einzige Nib-Datei. Die gesamte Ansicht scheint manuell aus Code gezeichnet zu werden.
Was bringt es, eine Nib-Datei zu haben / nicht zu haben? Warum haben sie sich dafür entschieden, alles aus Code zu erstellen anstatt etwas, das man sich vorstellen könnte, wie Storyboard oder * .xib-Dateien?
Es gibt sehr einfache Nibs wie die typische MainWindow.nib, die keinen lokalisierten Inhalt haben und mit einer einzelnen Codezeile reproduziert werden können. In solchen Fällen ist Code viel schneller als das Auslagern der Spitze.
Es gibt auch sehr dynamische Layouts, die man unmöglich als Feder beschreiben kann.
Sie sollten in jedem Fall den bequemsten und effizientesten Weg wählen. Es wird immer Kompromisse geben, wählen Sie nur weise.
Der größte Grund, warum ich Code mag, ist, dass er gut in der Quellcodeverwaltung ist. XIBs sind sehr schwierig zu vergleichen, zusammenführen, lesen.
Code ist auch einfach, dass gespeicherte Snippets kopieren / einfügen. Bei IB vergesse ich immer ein Kästchen, das mich fragt, warum die Magie nicht funktioniert. Meine Notizen haben Code-Snippets.
Was IB wirklich auszeichnet, ist das Layout und hilft Ihnen bei den Richtlinien für die Benutzerschnittstelle (Anzahl der Pixel zwischen den Steuerelementen usw. ... mit Hilfe von Verbindungslinien).
Also, meine persönliche Vorliebe ist Layout in IB und alles andere im Code (einschließlich Ziel, Aktion, Hinzufügen von Spalten usw. ... etc ...). In dynamischen Szenarios fällt IB jedoch auseinander und Sie erhalten benutzerdefinierte Ansichten.
Hier ist ein verwandter Beitrag:
Interface Builder (XIB) oder Code beim Zusammenführen in einer Teamumgebung?
Es gibt viele Gründe warum Sie Federn verwenden sollten und warum sollten Sie nicht. Es gibt keine definitive Antwort, und jede Antwort hängt davon ab, was Sie tun müssen.
Abgesehen von den offensichtlichen Vorteilen, die Nibs bietet (schneller UI-Erstellungsprozess, minimieren Sie den Konstruktionscode für die Konstruktion in .m-Dateien), bieten sie etwas, das Sie nicht anders finden können: Lokalisierungsprobleme lösen. Während Sie Ihre Anwendung in anderen Sprachen lokalisieren, stolpern Sie über Phrasen und Dinge, die 2-3 Wörter benötigen, um sie zu erklären, während sie in einer anderen Sprache nur eine Sprache brauchen. Dies führt bei Verwendung unterschiedlicher Lokalisierungen zu Fehlern bei falsch angeordneten Ansichten innerhalb eines View-Controllers. So können Sie in Xcode 4 2-3 Sub-Nibs für jede Spitze haben und jeden nach Belieben lokalisieren und die Buttons und Views an den richtigen Stellen platzieren, ohne dass Sie Ihre Ansichten abhängig von der Sprache verschieben müssen Benutzer hat. Wenn Sie all das mit Code tun würden, sollten Sie "if's überall" platziert haben, und das ist sicherlich eine schlechte Programmierpraxis und fehleranfällig.
Ich habe einige View-Controller erstellt, die Hunderte von Zeilen benötigen, um die Ansichten zu erstellen, wenn ich den Interface Builder nicht verwendet habe.
NIBs erreichen jedoch niemals die Leistung der programmgesteuerten Erstellung der Ansichten, da jede NIB ein in HTML / XML geschriebener Ansichtsdeskriptor ist und vor dem Erstellen einer Ansicht eine Datei von der Platte gelesen und analysiert werden muss. Nibs fehlen auch die Anpassungsoptionen, die der einfache Code hat (Schlagschatten, abgerundete Ecken und andere Quartz-Magie). Diese Anpassungsoptionen sind nicht verfügbar, da es viele Möglichkeiten gibt, dasselbe Ergebnis mithilfe von Code zu erreichen, indem Sie entweder mit der Core-Animationsebene höherer Ebene sprechen, indem Sie direkt QuarCore und CGGraphics ansprechen und dort schwere Dinge ausführen, die sicherlich schneller und empfohlen sind Fälle (Schatten mit Layern können extrem langsam sein). Daher möchte Apple die Entwicklung nicht zu einer bestimmten Art des Zeichnens einschränken.
NIBs existieren aus einem bestimmten Grund. Sie müssen sicherstellen, dass Sie in Ihrer Anwendung die Gründe verstehen, aus denen Sie eine NIB erstellen. Es gibt Nibs, um Code mit Steckdosen zu verbinden, die Lokalisierung zu erleichtern, die Entwicklung zu beschleunigen und den Code aufzuräumen. In einem Projekt müssen Sie sicherlich Nibs verwenden, aber Sie müssen auch vermeiden, sie zu verwenden, wo einfacher Code Ihnen auch die gleichen Ergebnisse mit minimalem oder ähnlichem Aufwand liefern würde.
Beachten Sie nicht zuletzt die Speicherverwaltung. Die Verwendung von Nibs wirkt sich auf die Freigabe von zugewiesenen Objekten wie IBOutlets aus. Wenn Sie sicher sind, dass ein IBOutlet, das Sie erstellen, freigegeben wird, wenn Sie möchten, verwenden Sie keine NIB. Verwenden Sie stattdessen einen einfachen Code.
Es gibt viele Gründe, Ansichten im Code zu erstellen.
Ich denke, der wichtigste Grund ist der Mangel an Leistung und Funktionen.
Ich benutze nib-Dateien, wenn ich nur einfache Informationen mit einfachen Buttons und Labels und für das Prototyping zeigen will.
Die Nib-Datei - und damit auch das Objektdiagramm - kann Platzhalterobjekte enthalten, die sich auf Objekte beziehen, die außerhalb des Dokuments liegen, aber Referenzen auf Objekte im Dokument oder auf Objekte im Dokument haben können Verweise. Ein spezieller Platzhalter ist der Eigentümer der Datei.
Zur Laufzeit laden Sie eine Nib-Datei mit der Methode loadNibNamed: owner: oder einer Variante davon. Der Eigentümer der Datei ist ein Platzhalter in der NIB-Datei für das Objekt, das Sie als Besitzerparameter dieser Methode übergeben. Die Verbindungen, die Sie mit dem Eigentümer der Datei in der nib-Datei in Interface Builder herstellen, werden wiederhergestellt, wenn Sie die Datei zur Laufzeit laden.
iOS verwendet nibs als Implementierungsdetail, das Storyboards, das Designlayoutformat für iOS-Benutzeroberflächen, unterstützt. Mit Storyboards können Sie die gesamte Benutzeroberfläche Ihrer App auf einer Leinwand entwerfen und visualisieren. Für iOS-Entwickler ist die Verwendung von Storyboards die empfohlene Methode zum Erstellen von Benutzeroberflächen.
Ich würde mit xibs beginnen. Sobald Sie die Benutzeroberfläche fertiggestellt haben, migrieren Sie Ihre xibs zu Code. Auf diese Weise erhalten Sie das Beste aus beiden Welten. XIBs können langsam sein, und ich habe 400KB XIBS gesehen (irgendwie selten). XIBs sind jedoch definitiv grausam ...
Tags und Links ios storyboard xib nib