Best Practices und Tools für die Entwicklung von iOS-Anwendungen

Bei der Entwicklung mobiler Anwendungen musste ich mehr als einmal Projekte von Grund auf neu erstellen. Gleichzeitig haben mein Team und ich immer viel Zeit mit der Grundeinstellung des Projekts verbracht, z. B. mit der Integration von Tools von Drittanbietern, dem Einrichten der Projektstruktur, dem Schreiben von Basisklassen, der Integration externer Bibliotheken usw.

Ich entschied, dass die Zeit, die zum Starten des Projekts benötigt wird, reduziert und der Hauptteil des Prozesses automatisiert werden kann. Gleichzeitig habe ich die von uns verwendeten Best Practices und Tools gesammelt und eine Projektvorlage vorbereitet, die wir beim Starten neuer Projekte verwenden. Eine solche Vorlage sollte dem Entwickler Zeit sparen, um ein neues Projekt zu konfigurieren, und eine gemeinsame Projektstruktur bereitstellen, an die sich jedes Teammitglied gewöhnt, sodass Sie nicht mehr über die Struktur eines neuen Projekts nachdenken und sie studieren müssen. Jetzt ist es immer das gleiche.

Jedes Tool oder jeder Ansatz, der der Vorlage hinzugefügt wird, verdient einen eigenen Artikel. Ich möchte jedoch versuchen, jeden Absatz zusammenzufassen und kurz zu erklären, warum ich sie in diesen Artikel aufgenommen habe.

Cocoapods

Ich glaube nicht, dass Cocoapods eine Einreichung erfordert. Dies ist eine Bibliothek zum Verwalten externer Abhängigkeiten für iOS-Projekte. Es existiert seit langer Zeit und ist in Tausenden (wenn nicht Millionen) von Projekten zuverlässig und praxiserprobt. Es gibt auch alternative Abhängigkeitsmanager, zum Beispiel: Karthago , aber ich habe mich entschieden, mit Cocoapods fortzufahren, da es die größte Auswahl an unterstützten Open Source-Projekten gibt. Die Verwendung von Cocoapods ist sehr einfach und verfügt über einen Suchindex , mit dem Sie leicht Pakete finden können, die jederzeit nützlich sein können.

Ein Vorlagenprojekt wird mit einer einfachen Poddatei geliefert , die Swiftlint und R.swift enthält. Die Vorlage enthält auch eine Gem-Datei zum Verwalten der Version von Cocoapods, die für das Abhängigkeitsmanagement verwendet wird. Diese Lösung wird von Entwicklern häufig ignoriert, verhindert jedoch Probleme, die auftreten, wenn Ihre Teamentwickler Abhängigkeiten mit verschiedenen Versionen von Cocoapods installieren. Gemfile verwendet zwangsweise dieselbe Version von Cocoapods für das gesamte Team.

Swiftlint

Swiftlint ist ein sehr nützliches Tool zum Durchsetzen bestimmter Regeln und des Schreibstils für jeden Entwickler im selben Team. Dieses System kann als automatisiertes Codeüberprüfungssystem betrachtet werden, das den Entwickler vor gefährlichen Momenten warnt, wie z. B. Force Casts, Force Trys usw. Zusätzlich zu den oben genannten Methoden wendet dieses System einen allgemeinen Stil zum Schreiben von Code und zur Überwachung an Damit alle Entwickler die gleichen Regeln befolgen, die mit dem "Codestil" verknüpft sind, z. B. Einrückungen oder Intervalle. Dieser Ansatz hat enorme Vorteile: Er spart nicht nur Zeit bei der Codeüberprüfung, sondern macht die Projektdateien auch erkennbar, was ihre Lesbarkeit und damit ihr Verständnis für alle Mitglieder des Entwicklungsteams verbessert. Dieser Link enthält eine Liste aller Regeln. In der Swiftlint-Vorlage wird sie mit Cocoapods installiert und ist im Schritt "Kompilierungsphasen" enthalten, sodass dem Entwickler bei jeder Kompilierung des Projekts eine Warnung angezeigt wird.

R.swift

R.swift ist ein Tool zum Abrufen stark typisierter, automatisch ausgefüllter Ressourcen wie Bilder, Schriftsegmente und Lokalisierungen. Es führt alle oben genannten Aktionen aus, indem es das Projekt scannt und die Klassen erstellt, die zum Abrufen von Ressourcen erforderlich sind. Der größte Vorteil dieser Bibliothek besteht darin, dass bei Verwendung von Ressourcen Programmcode erstellt wird:

• Vollständig typisiert - weniger Casts und Annahmen darüber, welche Methode zurückgegeben wird
• Kompilierungszeit überprüft - Keine ungültigen Zeilen mehr, die die Ausführung der Anwendung während der Codeausführung verhindern
• Autocompleted - Sie müssen den Namen image / nib / storyboard nicht erneut erraten

Betrachten Sie den folgenden Code mithilfe der offiziellen Zeichenfolgen-API:

let icon = UIImage(named: “custom-icon”) 

Wenn Sie im Namen des Bildes einen Fehler gemacht haben, erhalten Sie Null. Wenn ein Mitglied Ihres Teams den Namen der Bildressource ändert, gibt dieser Code Null zurück oder seine Ausführung wird gestoppt, wenn Sie das Bild zum Erweitern zwingen. Bei Verwendung von R.swift sieht es folgendermaßen aus:

 let icon = R.image.customIcon() 

Jetzt können Sie sicher sein, dass das Symbol wirklich vorhanden ist (der Compiler warnt Sie dank der Überprüfung der Kompilierungszeit, wenn dies nicht der Fall ist), und Sie können sicher sein, dass Sie im Namen des Symbols keinen Tippfehler machen, da Sie die automatische Vervollständigung verwenden.

R.swift wird mit Cocoapods installiert und in der Kompilierungsphase in die Vorlage integriert. Für jede Kompilierung werden Swift-Shell-Klassen generiert. Dies bedeutet, dass, wenn Sie eine Datei / ein Bild / eine Lokalisierung / eine Schriftart / eine Farbe / einen Stift usw. hinzufügen, all dies nach dem Kompilieren des Projekts über R.swift verfügbar ist.

Separate AppDelegate-Datei für Tests

Sehr oft vergessen sie die bewährte Methode, beim Ausführen von Tests eine separate TestAppDelegate-Klasse zu verwenden. Warum ist das eine gute Idee? Normalerweise erledigt die AppDelegate-Klasse beim Starten der Anwendung viel Arbeit. Es kann eine Fensterkonfigurationslogik haben, die Basisanzeige der Anwendungsbenutzeroberfläche konfigurieren, eine Registrierungslogik ausführen, um Benachrichtigungen zu erhalten, einen Einrichtungscode für die Datenbankverbindung haben und manchmal sogar Server-API-Aufrufe durchführen. Unit-Tests sollten keine Nebenwirkungen haben. Sie möchten wirklich keine zufälligen API-Aufrufe durchführen und die gesamte Benutzeroberflächenstruktur Ihrer Anwendung anpassen, nur um Komponententests auszuführen?

TestAppDelegate ist auch eine geeignete Wahl, um den Code abzurufen, den Sie während der Ausführung der Testsuite nur einmal ausführen möchten. Es kann Code enthalten, der Scheinobjekte, Netzwerkanforderungsstubs usw. generiert.

Die Vorlage enthält die Datei main.swift, die der Haupteinstiegspunkt für die Anwendung ist. In dieser Datei gibt es Methoden, die die Umgebung der Anwendung testen. Wenn es sich um eine Testumgebung handelt, rufen sie TestAppDelegate auf.

Compiler-Performance-Profiling-Flags

Swift ist eine großartige Sprache, einfacher zu verwenden und sicherer als Objective-C (IMO). Aber als es zum ersten Mal eingeführt wurde, hatte es einen großen Fehler - die Kompilierungszeit. Damals, als ich in Swift an einem Projekt arbeitete, das ungefähr 40.000 Zeilen Swift-Code enthielt (ein mittelgroßes Projekt). Der Code war sehr umfangreich, mit Einstellungen und Typinferenz, und das Kompilieren einer sauberen Assembly dauerte fast 5 Minuten. Wenn Sie auch nur kleine Änderungen vornehmen, wird das Projekt neu kompiliert und es dauert ungefähr 2 Minuten, bis die Änderungen angezeigt werden. Dies war eine der schlimmsten Erfahrungen, die ich je gemacht habe, und aus diesem Grund habe ich Swift fast nicht mehr verwendet.

Die einzige Lösung bestand darin, die Kompilierungszeit des Projekts zu profilieren und den Code so zu ändern, dass der Compiler schneller arbeitet. Um solche Probleme zu lösen, führt Apple einige inoffizielle Compiler-Flags ein , die den Entwickler warnen, dass das Kompilieren des Methodenkörpers oder das Bestimmen des Ausdruckstyps zu lange dauert. Ich habe diese Flags zum Vorlagenprojekt hinzugefügt, um vor der langen Kompilierungszeit Ihrer Anwendung zu warnen.

Heutzutage hat sich die Kompilierungszeit erheblich verkürzt, und Entwickler müssen ihren Code nur sehr selten optimieren, um die Kompilierungszeit zu verkürzen. Trotzdem ist es besser, alles im Voraus zu wissen, als zu versuchen, dieses Problem zu lösen, wenn das Projekt zu groß wird.

Entwicklungs- / Staging- / Produktionskonfigurationen

Ein anderer guter Ansatz (oder, könnte man sagen, eine Notwendigkeit) besteht darin, separate Konfigurations- und Umgebungsvariablen für Entwicklungsumgebungen, abschließende Tests und das Veröffentlichen von Anwendungen zu haben. Derzeit sollte fast jede Anwendung mit einem Server arbeiten, und normalerweise werden diese Server in mehreren Umgebungen bereitgestellt. Die Entwicklungsumgebung wird von Entwicklern für die tägliche Bereitstellung verwendet, um ihren Code zu testen. Die endgültige Testumgebung wird zum Erstellen stabiler Releases oder zum Testen durch Tester und Kunden verwendet.

Eine Möglichkeit, mehrere Umgebungen in einem iOS-Projekt zu unterstützen, besteht darin, Konfigurationen auf Projektebene hinzuzufügen.


Konfigurationen auf Projektebene

Nachdem Sie die Konfigurationen definiert haben, können Sie eine Configuration.plist-Datei erstellen, die Variablen für jede Umgebung enthält.


Konfigurationsliste

Beim Starten eines Projekts kann angegeben werden, welche Konfiguration verwendet werden soll. Sie können dies in einem Baugruppendiagramm tun.



Anschließend müssen Sie der Info.plist-Projektdatei eine weitere Eigenschaft hinzufügen. Der Wert dieser Eigenschaft wird zur Laufzeit im Namen der aktuellen Konfiguration dynamisch ersetzt.


All dies ist in der Vorlage vorkonfiguriert.

Es bleibt nur eine Klasse zu schreiben, die diese Variablen zur Laufzeit extrahieren kann, abhängig von der im Assembly-Schema ausgewählten Konfiguration. Die Vorlage enthält die ConfigurationManager- Klasse, mit der Variablen für die aktuelle Umgebung abgerufen werden können. Sie können auch die Implementierung dieser Klasse in Github überprüfen, um zu sehen, wie sie funktioniert.

Readme

Jedes Projekt sollte eine Readme-Datei enthalten, die mindestens Anweisungen zum Installieren von Abhängigkeiten und zum Starten des Projekts enthält. Es sollte auch Beschreibungen der Projektarchitektur und der Module enthalten. Leider schreiben Entwickler keine Dokumentation (die Readme-Datei ist Teil dieser Arbeit), und ich habe ein Projekt gesehen, das seit Monaten entwickelt wurde, und es hatte sogar eine Readme-Datei. Um das Schreiben einer Readme-Datei zu vereinfachen, enthält die Vorlage eine Standard-Readme-Datei , die die Installation und Struktur des Projekts abdeckt. Wenn Sie ein neues Projekt mithilfe von Vorlagen einrichten, fügen Sie automatisch die Readme-Datei hinzu.

Gitignore

Derzeit verwenden die meisten Projekte GIT als Versionskontrollsystem. Bei Verwendung von GIT möchten Entwickler einige Dateien oder Ordner im Projekt nicht ignorieren, z. B. den Build-Ordner oder den abgeleiteten Datenordner. Damit der Entwickler keine für sein iOS-Projekt geeignete Gitignore-Datei finden muss, enthält die Vorlage den von den Mitgliedern von Github bereitgestellten Standard-Gitignore.

Basisklassen für den Umgang mit externen Links und Benachrichtigungen

Heutzutage sollte fast jede Anwendung externe Links und Benachrichtigungen verarbeiten. Dazu muss der Entwickler Standardcode in die AppDelegate-Klasse schreiben. Diese Vorlage enthält eine Beschreibung der Vorgehensweise sowie Basisklassen , die das Arbeiten mit externen Links und Benachrichtigungen erleichtern.

Fazit

Zusammenfassend enthält die beschriebene Vorlage die besten Ansätze und integriert nützliche Tools von Drittanbietern. All dies sollte Ihrer Teamentwicklungszeit sparen, die Sie für die Einrichtung eines neuen Projekts aufgewendet haben, und eine gemeinsame und solide Grundlage für den Rest des Projekts bieten. Lassen Sie sich und dieses Team von dieser Vorlage unterstützen!