CocoaPods par David Yang

241 vues

Publié le

Introduction et présentation de CocoaPods et ses bonnes pratiques. Tout ce qu’il faut savoir sur son fonctionnement, comment et pourquoi écrire ses propres librairies tierces et bien utiliser cet outil (astuces et bonnes pratiques).

Publié dans : Mobile
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
241
Sur SlideShare
0
Issues des intégrations
0
Intégrations
0
Actions
Partages
0
Téléchargements
4
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Historiquement, intégrer des bibliothèques tierces dans une application était un enfer.

    Le but principal de CocoaPods est de faciliter tout ça.

    CocoaPods en lui-même un projet opensource, hebergé sur GitHub et écrit en Ruby.
  • On a donc fait notre pod install.

    Qu’est ce qui a changer ??
  • Use_frameworks! -> CocoaPods écrit en Swift
  • Et après ça ?

    On a listé nos dépendances, il ne reste plus qu’à les installer.
  • Et après ça, on est tout bon !

    Mais que s’est-il passé ? On va le voir dans le chapitre
  • Du côté Finder…

    CocoaPods nous a crée un workspace.
    On a notre fichier Podfile.
    Le fichier Podfile.lock et un dossier Pods.

    Dorénavant on utilisera le workspace !
  • Nos dépendances ont en fait été regroupées dans un projet « Pods ».

    Depuis notre projet principal, on a donc désormais accès à toutes les bibliothèques tierces qui se sont retrouvées dans le projet Pods.
    Comment on fait-ça ? -> Next slide.
  • On a vu combien c’est pratique d’utiliser CocoaPods pour nos projets iOS.

    Et pour aller plus loin, il peut arriver qu’on ait envie de créer nos propres Pods
  • Le code de notre pod va dans Pod.

    Example : projet d’example utilisant notre Pod.
    On voit que dedans on a un Podfile qui en fait indique au projet exemple d’utiliser le pod qu’on vient de créer.

    Remarque, lorsqu’on ajoute des resources, il faut donc faire un pod update dans le projet Example !
    C’est aussi dans le projet Example qu’on fait les TU pour notre Pod.

    Transition : le podspec !
  • Il s’agit d’un fichier qui présente votre Pod (nom, version, repo git, branche, description, etc).

    Il fournit également des informations importantes lorsqu’ils sont ajouté à un projet :
    Les sources du Pods
    Les frameworks natifs
    Les dépendances
    Les resources à embarquer

    Ce fichier est indispensable à l’utilisation d’un Pod. On ne peut pas l’installer sans.
  • Pod trunk push :

    Pousse le fichier podspec sur le repo Git officiel de CocoaPods.
  • Numéro de version : évite d’avoir une dépendance mise à jour malencontreusement lors de pod update

    :tag ou :branch -> pour récupérer des versions experimentales en Swift 3 par exemple…
  • Numéro de version : évite d’avoir une dépendance mise à jour malencontreusement lors de pod update

    :tag ou :branch -> pour récupérer des versions experimentales en Swift 3 par exemple…
  • Numéro de version : évite d’avoir une dépendance mise à jour malencontreusement lors de pod update

    :tag ou :branch -> pour récupérer des versions experimentales en Swift 3 par exemple…
  • CocoaPods par David Yang

    1. 1. COCOAPODS : INTRODUCTION ET BONNES PRATIQUES COCOAHEADS – SESSION OCTOBRE 2016
    2. 2. SOMMAIRE Introduction Présentation Installation Utilisation Fonctionnement Créer ses propres Pods Bonnes pratiques Q/R 17.11.16 BACKELITE 2
    3. 3. INTRODUCTION
    4. 4. INTRODUCTION Cocoa Pod 17.11.16 4BACKELITE = Gousse de Cocoa
    5. 5. INTRODUCTION CocoaPods est un gestionnaire de dépendances pour les projets Cocoa. 17.11.16 5BACKELITE
    6. 6. PRÉSENTATION
    7. 7. Xcode Workspace FONCTIONNEMENT 17.11.16 BACKELITE 7 AFNetworking SwiftyJSON MagicalRecord CocoaPods Repo Xcode Project Podfile - AFNetworking - MagicalRecord - SwiftyJSON AFNetworking podspec MagicalRecord podspec SwiftyJSON podspec Pods Project AFNetworking SwiftyJSON MagicalRecord
    8. 8. INSTALLATION
    9. 9. INSTALLATION 17.11.16 BACKELITE 9 • Une seule commande : sudo gem install cocoapods
    10. 10. UTILISATION
    11. 11. UTILISATION 17.11.16 BACKELITE 11 Le fichier Podfile • Placé à la racine du projet (au même niveau que xcodeproj) • Liste toutes les dépendances du projet Comment ? pod init
    12. 12. UTILISATION Exemple de fichier Podfile platform :ios, '8.0' use_frameworks! target 'MyApp' do pod 'AFNetworking', '~> 2.6' pod 'ORStackView', '~> 3.0' pod 'SwiftyJSON', '~> 2.3' end 17.11.16 BACKELITE 12
    13. 13. UTILISATION Comment trouver des Pods (ou leurs noms) ? • https://cocoapods.org/ • Directement sur les repos GitHub • En ligne de commande : pod search [QUERY] 17.11.16 BACKELITE 13
    14. 14. Et après ça ? 17.11.16 BACKELITE 14
    15. 15. UTILISATION 17.11.16 BACKELITE 15 pod install
    16. 16. UTILISATION 17.11.16 BACKELITE 16
    17. 17. UTILISATION 17.11.16 BACKELITE 17
    18. 18. UTILISATION Comment utiliser nos Pods dans notre projet ? Un simple #import à faire ! 17.11.16 BACKELITE 18
    19. 19. UTILISATION • Pour mettre à jour une dépendance pod update [POD_NAME] • Pour supprimer une dépendance pod install (après avoir supprimé votre dépendance du Podfile) 17.11.16 BACKELITE 19
    20. 20. Pourquoi CocoaPods est-il si pratique ? 17.11.16 BACKELITE 20
    21. 21. UTILISATION • Crée / met à jour un workspace • Ajoute votre projet au workspace • Récupère les specs des Pods à installer sur le repo master de CocoaPods (https://github.com/CocoaPods/CocoaPods) • Récupère les sources des Pods • Crée et ajoute la bibliothèque statique CocoaPods au projet (si nécessaire) • Ajoute libPods.a sur vos targets dans les Build Phases (Link with libraries) • Ajoute la Configuration Xcode CocoaPods à votre projet • Modifie la configuration de vos targets pour utiliser CocoaPods • Ajoute un script au Build Phase de vos targets pour copier les ressources des Pods (images, assets, XIB, etc). 17.11.16 BACKELITE 21
    22. 22. CRÉER SES PROPRES PODS
    23. 23. CRÉER SES PROPRES PODS DIVERSES RAISONS… 17.11.16 BACKELITE 23 • Isoler du code • Ré-utiliser son propre code dans plusieurs projets • « Modulariser » une grosse application • Contribuer à la communauté
    24. 24. CRÉER SES PROPRES PODS Comment ? pod lib create [MY_POD_NAME] 17.11.16 BACKELITE 24
    25. 25. CRÉER SES PROPRES PODS LA STRUCTURE D’UN POD $ tree MyLib -L 2 MyLib ├── .travis.yml ├── _Pods.xcproject ├── Example │ ├── MyLib │ ├── MyLib.xcodeproj │ ├── MyLib.xcworkspace │ ├── Podfile │ ├── Podfile.lock │ ├── Pods │ └── Tests ├── LICENSE ├── MyLib.podspec ├── Pod │ ├── Assets │ └── Classes │ └── RemoveMe.[swift/m] └── README.md 17.11.16 BACKELITE 25
    26. 26. CRÉER SES PROPRES PODS LE FICHIER PODSPEC Pod::Spec.new do |spec| spec.name = 'Reachability' spec.version = '3.1.0' spec.license = { :type => 'BSD' } spec.homepage = 'https://github.com/tonymillion/Reachability' spec.authors = { 'Tony Million' => 'tonymillion@gmail.com' } spec.summary = 'ARC and GCD Compatible Reachability Class for iOS and macOS.' spec.source = { :git => 'https://github.com/tonymillion/Reachability.git', :tag => 'v3.1.0' } spec.source_files = 'Reachability.h,m' spec.framework = 'SystemConfiguration' spec.requires_arc = true #spec.dependency 'SomeOtherPod’ spec.ios.deployment_target = '9.0' spec.osx.deployment_target = '10.10’ #spec.resource_bundles = { 'Reachability' => [’Images/*.png’] } end 17.11.16 BACKELITE 26
    27. 27. Comment utiliser nos Pods fraîchement crées ? 17.11.16 BACKELITE 27
    28. 28. CRÉER SES PROPRES PODS UTILISER UN POD LOCALEMENT Dans le Podfile de votre projet, préciser le path de votre Pod. pod 'AFNetworking', :path => '~/Documents/AFNetworking' 17.11.16 BACKELITE 28
    29. 29. CRÉER SES PROPRES PODS PUBLICATION SUR LE REPO OFFICIEL COCOAPODS 1. Vérifier votre podspec pod spec lint 2. Publier votre podspec sur le repo CocoaPods/Specs pod trunk push PODNAME.podspec Le podspec est alors disponible sur https://github.com/CocoaPods/Specs 17.11.16 BACKELITE 29
    30. 30. BONNES PRATIQUES
    31. 31. BONNES PRATIQUES GÉNÉRAL Un Pod doit : • Être fourni avec un projet Example contant : • Un exemple d’implémentation / d’utilisation • Des tests unitaires • Documenté (au moins un README) • Embarquer les ressources nécessaires à son utilisation (XIB, images, assets, media, fonts, etc.) • Déclarer ses propres dépendances dans son podspec (s’il y en a) • Être utilisable tel quel après un « pod install » 17.11.16 BACKELITE 31
    32. 32. BONNES PRATIQUES ASTUCES DIVERSES • Utiliser l’option --no-repo-update lors d’un pod install / update • Préciser les numéros de version de vos dépendances • Utiliser les options :tag ou :branch pour récupérer des versions spécifiques d’une dépendance qui n’a pas eu de release officielle sur un repo Spec • Eviter d’inclure vos pods dans des targets et scheme ou ils ne sont pas utiles • Penser à ajouter la ligne use_framewoks! dans votre Podfile en cas d’utilisation de Swift 17.11.16 BACKELITE 32
    33. 33. BONNES PRATIQUES ASTUCES DIVERSES • Dans le cas où votre pod contient des ressources à exploiter, c’est au pod lui-même de les retourner au projet hôte et non au projet hôte d’aller chercher dans le pod ! (XIB, Storyboard, images, media, font, etc.) 17.11.16 BACKELITE 33
    34. 34. BONNES PRATIQUES ASTUCES DIVERSES • Précisez le numéro de version de votre dépendance dans le Podfile ! • Consulter le fichier Podfile.lock pour suivre les versions installées de vos dépendances 17.11.16 BACKELITE 34
    35. 35. BONNES PRATIQUES POD PRIVÉ Utiliser un repo de Spec privé pour vos outils internes. Il s’agit d’un simple repo GIT. Pour l’ajouter à CocoaPods : pod repo add REPO_NAME SOURCE_URL Pour posser un podspec sur votre repo privé pod repo push REPO_NAME MyPod.podspec 17.11.16 BACKELITE 35
    36. 36. BONNES PRATIQUES POD PRIVÉ Solution alternative (sans repo Spec privé) Préciser le repo Git du Pod à utiliser. Exemple : pod 'AFNetworking', :git => 'https://github.com/gowalla/AFNetworking.git' Options possibles : :branch :tag :commit 17.11.16 BACKELITE 36
    37. 37. BONNES PRATIQUES AVANTAGES • Votre repo contient tout ce qu’il faut à votre projet pour fonctionner • Prévient de la disparition éventuelle d’une dépendance • En cas d’utilisation d’une intégration continu, ne nécessite pas d’effectuer un « pod install » côté IC, ce qui peut allonger le temps de construction d’un build. 17.11.16 BACKELITE 37 Faut-il pousser les sources des Pods avec votre projets sur vos repos GIT/SVN ? INCONVÉNIENTS • Alourdi votre repo • Nécessite un meilleur suivi du versioning de vos dépendances. • En travail collaboratif sur des pods privés, peut s’avérer difficile à maintenir.
    38. 38. Q/R
    39. 39. LIENS UTILES • https://guides.cocoapods.org/ 17.11.16 BACKELITE 39
    40. 40. 17.11.16 BACKELITE 40
    41. 41. david.yang@backelite.com www.backelite.com CONTACTEZ-NOUS YANG David iOS Developer / Tech Lead 17.11.16 BACKELITE 41

    ×