English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Nachdem Sie die Pods-Abhängigkeiten anderer Personen gelernt haben, möchten Sie sicherlich, Ihre eigenen Abhängigkeiten zu erstellen, heute werden wir das Geheimnis des Erstellungsprozesses der Pods-Abhängigkeiten enthüllen. Der gesamte Erstellungsprozess basiert auf einem von mir implementierten View namens WZMarqueeView, die Schritte sind wie folgt:
Eins: Erstellen Sie Ihr eigenes GitHub-Repository
CocoaPods werden auf GitHub gehostet (offizieller Link:https://github.com/CocoaPods) Alle Pods-Abhängigkeiten sind auch von GitHub abhängig, daher müssen wir als erstes ein eigenes GitHub-Repository erstellen. Das Erstellungsinterface des Repositories ist wie folgt gezeigt:
In dem obigen Bild sind insgesamt6Die entsprechenden Erklärungen sind wie folgt:
1、Repository-Name
Repository-Name, hier in WZMarqueeView geschrieben, obligatorisch;
2、Beschreibung
Beschreibungsinformationen des Repositories, optional;
3、Öffentlichkeit des Repositories
Hier kann nur Public gewählt werden, einerseits, weil Private Geld kostet, andererseits, weil Private niemand sehen kann, warum sollte man es teilen;
4、Ob ein Standard-README-Datei erstellt wird
Ein vollständiges Repository benötigt eine README-Documentation, empfohlen wird, dies anzukreuzen. Natürlich können Sie auch später manuell eine erstellen, wenn Sie keine Probleme damit haben;
5、Ob die .gitignore-Datei hinzugefügt wird
Die .gitignore-Datei enthält mehrere Dateitypen, für alle Dateitypen, die in dieser Datei enthalten sind, werden sie von Git nicht in die Versionsverwaltung aufgenommen. Ob Sie diese auswählen, hängt von Ihren Bedürfnissen ab;
6、Lizenztyp
Regelmäßige Repositories sollten eine Lizenzdatei haben, Pods-Abhängigkeiten haben höhere Anforderungen an diese Datei und sie muss vorhanden sein. Daher ist es am besten, dass GitHub eine erstellt, oder Sie können sie später selbst erstellen. Ich verwende den Lizenztyp MIT.
Nachdem alle oben genannten Felder ausgefüllt sind, klicken Sie auf die Schaltfläche Create repository, das erfolgreiche Fenster ist wie folgt gezeigt:
Bis hierher ist der Prozess der Erstellung des Repositories abgeschlossen.
Zwei: Clonen des Repositories auf den lokalen Computer
Um den Inhalt des Repositories zu löschen, müssen Sie zunächst das Repository lokal clonen, es gibt mehrere Methoden, empfohlen wird der Befehlszeilenmodus:
$ git clone https://github.com/wangzz/WZMarqueeView.git
Nach Abschluss der Operation werden die entsprechenden Dateien auf GitHub in das lokale Verzeichnis kopiert, die Verzeichnisstruktur ist wie folgt:
Die .gitignore-Datei im Repository auf GitHub ist eine versteckte Datei, die mit einem Punkt beginnt, daher sind hier nur zwei sichtbar.
Alle zukünftigen Dateiänderungen, Hinzufügungen und Änderungen erfolgen in diesem Verzeichnis.
Drei: Fügen Sie die Dateien hinzu, die für die Erstellung der Pods-Abhängigkeitsbibliothek erforderlich sind
Hinweis: Alle nachstehenden Beschreibungsdateien müssen im Hauptverzeichnis des lokalen Git-Repositorys untergebracht werden.
1mit der Endung .podspec
Diese Datei ist die Beschreibungsdatei für die Pods-Abhängigkeitsbibliothek, jede Pods-Abhängigkeitsbibliothek muss genau eine solche Beschreibungsdatei haben. Der Dateiname muss mit dem Namen übereinstimmen, den wir erstellen möchten, und der Dateiname der WZMarqueeView-Abhängigkeitsbibliothek ist WZMarqueeView.podspec.
11 Inhalt der podspec-Datei
Der Inhalt der Speicherung von WZMarqueeView.podspec ist:
Pod::Spec.new do |s|
s.name = "WZMarqueeView"
s.version = "1.0.0"
s.summary = "Ein Marquee-View, das auf iOS verwendet wird."
s.description = <<-DESC
Es ist ein Marquee-View, das auf iOS verwendet wird und durch Objective implementiert wird.-C.
DESC
s.homepage = "https:"//github.com/wangzz/WZMarqueeView"
# s.screenshots = "www.example.com/screenshots_1", "www.example.com/screenshots_2"
s.license = 'MIT'
s.author = { "王中周" => "wzzvictory_tjsd@"163.com" }
s.source = { :git => "https:"//github.com/wangzz/WZMarqueeView.git", :tag => s.version.to_s }
# s.social_media_url = 'https:'//twitter.com/NAME''
s.platform = :ios, ''43'
# s.ios.deployment_target = ''5.0''
# s.osx.deployment_target = ''107'
s.requires_arc = true
s.source_files = 'WZMarqueeView'/*'
# s.resources = 'Assets'
# s.ios.exclude_files = 'Classes'/osx'
# s.osx.exclude_files = 'Classes'/ios'
# s.public_header_files = 'Classes'/**/*.h'
s.frameworks = 'Foundation', 'CoreGraphics', 'UIKit'
end
Diese Datei ist eine Ruby-Datei, die Einträge sind leicht zu verstehen.
Einige Parameter müssen erläutert werden:
① s.license
Lizenztyp der Pods-Abhängigkeitsbibliothek, füllen Sie bitte Ihre Auswahl aus.
② s.source_files
Stellt den Pfad der Quelldateien dar, achte darauf, dass dieser Pfad relativ zur podspec-Datei ist.
③ s.frameworks
Benötigte Frameworks, ohne den Suffix .frameworks hinzuzufügen.
12 Wie man eine podspec-Datei erstellt
Es gibt zwei Wege, um Ihre eigene podspec-Datei zu erstellen:
① Kopieren Sie meine podspec-Datei und ändern Sie die entsprechenden Parameter, dies wird empfohlen.
② Führen Sie folgende Erstellungsanweisung aus:
$ pod spec create WZMarqueeView
Es wird auch eine Datei namens WZMarqueeView.podspec erstellt. Aber wenn Sie die erstellte Datei öffnen, werden Sie feststellen, dass es darin viele Dinge gibt, die wir nicht benötigen.
2
CocoaPods verlangt zwingend, dass alle Pods-Abhängigkeitsbibliotheken eine Lizenzdatei haben müssen, anderenfalls wird die Überprüfung nicht bestanden. Es gibt viele Arten von Lizenztypen, Details können auf der Website tl;dr Legal nachgelesen werden. Beim Erstellen eines GitHub- Repositories habe ich bereits die Lizenzart MIT ausgewählt.
3
Die Erstellung der Pods-Abhängigkeitsbibliothek dient dazu, es anderen Leuten zu erleichtern, unsere Ergebnisse zu nutzen, z.B. die von mir allen zur Verfügung gestellte WZMarqueeView-Klasse, die ich den breiten Nutzern zur Verfügung stellen möchte, ist natürlich unerlässlich. Ich habe die beiden Dateien dieser Klasse in einen Ordner namens WZMarqueeView gepackt, die entsprechende Verzeichnisstruktur ist wie im folgenden Bild dargestellt:
Es enthält zwei Dateien: WZMarqueeView.h und WZMarqueeView.m
4
Um anderen Menschen das schnelle Verständnis und die Verwendung unserer Pods-Abhängigkeitsbibliotheken zu vermitteln, ist in der Regel erforderlich, einen Demo-Projekt bereitzustellen. Das von mir erstellte Demo-Projekt wurde in einem Ordner namens WZMarqueeViewDemo abgelegt, der Dateien wie im folgenden Bild enthält:
5、README.md
Diejenigen, die GitHub verwenden, sollten diese Datei kennen. Es ist ein unverzichtbarer Bestandteil eines erfolgreichen GitHub-Repositories und wird im Markdown-Format verwendet, um detaillierte Informationen über das Repository zu geben.
Das Gesagte5sind die grundlegenden Dateien, die für die Erstellung von Pods-Abhängigkeitsbibliotheken erforderlich sind, darunter1、2、3ist obligatorisch,4、5ist optional, aber stark empfohlen.
Nachdem diese Dateien hinzugefügt wurden, hat sich das Verzeichnis der lokalen GitHub-Repository wie im folgenden Bild gezeigt verändert:
V. Übertragen der geänderten Dateien auf GitHub
Nach dem dritten Schritt wurden viele Dateien in das lokale git-Repository hinzugefügt. Jetzt müssen diese in das GitHub-Repository übertragen werden. Der Übertragungsprozess gliedert sich in folgende Schritte:
1、Pod-Prüfung
Führen Sie die folgenden Befehle aus:
$ Setzen Sie die neue Version auf 1.0.0 $ Setzen Sie den neuen Tag auf 1.0.0
Diese beiden Befehle dienen dazu, eine Versionsnummer für pod hinzuzufügen und einen Tag zu setzen. Danach führen Sie das pod-Prüfkommando aus:
$ pod lib lint
Falls alles normal verläuft, sollten Sie nach Ausführung dieses Befehls die folgenden Ausgaben sehen:
-> WZMarqueeView (1.0.0) WZMarqueeView hat die Prüfung bestanden.
Bis hierher ist die pod-Prüfung abgeschlossen.
Zu beachten ist, dass bei der Ausführung des pod-Prüfkommandos jede Warnung oder Fehlermeldung das Ergebnis negativ beeinflussen wird! Wenn es zu einer Abweichung beim Prüfen kommt, werden detaillierte Informationen ausgegeben, die Sie entsprechend verwenden können, um Änderungen vorzunehmen.
2、Übertragen der Inhalte der lokalen git-Repository auf das GitHub-Repository
Führen Sie die folgenden Befehle nacheinander aus:
$ git add -A && git commit -m "Release 1.0.0." $ git tag '1.0.0' $ git push --tags $ git push origin master
Die oben genannten Befehle gehören zum Bereich von git und werden hier nicht weiter erläutert. Wenn alles normal verläuft, sollten Sie auf GitHub die von Ihnen hinzugefügten Inhalte sehen können. Wie im folgenden Bild gezeigt:
V. Hochladen der podspec-Datei auf das offizielle Repository von CocoaPods
Nach den ersten vier Schritten könnten Sie denken, dass alles vorbei ist, aber das ist leider noch nicht der Fall.
Um sicherzustellen, dass eine Pods-Abhängigkeitsbibliothek tatsächlich verfügbar ist, müssen Sie einen letzten Schritt durchführen: Laden Sie die von uns erstellte podspec-Datei auf das offizielle Specs-Repository von CocoaPods hoch, das unter folgendem Link zu finden ist: https://github.com/CocoaPods/Specs
Öffnen Sie diesen Link und Sie werden feststellen, dass alle Pods-Abhängigkeitsbibliotheken, die wir verwenden können, sowie alle Pods, die wir mit dem Befehl pod search suchen können, ihre podspec-Dateien in diesem Repository hochladen. Das bedeutet, dass nur wenn unsere podspec-Datei in dieses Repository hochgeladen wird, sie zu einer echten Pods-Abhängigkeitsbibliothek wird und andere sie normal verwenden können!
Nach den Regeln von git muss man, um Dateien in das Repository anderer hinzuzufügen, zunächst ein fork des anderen Repositorys erstellen, die entsprechenden Änderungen vornehmen und dann an den Originalautor pushen. Warten Sie auf die Genehmigung des Autors, und fügen Sie ihn dann in das ursprüngliche Repository ein.
Nachdem der Prozess verstanden wurde, wissen Sie natürlich, was zu tun ist:
1Ein fork des offiziellen CocoaPods Specs Repository erstellen
Gehen Sie in den Link des offiziellen Repositorys, klicken Sie auf den Fork-Button oben rechts im Bildschirm, wie folgt:
Dann finden Sie, dass es unter Ihrem Namen eine zusätzliche Repository-Branche gibt. Zum Beispiel ist meine Branche:
2Das forkte Repository lokal klonen
Führen Sie die folgenden Befehle aus:
$ git clone https://github.com/wangzz/Specs.git
Bitte beachten Sie, dass alle Repository-Adressen durch Ihre eigenen ersetzt werden müssen.
Dieser Repository ist etwas groß, man muss geduldig sein.
3Die eigene podspec-Datei zum lokalen Specs Repository hinzufügen
Nachdem das Specs Repository lokal geklont wurde, wird es in ein Verzeichnis namens Specs gelegt. Das Speicherprinzip der podspec-Datei im Specs Repository ist:
> Verzeichnis mit gleichem Namen wie die Pods-Abhängigkeitsbibliothek---> Verzeichnis mit gleichem Namens wie der Versionsnummer---> podspec-Datei
Nach diesem Prinzip muss ich im Verzeichnis Specs ein Verzeichnis namens WZMarqueeView erstellen, dann in das Verzeichnis WZMarqueeView wechseln und ein Verzeichnis mit dem Namen1In das Verzeichnis .0.0 wechseln, und letztendlich in1In das Verzeichnis .0.0 kopieren, und die zuvor erstellte Datei WZMarqueeView.podspec hineinkopieren.
Es ist nicht schwer zu verstehen, dass wenn in Zukunft eine Aktualisierung der Klasse WZMarqueeView erforderlich ist, ein Verzeichnis mit dem Namen der entsprechenden Versionsnummer unter WZMarqueeView erstellt wird, um die podspec-Datei der entsprechenden Version zu speichern.
Nach Abschluss dieser Aktionen, ist die Verzeichnisstruktur wie folgt:
4Die Änderungen im lokalen Specs Repository auf das GitHub-Repository hochladen
Führen Sie die folgenden Befehle aus:
$ git add -A && git commit -m "Fügen Sie die Datei WZMarqueeView podspec hinzu" $ git push origin master
Nach dem Erfolg können Sie die soeben hochgeladene Datei im eigenen forkten Specs Repository auf GitHub sehen.
5Die Änderungen, die Sie im eigenen forkten Specs vornehmen, werden auf das offizielle Specs Repository von CocoaPods gezogen
In das eigene forkte Specs Repository eintreten, sehen Sie eine grüne Schaltfläche oben links auf dem Bildschirm:
Wenn Sie auf diesen Button klicken, öffnet sich wie im folgenden Bild gezeigte Oberfläche:
Klicken Sie auf den grünen Button "Create Pull Request", um die Änderungen, die wir im geforkten Specs vorgenommen haben, an das offizielle Specs-Repository von CocoaPods zu übertragen.
Nach diesem Schritt bleibt nur noch warten, auf dass die Betreuer von CocoaPods unsere Änderungen überprüfen und die von uns gezogenen Änderungen in das offizielle Specs-Repository integrieren. Dieser Prozess dauert in der Regel einen Tag oder so. Bei jeder Nachricht, wie z.B. wenn die Überprüfung abgelehnt wird oder wenn sie genehmigt wird, wird CocoaPods offiziell eine E-Mail senden.
Wenn die Überprüfung genehmigt wird, können wir unseren hochgeladenen Ordner in der offiziellen Specs-Bibliothek sehen.
6und überprüfen Sie den Überprüfungsfortschritt
Natürlich können wir auch den Überprüfungsfortschritt überprüfen, öffnen Sie diesen Link:https://github.com/CocoaPods/Specs/Pullshier können Sie alle Pull-Anfragen der Specs-Repository sehen, wie im folgenden Bild gezeigt:
Der rote Kreis zeigt die Anfrage, die ich soeben gezogen habe, und wenn Sie darauf klicken, können Sie den entsprechenden Überprüfungsfortschritt sehen.
Sechst, überprüfen Sie unsere selbst erstellten Pods-Abhängigkeitsbibliotheken
Wenn Sie eine E-Mail von CocoaPods erhalten, in der die Überprüfung genehmigt wurde, möchten Sie wahrscheinlich sofort auf Ihrem Computer den Befehl pod search ausführen, um zu sehen, ob Sie Ihre eigenen Pods-Abhängigkeitsbibliotheken finden können. Aber Sie werden enttäuscht sein, weil Sie einen zusätzlichen Befehl ausführen müssen, um den Suchbefehl pod search auf unserem lokalen Computer zu verwenden, um unsere Abhängigkeitsbibliotheken zu finden:
$ pod setup
In meinem ersten Artikel der CocoaPods-Serie: Eine detaillierte Erklärung von CocoaPods----In der letzten Teil des Fortgeschrittenen Kapitels wurde dieser Befehl vorgestellt, der alle Pods-Abhängigkeitsbibliotheken lokal aktualisiert. Nachdem Sie diesen Befehl ausgeführt haben, führen Sie weiter aus:
$ pod search WZMarqueeView
dann werden die entsprechenden Informationen angezeigt!
Nach all dem, hier endet der gesamte Prozess der Erstellung der Pods-Abhängigkeitsbibliothek! Freunde, sind Sie erfolgreich? Haben Sie Probleme? Bitte hinterlassen Sie einen Kommentar.
Siebent, Referenzdokumentation