Seite 2: Beispiel

Inhaltsverzeichnis

Beispielhafter Einsatz von CocoaPods

Im Beispiel soll die erwähnte Bibliothek ZXing in einer iOS-Anwendung verwendet werden. Dazu initialisiert der Entwickler ein neues Projekt in Xcode und öffnet ein Terminal. Dort wechselt er in den Ordner, in dem sich die Projektdatei befindet. Hier legt er eine Datei namens "Podfile" mit den folgenden Inhalten an:

platform : ios,'6.0'
pod 'ZXingObjC',  '2.1.0'

Beim Aufruf des Befehls

$ pod install

im selbigen Ordner verarbeitet CocoaPods die Podfile und installiert die Projektabhängigkeiten. Dazu legt das Framework einen Workspace an (ein Konzept, das mit Xcode 4 hinzukam und das Verwenden mehrerer Projekte in einer Workspace-Datei erlaubt). Dadurch lassen sich Projektinhalte und Abhängigkeiten vollständig voneinander trennen. In Xcode sieht das wie in der folgenden Abbildung aus.

Nun lässt sich das eingebundene Projekt direkt im Sourcecode verwenden. Es ist keine weitere Konfiguration notwendig. Wichtig ist, ab jetzt nur noch die *.xcworkspace-Datei zu nutzen, da nur sie die Informationen über das eigene Projekt und die geladenen Abhängigkeiten enthält.

Eigene Pod-Bibliothek erstellen

Einmal verwendet möchte man CocoaPods nicht mehr missen. Für den dauerhaften Einsatz des Werkzeugs in eigenen Projekten stellen sich die folgenden Fragen:

• Wie wird ein Projekt wiederverwendbar (für den Entwickler selbst oder ggf. auch für andere)?
• Wie werden verschiedene Softwareversionen zuverlässig verwaltet?
• Lässt sich die Konfiguration der Projekteinstellungen vermeiden?

Eine zentrale Rolle spielen hier die podspec-Dateien. In ihnen sind alle wichtigen Projekteinstellungen und Versionsinformationen hinterlegt. Zur Verdeutlichung ein Beispiel einer solchen Datei:

Pod::Spec.new do |s|
  s.name         = "ZXingObjC"
  s.version      = "2.1.0"
  s.summary      = "An Objective-C Port of ZXing."
  s.homepage     = "https://github.com/TheLevelUp/ZXingObjC"
  s.author       = "ZXing team (http://...) and TheLevelUp"
  s.license      = { :type => 'Apache License, Version 2.0', 
                     :file => 'COPYING' }
  s.source       = { :git => "https://github.com/.../ZXingObjC.git", 
                     :tag => "2.1.0" }
  s.source_files = 'ZXingObjC/**/*.{h,m}'
  s.requires_arc = false
  s.frameworks   = 'ImageIO', 'CoreGraphics', 'CoreVideo',
                   'CoreMedia', 'QuartzCore', 
                   'AVFoundation', 'AudioToolbox'
end

Die meisten Felder sind selbsterklärend und folgen dem Prinzip "Convention over Configuration". Die Felder source und source_files sind allerdings beachtenswert, da sie über Schlüssel-Wert-Paare den Ort des Repository und das zu verwendende Commit/Tag angeben. Bewährt hat sich aber, anstelle eines Commits ein Tag zu erstellen und dieses zu verwenden. Dieses benennt man üblicherweise nach der Version. Dennoch kann anstelle des Tag- auch der Commit-Schlüssel verwendet werden. Die source_files lassen sich mit regulären Ausdrücken versehen, sodass man auch Definitionen wie ZXingObjC/**/*.{h,m} nutzen kann.

Die CocoaPods-Dokumentation beschreibt noch viele weitere Felder, aber es empfiehlt sich, aus anderen *.podspec-Dateien zu lernen. Die Sammlung aller bekannten *.podspec-Dateien unter ~/.cocoapods ist eine gute Quelle für Beispiele.

Nach dem Erstellen einer podspec-Datei lässt sich mit dem Aufruf

$ pod spec lint [Name_der_Datei].podspec

prüfen, ob die Konfigurationsdatei Fehler enthält und alle Pflichtfelder vorhanden sind. Sobald der Test erfolgreich beendet ist, ist die erste eigene podspec-Datei fertig. Nun gibt es zwei Möglichkeiten, die Arbeit abzuschließen:

1. durch das Erstellen eines Pull-Requests (für das Repository [https://github.com/CocoaPods/Specs]), damit die eigene Konfiguration mit etwas Wartezeit ins öffentliche CocoaPods-Repository übernommen wird, oder
2. durch das Hinzufügen der podspec-Datei zum lokalen Git-Repository (unter ~/.cocoapods), um sofort loslegen zu können.

In jedem Fall ist es sinnvoll, die eigene Konfiguration noch einmal in einem neuen Xcode-Projekt zu testen, um sicherzugehen, dass sich keine Fehler eingeschlichen haben.

Fazit

Dem Slogan "The best way to manage library dependencies in Objective-C projects" ist nichts hinzuzufügen. CocoaPods übernimmt die Projektkonfiguration und erspart Entwicklern die manuelle Nachbearbeitung. Es stellt viele Projekte und Frameworks zur Verfügung und erleichtert die Trennung zwischen verwendeten Bibliotheken und eigenem Sourcecode. Auch vererbte Abhängigkeiten stellen durch das Konzept von CocoaPods kein Problem mehr dar. Darüber hinaus ist das CocoaPods-Projekt sehr lebendig und wird hervorragend gepflegt. Änderungen und Updates werden regelmäßig getwittert.

Die podspec-Dateien sind einfach verständlich und gut erweiterbar. Hinzu kommt, dass sich auch lokale Projekte und Closed-Source-Projekte verwalten lassen. Es besteht somit kein Veröffentlichungszwang. Und zu guter Letzt ist die Installations- und Einarbeitszeit gering, da CocoaPods auf bekannte Techniken wie Git setzt und die Integration in Xcode-Projekte über Workspaces läuft.

CocoaPods erleichtert einem Entwicklungsteam die tägliche Arbeit deutlich und erhöht die Build-Geschwindigkeit drastisch. Darüber hinaus lassen sich auch bestehende Projekte einfach auf CocoaPods umstellen.

Benedikt Iltisberger
arbeitet als Mobility Consultant für die Management- und IT-Beratung Acando GmbH. Er ist Experte für Mobile Computing und IT-Security und verfügt über langjährige Projekt- und Entwicklungserfahrung im Mac/OS-X- und iOS-Umfeld. (ane)