Dependency Management in Xcode mit CocoaPods

Schokolade für den Mac
Kommentare

Ein gutes Management externer Bibliotheken ist für größere Softwareprojekte unabdingbar. Entsprechende Tools wie Maven sind beispielsweise für Java bereits Standard. Und wie sieht das für das Management von Objective-C-Code aus? Auch für iOS wird es immer wichtiger, auf externe Bibliotheken zu setzen. Eine sehr gute Lösung stellt das in Ruby programmierte Framework CocoaPods dar. Wir haben es uns genauer angesehen.

Tools wie Maven haben in den letzten Jahren gezeigt, wie wichtig ein gutes Management der verwendeten Bibliotheken innerhalb größerer Softwareprojekte ist. Diese Tools sind bei Java und C# bereits Standard und werden für größere Projekte fast immer eingesetzt. Die Situation bei Objective-C sah bisher anders aus: Jede Bibliothek musste einzeln und teilweise mit großem Aufwand in das existierende Projekt eingebunden werden. Hierzu gibt es viele verschiedene Vorgehensweisen. Jede weist eine Reihe von Problemen und Fallstricken auf. Auf der anderen Seite gibt es durch den großen Erfolg der Sprache und durch eine immer größere werdende Zahl an Nutzern von iOS-Geräten einen steigenden Bedarf an professioneller und vor allem effektiver Softwareentwicklung. Zur Erleichterung der Aufgaben gibt eine immer höhere Zahl an Frameworks und Klassenbibliotheken, die die Programmierarbeit erheblich vereinfachen. Mit diesen Hilfsmitteln lassen sich viele Standardaufgaben teilweise wesentlich besser erledigen. Meist sind diese nach einer anfänglichen Einarbeitungszeit nicht mehr aus dem Alltag eines Entwicklers wegzudenken. Das Ziel einer größtmöglichen Wiederverwendung steht auch bei der Entwicklung für diese Plattform an oberster Stelle. Das Stichwort für diese Art der Softwareentwicklung ist die so genannte modulare Programmentwicklung. Der Nachteil des Einsatzes vieler – teilweise voneinander unabhängiger Module – ist im Gegensatz dazu ein größerer Verwaltungsaufwand. Das gilt insbesondere dann, wenn bei den externen Komponenten auch auf Versionen der verschiedenen Bibliotheken und deren richtige Zusammenarbeit geachtet werden muss. Für diese ganzen Probleme gab es bisher keine einheitliche Lösung. Doch nun gibt es einen erfolgversprechenden Kandidaten. Es ist das Tool CocoaPods. CocoaPods ist ein in Ruby programmiertes Dependency-Management-Tool, das den Entwickler auf sehr elegante Weise bei der Verwaltung externer Bibliotheken und deren Einbindung in eigene Objective-C-Projekte unterstützt. Dieser Beitrag stellt in den kommenden Abschnitten die Verwendung von CocoaPods anhand von unterschiedlichen Beispielen vor [1]. Zunächst wird der Installationsprozess erläutert und danach in die generelle Verwendung des Frameworks eingeführt.

Die Installation von CocoaPods

Die Voraussetzung für die Verwendung von CocoaPods ist eine installierte Ruby VM. Hierauf kann in diesem Artikel nicht weiter eingegangen werden. Es wird daher auf die einschlägigen Quellen verwiesen werden. Die Installation von CocoaPods geschieht über das Paketsystem/den Installationsmanager gem von Ruby mit den folgenden Kommandozeilenaufrufen:

{sudo} gem install cocoapods
pod setup

Der erste Befehl ({sudo} gem install cocoapods) installiert das so genannte RubyGEM (Kasten) namens CocoaPods. Nach der Installation steht das Programm über den Konsolenbefehl pod zur Verfügung. Mittels des Befehls pod –help kann man testen, ob die Installation fehlerfrei durchgeführt wurde. Die Ausgabe auf der Konsole zeigt eine erste Hilfe für die Verwendung von CocoaPods. Das Kommandozeilentool pod ist hierbei ein Link auf ein Skript, das

1. die ruby-vm mithilfe eines Skript startet und
2. CocoaPods aufruft. Der zweite Befehl initialisiert die Daten von CocoaPods und führt ggf. ein Update mithilfe der Quellen durch.

Nach diesen Schritten ist CocoaPods einsatzbereit.

RubyGEM
RubyGems (oder kurz Gems) stellen das offizielle Paketsystem für die Programmiersprache Ruby dar. Es definiert ein Format und ein Werkzeug zur Verwaltung von Paketen und stellt ein Repository mit den verfügbaren Paketen bereit.
<p><em>Aufmacherbild: <a href=“http://www.shutterstock.com/pic.mhtml?id=167134703“ title=“Wheat and Oats Chocolate Cereal 
 von Shutterstock / Uhrheberrech: : karinkamon     „>Wheat and Oats Chocolate Cereal   </a> von Shutterstock / Urheberrecht: : karinkamon     </em></p>

[ header = Seite 2: Ein einführendes Beispiel ]

Ein einführendes Beispiel

Es werden anhand eines Beispiels die verschiedenen Aspekte von CocoaPods dargestellt. Dazu benötigen wir zuerst ein Xcode-Projekt. Dieses Projekt wird mehrere externe Bibliotheken benutzen und diese über CocoaPods beziehen. CocoaPods kann hierbei sowohl für MacOS X als auch für iOS-Projekte verwendet werden. Im Folgenden wird jedoch nur auf die Unterstützung in iOS-Projekten eingegangen. Unser Beispiel ist ein einfacher RSS-Reader. Dabei wird lediglich auf die Aspekte der Bibliotheksverwaltung eingegangen und die Implementierung vernachlässigt. Zuerst wird ein neues Projekt mit dem Namen RssReader erstellt (Abb. 1). Nach dem Erzeugen des Projekts wird dieses unmittelbar wieder geschlossen, damit CocoaPods seine Arbeit verrichten kann. Es muss auf die Konsole gewechselt werden. Um das Tool CocoaPods zu bedienen, ist der Konsolenbefehl pod zu verwenden. Über diesen Befehl können alle Funktionen von CocoaPods abgerufen werden. Wir wechseln nun in das Verzeichnis des Projekts und betrachten dessen Inhalt. Dieser sollte wie in Abbildung 2 aussehen. 

Abb. 1: Ein neues Projekt ist Voraussetzung, um CocoaPods zu testen

Abb. 2: Inhalt des Projektverzeichnisses des Projekts „RssReader“

Im nächsten Schritt legen wir eine Datei mit dem Namen Podfile an (ohne Extension). Diese Datei ist die Datenbasis für die Arbeit mit CocoaPods. Wie auch bei Maven wird in dieser Datei deskriptiv festgelegt, welche Abhängigkeiten das Projekt benötigt. Eingetragen wird als erstes, für welche Plattform entwickelt wird, also hier platform :ios. Beispielhaft ist eine erste Abhängigkeit für das RssReader-Projekt verzeichnet. Es handelt sich um das REST-Framework für iOS mit der Bezeichnung RestKit. Es dient dazu, die Inhalte der RSS-Dateien abzurufen. Die allgemeine Notation für das Einbinden einer Abhängigkeit zu einer externen Bibliothek lautet in CocoaPods wie folgt:

pod 'NameDerBibliothek'

Die gesamte Datei PodFile sieht also mit dieser Abhängigkeit wie folgt aus:

platform :ios
pod 'RestKit'

Hat man alle gewünschten Bibliotheken zusammengestellt und in das Podfile eingetragen, kann man CocoaPods anweisen, die Bibliotheken für dieses Projekt zu laden und in den Build-Prozess einzubinden. Im Beispiel beschränken wir uns auf die Abhängigkeit zu dem Framework RestKit. Die Auflösung und Installation geschieht über den Befehl pod install. Dieser wird über die Konsole in dem jeweiligen Ordner des gerade genutzten Projektes aufgerufen. Danach löst CocoaPods rekursiv alle Abhängigkeiten bezüglich der angegebenen Bibliotheken auf und prüft, ob diese in der gewünschten Version und für die spezifizierte Plattform verfügbar sind. Die Konsolenausgabe dieses Befehls ist in Abbildung 3 dargestellt. 

Abb. 3: Die Konsolenausgabe während des ersten Durchlaufs von pod install

Es ist zu sehen, dass bei der Angabe des Frameworks RestKit noch weitere (transitive) Abhängigkeiten hinzugekommen sind. Hier ist der Vorteil der Verwendung von CocoaPods ersichtlich: Wenn ein Programmierer dieses Framework manuell einbinden wollte, müsste auf all diese Bibliotheken verwiesen werden. Sofern CocoaPods alle Abhängigkeiten erfolgreich auflösen konnte, werden alle Bibliotheken in ein eigenes Xcode-Projekt namens Pods importiert. Dieses Projekt wird beim ersten Aufruf automatisch erzeugt. Weiterhin wird ein Workspace angelegt, und die beiden Projekte (das manuelle von uns erstellte und das von CocoaPods automatisch generierte) werden eingebunden. Ein Workspace ist in Xcode eine Sammlung von mehreren Projekten, die gemeinsam bearbeitet werden. Dabei stellt das Projekt Pods stellvertretend alle eingebundenen Frameworks/Bibliotheken dar. Auch sind im Projekt Pods alle Einstellungen zur Kompilierung und Pfade zu den Bibliotheken so gesetzt, dass das Projekt eigenständig erstellt werden kann. Das Schöne an dieser Lösung: Eventuelle zusätzliche Optionen zum Erstellen und Ausliefern des Projekts bleiben verborgen und belasten nicht das eigentliche Entwicklungsvorhaben. Es wird eine einzige Datei aus dem Pods-Projekt generiert. Dieses ist eine Library-Datei mit dem Namen LibPods.a. Sie enthält alle kompilierten Codeteile der Bibliotheken. Die Header der verwendeten Bibliotheken werden separat in das erstellte Projekt eingebunden und können somit direkt verwendet werden. Nach der Installation sollte das Verzeichnis des Projekts wie in Abbildung 4 aussehen.

Abb. 4: Das Verzeichnis des Projekts RssReader

Nach diesem Schritt muss nunmehr der neu generierte Workspace anstatt des Projekts geöffnet werden. Das ist notwendig, damit Xcode die Abhängigkeiten richtig zuordnen kann. Wenn alles richtig verlaufen ist, sollte der Workspace wie in Abbildung 5 aussehen. Dieses Konstrukt ist mit einem Klick auf BUILD AND RUN sofort kompilierbar und im Simulator lauffähig. Glückwunsch, Sie haben Ihr erstes Projekt mithilfe von CocoaPods erfolgreich erstellt!

Abb. 5: Der Workspace in Xcode für das erste Beispiel

[ header = Seite 3: Intensivierung ]

Intensivierung

Nach diesem ersten einfachen Beispiel wird nun auf weitere Aspekte von CocoaPods eingegangen. Das wichtigste Hilfsmittel bzw. Werkzeug, das CocoaPods zur Verfügung stellt, ist die Suchfunktion nach bestimmten Bibliotheken, die unterstützt werden. Die Suche bei CocoaPods kann über verschiedene Wege gelöst werden. Es gibt zum einen eine Suche auf der Webseite des Projekts. Hier kann man eingrenzen, ob man für iOS oder für MacOS entwickelt. Weiterhin kann man mittels Freitext nach verfügbaren Bibliotheken suchen. Beispielhaft wird in Abbildung 6 nach dem Logging-Framework Cocoalumberjack gesucht.

Abb. 6: Suche auf der Webseite des Projektes nach Frameworks

Die zweite Möglichkeit ist die direkte Suche über das Kommandozeilentool pod. Dazu gibt es den Parameter search. Abbildung 7 zeigt die Suche nach dem gleichen Framework auf der Kommandozeile. Die Vorteile gegenüber der Suche im Browser sind:

• Die Informationen stehen schneller zur Verfügung.
• Es werden mehr Informationen über ein einzelnes Framework angezeigt.

Man kann hier den in grünen Textzeichen geschriebenen Namen (ohne Versionsnummer) in die entsprechende Sektion im Podfile eintragen. Der Name stellt die ID der Abhängigkeit dar.

Abb. 7: Aktive Suche über die Kommandozeile

Wir wollen jetzt die zusätzliche Abhängigkeit CocoaLumberjack in das Projekt einbinden. Dieses erfolgt auf die gleiche – wie oben erläuterte – Weise. Dazu wird das Podfile mit dem entsprechenden neuen Eintrag versehen: 

platform :ios
pod 'RestKit'
pod 'CocoaLumberjack'

Nach dem Editieren ruft man erneut pod install auf, und die Abhängigkeiten werden aktualisiert. Es ist nach der Installation nicht zwingend notwendig, den Workspace zuvor zu schließen, da Xcode die Veränderung der Quelldateien bemerkt und mit einer Fehlermeldung das erneute Laden der Dateiinhalte empfiehlt (Abb. 8). Nach der Bestätigung auf den Button REVERT hat man den Workspace aktualisiert. 

Abb. 8: Information über eine festgestellt Veränderung des Workspace

Kennen sollte man auch die zusätzlichen Parameter der Methode search. Eine Eingabe von pod search ohne Parameter zeigt die verfügbaren Optionen (Abb. 9). Die wichtigste Option ist —full. Damit ist es möglich, alle Felder der zur Verfügung stehenden Bibliotheken zu durchsuchen (ein search ohne Parameter sucht nur im Titel). Nach dem Einbinden, Installieren und erneuten Laden der Sourcen in Xcode steht das CocoaLumberjack-Framework zur Verfügung.

Abb. 9: Kommandozeilenoptionen der Suche

Der nächste Schritt ist die Angabe einer Versionsnummer. Im Beispiel wurden bisher keine Versionsnummern verwendet. In diesem Fall nimmt CocoaPods immer die neueste Version, die für die angegebene Plattform zur Verfügung steht. Versionen werden innerhalb des Podfiles hinter dem Namen der Bibliothek in Hochkommata geschrieben und mit einem Komma abgetrennt. Ein Beispiel ist im nachfolgenden Listing zu sehen. Hier wird nicht die aktuellste Version von CocoaLumberjack genutzt, sondern die Version 1.3.3. Bei größeren Projekten sollten explizit Versionsnummern eingesetzt werden, da sonst ein nicht bemerktes Update einer Bibliothek zu unerwarteten Nebeneffekten führen kann. 

platform :ios
pod 'RestKit'
pod 'CocoaLumberjack', '1.3.3'

Es ist nicht nur möglich, eine bestimmte Versionsnummer anzugeben, sondern auch eine ganze Spanne von Versionen. Die Angaben können wie folgt spezifiziert werden:

> 0.1: alle Versionen, die höher als 0.1 sind
>= 0.1: alle Versionen, die höher als oder gleich 0.1 sind
< 0.1: alle Versionen, die niedriger als 0.1 sind
<= 0.1: alle Versionen, die niedriger als oder gleich 0.1 sind
~> 0.1.2: alle Versionen, die höher als 0.1.2 bis zur Version 0.2 sind, aber nicht die Version 0.2 

Kommen wir zu einem sehr spannenden Thema, das bei richtigem Einsatz zu Platz- und Performancevorteilen führt: die Angabe eines Geltungsbereichs einer Abhängigkeit. Dies gilt vor allem für größere Projekte, aus denen verschiedene Binaries (Targets) erzeugt werden, die wiederum auf verschiedenen Bibliotheken aufgebaut sind. Zum Beispiel ist es nicht sinnvoll, eine Bibliothek, die zum Generieren von Testdaten verwendet wird, in die Produktivversion einzubinden. Für diese Problemstellung bietet Cocoapods ebenfalls eine sehr elegante Beschreibungsmöglichkeit. Im folgenden Beispiel ist die Bibliothek CocoaLumberjack nur noch für den Testmodus eingebunden (also für das Target RssReaderTests). Generell wird für jedes angegebene Target eine eigene kompilierte Library-Datei erzeugt. Das ist sehr hilfreich, wenn aus einem Workspace unterschiedliche Targets für unterschiedliche Applikationen definiert werden. Es ist dann möglich, für jede Applikation separate Abhängigkeiten zu festzulegen:

platform :ios, '4.3'
pod 'RestKit', '0.10.3'
target :RssReaderTests do
    pod 'CocoaLumberjack'
end

Alle Targets der Applikation erhalten die Bibliothek RestKit in der Version 0.10.3. Das Target RssReaderTests bekommt zusätzlich den Verweis auf die Bibliothek CocoaLumberjack. Nach dem Aufruf von pod install existieren zwei verschiedene Library-Dateien (LibPods.a und libPods-RssReaderTests.a). Es ist möglich, innerhalb von CocoaPods einen scope (Gültigkeitsbereich) für eine Dependency festzulegen. 

Kommen wir zum nächsten Beispiel, um die möglichen Optionen zur Konfiguration besser studieren zu können (Listing 1).

platform :ios, '4.3'
xcodeproj "RelativePathProject/RelativePathProject.xcodeproj"
pod 'RestKit', '0.10.3'
target : RssReaderTests do
    pod 'CocoaLumberjack'
end
target :debug, :exclusive => true do
    pod 'Kiwi'
end

Das dargestellte Beispiel ist wie folgt zu interpretieren: Die Einstellungen werden auf die Plattform iOS Version 4.3 optimiert. Alle Targets erhalten die neueste Version von RestKit. Es ist möglich, die angegebene Plattform (platform) durch eine Versionsangabe zu ergänzen. Hiermit wird festgelegt, bis zu welcher iOS-Version der Build noch kompatibel ist. Listing 1 enthält noch mehr interessante Optionen von CocoaPods: 

• Das Original-Xcode-Projekt liegt in einem relativen Pfad zu dem Podfile.
• Mit der Angabe: exclusive => true wird festgelegt, dass das Target debug nur die explizit hierfür angegebenen Abhängigkeiten erhält. Im Normalfall würden auch transitive Abhängigkeiten zugewiesen werden. Dies ist durch die Angabe des Flags aber nicht der Fall. Es erfolgt eine Beschränkung auf die Abhängigkeit Kiwi.

Genauso einfach wie das Hinzufügen ist das Entfernen von Abhängigkeiten. Hierzu muss lediglich der Eintrag der Bibliothek in dem Podfile gelöscht und erneut der Befehl pod install aufgerufen werden. Danach ist die betreffende Bibliothek aus dem Workspace entfernt. 

[ header = Seite 4: Ein Blick hinter die Kulissen ]

Ein Blick hinter die Kulissen

Wie funktioniert CocoaPods intern? Das Verständnis für die interne Funktionsweise hilft, Fehler zu finden und eigene Ideen in das Projekt einzubinden. Generell ist anzumerken, dass sich CocoaPods bei der Handhabung, Verwendung und Funktionsweise stark am Arbeitsablauf des Tools bundler von Ruby orientiert [2]. Es handelt sich um ein Tool, um unterschiedliche Versionen von Bibliotheken konsistent zu halten und diese zu verwalten. Man kann sagen, dass CocoaPods sich die Funktionsweise von Bundler zunutze gemacht hat, um diesen Mechanismus auch für Objective-C-Anwendungen bereitzustellen. Grundlegend baut CocoaPods auf das bereits genannte Tool gem auf. CocoaPods vereinfacht und automatisiert nahezu alle Aufgaben rund um die Einstellungen des Build-Vorgangs. Hierzu gehören die Verwaltung von Ordnerstrukturen und die Verwaltung von (rekursiven) Abhängigkeiten. Bei dem Tool bundler wird zum Verwalten der Abhängigkeiten und Eigenschaften eine so genannte gemspec-Datei benutzt. Bei CocoaPods lautet die Datei .podspec. Diese enthält alle Informationen über die Abhängigkeiten und Metadaten der jeweiligen Bibliothek.

Nachfolgend wird der Installationsvorgang etwas genauer betrachtet und erläutert. Es werden zuerst die benötigten Ruby-Pakete heruntergeladen und lokal zur Verfügung gestellt. Danach wird die Datenbasis für die unterstützten Bibliotheken angelegt. Diese sind (in der jetzigen Version von CocoaPods) noch nicht direkt online durchsuchbar, sondern müssen lokal als Verzeichnis zur Verfügung stehen. Dazu existiert ein eigenes Github-Repository, das alle Informationen in Form dieser .podspec-Beschreibungsdateien enthält. Das Repository wird auf den Rechner geklont. Es kann unter [3] eingesehen werden (Abb. 10). 

Abb. 10: Das Spec-Repository

Dieses Repository liegt lokal im Ordner cocoapods. Er befindet sich unter dem Home-Verzeichnis des aktuellen Benutzers. Der Ordner enthält alle Beschreibungsdaten für die Bibliotheken, die CocoaPods bekannt sind. Separate Unterordner stehen für verschiedene Versionen zur Verfügung. Abbildung 11 zeigt einen Ausschnitt aus dem Verzeichnis.

Abb. 11: Die Ordnerstruktur von CocoaPods

Was ist der Inhalt dieser .podspec-Dateien? Es handelt sich um eine textuelle Beschreibung der Metadaten der Bibliothek. Hinter diesem Format verbirgt sich die Klasse Pod::Specification. Eine Beschreibung dieser Klasse findet sich in der Onlinedokumentation unter [4]. Jede .podspec-Datei ist eine Instanz dieser Klasse. Genau hier hat CocoaPods auch einen Vorteil gegenüber Maven: Bei Maven ist es üblich, die Beschreibung der Metadaten in XML vorzunehmen. Diese XML-Dateien müssen vor der Verwendung geparst und in Objekte gewandelt werden. Dagegen ist der Inhalt einer .podspec-Datei ein Ruby-Skript, das direkt Objekte in Ruby-Syntax beschreibt. Listing 2 zeigt die .podspec-Datei aus Abbildung 10. 

Pod::Spec.new do |s|
  s.name         = "iTunesSearch"
  s.version      = "0.1.0"
  s.summary      = "Block based iTunes store communication for iOS and Mac OS X."
  s.homepage     = "https: //github.com/gangverk/iTunesSearch"
  s.license      = 'MIT'
  s.author       = { "Gangverk" => "contact@gangverk.is" }
  s.source       = { :git => "https: //github.com/gangverk/iTunesSearch.git", :tag => s.version.to_s }
  s.ios.deployment_target = '5.0'
  s.osx.deployment_target = '10.6'
  s.source_files = 'iTunesSearch/*.{h,m}'
  s.requires_arc = true
end

Das Beispiel in Listing 1 beschreibt die Eigenschaften der Bibliothek iTunesSearch in der Version 0.1.0. Sie gibt u. a. den Ort der Dokumentation und den Namen des Autors an. Diese Eigenschaften können für jede einzelne Version der Bibliothek gesetzt werden. Tabelle 1 zeigt mögliche Attribute. 

Attribut Beschreibung
name der Name der Bibliothek
version die Version der Bibliothek
summary eine Zusammenfeassung zum Inhalt der Bibliothek
homepage ein Verweis auf die Homepage der Bibliothek
dependency die Abhängigkeiten zu anderen Pods
author der Name des Autors der Bibliothek
source der URL zu den Quellcodedateien
platform die unterstützten Plattformen der Bibliothek (iOS oder Mac OS)
source_files enthält eine Beschreibung, welche Arten von Dateien als Quellcode verwendet werden
compiler_flags zusätzliche Flags zum Kompilieren der Bibliothek
requires_arc zeigt an, ob diese Version der Bibliothek mit ARC-Option (Kasten) kompiliert werden muss
libraries listet alle Libraries auf, die diese Bibliothek benötigt
subspec ein Submodul innerhalb der Bibliothek

Tabelle 1: Die Attribute der Klasse Pod::Specification

ARC
ARC (automatic reference counting) ist eine automatische Verwaltung von Referenzen (Zeigern) auf ein bestimmtes Objekt. Das Ziel ist es, zu erkennen, wann ein Objekt wieder aus dem Speicher gelöscht werden kann. Der Entwickler muss sich nicht mehr um diese Verwaltungsarbeiten kümmern.

Auf das source-Attribut wird genauer eingegangen. Es definiert, aus welcher Quelle der Code geladen wird. Es werden folgende Formate unterstützt:

Git Repositories
Mercurial Repositorys
Subversion Repositories
HTTP-/FTP-Links zu Dateien mit dem Formaten .zip, .tgz, .tar und .tbz

Aus diesen Arten von Quellen kann der Code automatisch von CocoaPods geladen werden. Das bedeutet, man kann alle Bibliotheken, deren Quellen in einem solchen Format vorliegen, im Projekt als Abhängigkeit definieren und nutzen. Zusätzlich können verschiedene Versionen des Quellcodes angegeben werden. Listing 3 zeigt einige Beispiele zu den Versionsangaben.

Zeile 1 zeigt ein Git Repository, bei dem ein Tag (0.0.1) angegeben wurde.
Zeile 2: Ein SVN Repository, bei dem das Tag 1.0.0 angeben wurde.
Zeile 3: Ein Mercurial Repository, bei dem Verweis auf die Revision 1.0.0 erfolgt.
Zeile 4: Nochmalig ein Git Repository. Es wurde ein bestimmter commit referenziert. 

s.source       = { :git => "http: //EXAMPLE/Example.git", :tag => "0.0.1" }
s.source       = { :svn => 'http: //EXAMPLE/Example/tags/1.0.0' }
s.source       = { :hg  => 'http: //EXAMPLE/Example', :revision => '1.0.0' }
s.source       = { :git  => 'http: //EXAMPLE/Example', :commit => "baf1c407f74dd6ca6c6c8c46bc0a3a565e79d3b6"
}

Bis zur Version 0.15.0 von CocoaPods aktualisiert sich dieser Ordner nicht automatisch. Das bedeutet, dass die Datenbasis von CocoaPods mithilfe eines manuellen Updates (Befehl pod setup) erfolgen muss. Seit der Version 0.16.0 wird dies automatisch ausgeführt. 

Zusammenfassung und Fazit

In diesem Artikel wurde gezeigt, wie einfach ein beliebiges Projekt durch den Einsatz von CocoaPods profitieren kann. Nahezu jeden Tag stehen neue Bibliotheken für die Wiederverwendung zur Verfügung. Das Problem: Man muss diese finden! Dazu gibt es die Möglichkeit, den RSS Feed der Entwicklerseite zu abonnieren oder dem Entwickler-Account auf Twitter zu folgen [5]. Der Kasten „Bibliotheken für die Einbindung in eigene Projekte“ enthält einige interessante Bibliotheken, die die alltäglichen Programmieraufgaben erheblich vereinfachen können. Weitere Informationen – u. a. auch zu anderen interessanten Themen der IT und zur Programmierung – finden Sie auf den Seiten der Autoren [6]

Bibliotheken für die Einbindung in eigene Projekte (Beispiele)

• ZXing: Ein QR-Code-Scanner.
• ShareKit: Ein sehr einfaches Tool, um Inhalte mit vielfältigen sozialen Netzwerken zu teilen.
• Reachability: Ein Werkzeug, um die Netzwerkerreichbarkeit zu testen (mit 3G/WLAN-Unterscheidung).
• AFNetworking: Eine sehr leistungsfähige Netzwerkbibliothek für iOS.
• CocoaLumberjack: Ein sehr gutes Logging-Framework.
• QuickDialog: Eine sehr einfach zu benutzende Bibliothek um Dialoge zu erstellen.
• IAPManager: ein Interface, welches die Verwaltung von Inn-App-Käufen erleichtert

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -