Je eerste CocoaPod maken

Invoering

CocoaPods is een geweldige tool om te helpen met afhankelijkheidsbeheer bij het bouwen van iOS- of OS X-applicaties. Al jaren rond en goed ondersteund, is de volwassenheid van CocoaPods duidelijk. Hoewel het heel gewoon is om CocoaPods te gebruiken in uw iOS- of OS X-softwareprojecten, is het minder gebruikelijk om een ​​pod anderen te gebruiken. Deze tutorial begeleidt je bij het maken van je eerste pod en geeft je enkele tips over wat een geweldige pod kenmerkt.

1. Installeer CocoaPods

Vanzelfsprekend moet je CocoaPods installeren om een ​​pod te maken. Het is verkrijgbaar als een Ruby-juweel van RubyGems. Om CocoaPods te installeren, voert u de volgende opdrachten uit vanaf de opdrachtregel:

gem installeer cocoapods

Deze tutorial is geschreven tegen CocoaPods 0.37.2.

2. Stap voor stap overzicht

Van een hoog niveau zijn er vijf stappen nodig om je eerste pod te maken:

1. Bepaal het idee voor uw eerste pod.
2. Gebruik de pod lib commando om de skeletmapstructuur en de bijbehorende bestanden voor uw pod te maken.
3. Werk de metadata van uw pod bij, zoals de licentie- en versie-informatie.
4. Voeg de code voor uw pod toe. Dit omvat zowel de code voor de pod zelf als elke code die nodig is voor een voorbeeldproject.
5. Maak de pod openbaar beschikbaar.

3. Podstorming

Podstorming is eigenlijk geen woord, maar het is tijd om te brainstormen over de functionaliteit van je eerste pod. Er zijn meer dan 10.000 publiek beschikbare pods geïndexeerd in de officiële Specs repository. Mensen hebben allerlei dingen gevonden om als pod beschikbaar te maken. Hier zijn enkele suggesties om u te helpen met podstormen, ik bedoel, ik bedoel brainstormen:

• Functiecode: Heb je een unieke kijk op het uitvoeren van bepaalde stringmanipulaties? Heeft u een favoriete subklasse die u hebt geschreven voor het uitvoeren van een gelikte animatie op a UIView? Specifieke utility-code zoals deze is een goed voorbeeld van wat kan worden omgezet in een pod. Het is vaak al goed ingeburgerd en ontkoppeld van andere bestaande codebases.
• Pakketten van derden: Heeft u een wrapper rond een andere derde-partij-API gemaakt? Heeft u een app waarvoor u haken wilt leveren waarmee andere apps kunnen worden geïntegreerd, zoals voor verificatie? Biedt uw bedrijf een web-API voor webgebaseerde bronnen die nuttig zou kunnen zijn voor andere iOS-apps om eenvoudig mee te integreren? Als dat zo is, is een pod logisch, omdat dit een eenvoudige manier is om andere iOS-toepassingen eenvoudig te integreren met deze pakketten.
• UI-componenten: Heb je een Buttery-smooth UI-widget gemaakt die je graag wilt dat andere apps kunnen gebruiken? Dit zijn mijn favoriete pods. Het is geweldig om een ​​gecompliceerde en heerlijke UI-component toe te voegen aan een applicatie door simpelweg een pod-afhankelijkheid toe te voegen.
• Alles dat u wilt dat anderen kunnen gebruiken. Heb je iets gemaakt waarvan je denkt dat anderen het nuttig zouden vinden? Als dat zo is, verander het dan in een pod zodat anderen het gemakkelijk kunnen gebruiken.

In deze zelfstudie leer je een pod maken waarmee je een. Kunt maken UILabel dat knippert. We zullen het noemen BlinkingLabel.

4. Maak het project

Tijd om in te graven. Nu u weet welke functionaliteit uw pod gaat bieden, is het tijd om deze te maken. De pod lib opdracht is een belangrijke tool die we tijdens het aanmaakproces voor twee doelen gebruiken.

1. pod lib lint zal valideren dat alles in orde is met je pod en dat deze klaar is voor gebruik door CocoaPods.
2. pod lib maken zal je echt een vliegende start geven door een standaard directorystructuur te bieden met een aantal boilerplate-bestanden die nodig zijn voor een pod van hoge kwaliteit. pod lib maken is niet de enige manier om je pod te maken, maar het is de gemakkelijkste.

Open een Terminal-venster, navigeer naar een werkdirectory en voer de volgende opdracht uit:

pod lib maakt BlinkingLabel

• Wanneer u wordt gevraagd welke taal u wilt gebruiken, antwoordt u Snel.
• Als u wordt gevraagd of u een demotoepassing wilt opnemen, beantwoordt u dit Ja.
• Bij het bepalen of een monsterproject moet worden gemaakt of niet, stelt het CocoaPods-team voor zich af te vragen "Moet deze pod een schermafbeelding bevatten?" Als dat zo is, is het een goed idee om een ​​voorbeeldproject op te nemen.
• Op de vraag welk testkader moet worden gebruikt, antwoord Geen.
• Antwoord Nee naar de prompt met betrekking tot op view gebaseerde testen.

Testen valt buiten het bestek van deze zelfstudie, maar laat het niet stoppen om dit verder te onderzoeken na deze zelfstudie. De verhouding tussen tests en coderegels is een factor die in aanmerking wordt genomen door de kwaliteitsindex van CocoaPods.

Wanneer de steiger voor uw pod is ingesteld, opent Xcode uw gloednieuwe project, klaar om aan uw pod te werken.

5. Updaten van de metadata van uw pod

Er zijn drie belangrijke stukken metadata die bij uw pod moeten worden gevoegd:

• .podspec: Dit bestand beschrijft informatie over deze specifieke versie van uw pod. Uw pods, versienummer, startpagina en auteursnamen zijn enkele voorbeelden van wat is inbegrepen. Raadpleeg de officiële referentiepagina voor meer informatie.
• LEESMIJ: Als je GitHub eerder hebt gebruikt, weet je hoe belangrijk een README is. README van een project, geschreven in Markdown, wordt weergegeven op de startpagina van een project op GitHub. Een goede README kan het verschil zijn tussen iemand die je project gebruikt of niet. Bovendien draagt ​​het bij aan een high CocoaPods kwaliteitsindex ook.
  
• LICENTIE: Als u uw pod in de Spec-repository wilt laten accepteren, moet uw pod een licentie bevatten. De pod lib maken commando vult het LICENSE-bestand automatisch in met de MIT-licentie en dat is wat we gaan gebruiken voor deze tutorial.
  

Om de .podspec in vorm, open het in Xcode. Je zult het onder vinden BlinkingLabel / Podspec-metadata / BlinkingLabel.podspec. Gelukkig heeft CocoaPods een goed bevolkte sjabloon voor ons gemaakt toen we de pod lib makencommando. Je staat op het punt nog meer van die tool te houden. De pod lib lint commando valideert automatisch de .podspec bestand om ervoor te zorgen dat het voldoet aan de beste werkwijzen. Of, als je lui bent, kun je het ook gebruiken om erachter te komen welk absoluut minimum je moet doen om een ​​goed te maken .podspec het dossier.

Voer vanaf de opdrachtregel in de hoofdmap van het BlinkingLabel-project de volgende opdracht uit:

pod lib lint BlinkingLabel.podspec

Dit zou het volgende moeten uitvoeren:

> pod lib lint BlinkingLabel.podspec -> BlinkingLabel (0.1.0) - WARN | De samenvatting is niet zinvol. - WARN | De beschrijving is niet zinvol. - WARN | Er is een probleem opgetreden bij het valideren van de URL https://github.com// BlinkingLabel. [!] BlinkingLabel heeft de validatie niet doorstaan. U kunt de '--no-clean'-optie gebruiken om elk probleem te inspecteren.

De tool vertelt je dat er drie dingen moeten worden opgelost in de .podspec het dossier:

• voeg meer informatie toe aan de samenvatting
• voeg een goede beschrijving toe
• geef een URL op voor de startpagina van de pod

Hier zijn enkele voorgestelde waarden voor deze velden:

• s.summary: Een subklasse op UILabel dat levert een knipperen.
• s.description: Dit CocoaPod biedt de mogelijkheid om een ​​te gebruiken UILabel die kan worden gestart en gestopt met knipperen.
• s.homepage: https://github.com/obuseme/BlinkingLabel (vervang obuseme met je GitHub-gebruikersnaam)

Maar wacht even, als je de instructies stap voor stap hebt gevolgd, is er technisch gezien nog geen project op die URL. Het is tijd om je project naar een openbare repository op GitHub te pushen. Hoewel er andere opties zijn om je pods te hosten, is GitHub verreweg de meest voorkomende.

Om je project naar GitHub te pushen, blader je naar GitHub, log in of maak een account aan en maak een Nieuwe repository riep BlinkingLabel. Voer vervolgens vanaf de opdrachtregel de volgende opdrachten uit:

git add. git commit -m "Initial Commit" git remote add origine https://github.com//BlinkingLabel.git // vervangen  met je github.com gebruikersnaam git push -u originamaster

Op dit punt, als je alles goed hebt gedaan en het lint plukt, .podspec bestand opnieuw moet validatie worden doorgegeven.

> pod lib lint BlinkingLabel.podspec -> BlinkingLabel (0.1.0) BlinkingLabel geslaagd validatie.

6. Code toevoegen

Je hebt nu de basishell van een pod, maar deze doet niets. Het is tijd om wat functionaliteit toe te voegen. Het handige aan het voorbeeldproject dat CocoaPods voor u heeft gemaakt, is dat u tegelijkertijd code kunt schrijven voor zowel de pod als het voorbeeldproject.

Zoek eerst het bestand ReplaceMe.swift onder Pods / Ontwikkelingstoetjes / KnipperenLabel / pod / Lessen / en verwijder het.

Maak vervolgens een nieuw Swift-bestand in dezelfde map en geef het een naam BlinkingLabel.swift. Vervang de inhoud van het nieuwe bestand door het volgende:

public class BlinkingLabel: UILabel public func startBlinking () let options: UIViewAnimationOptions = .Repeat | .Autoreverse UIView.animateWithDuration (0.25, delay: 0.0, options: options, animations: self.alpha = 0, completion: nil) public func stopBlinking () alpha = 1 layer.removeAllAnimations ()

U hebt zojuist functionaliteit aan uw eerste pod toegevoegd, een subklasse aan UILabel. De subklasse biedt een methode om het label te laten knipperen en een andere methode om te voorkomen dat het gaat knipperen.

Om ervoor te zorgen dat andere ontwikkelaars gemakkelijk kunnen begrijpen hoe te gebruiken BlinkingLabel, voeg een voorbeeldcode toe aan het voorbeeldproject. Open BlinkingLabel / Voorbeeld voor BlinkingLabel /ViewController.swift en laat het er zo uitzien:

import UIKit import BlinkingLabel class ViewController: UIViewController var isBlinking = false let blinkingLabel = BlinkingLabel (frame: CGRectMaken (10, 20, 200, 30)) override func viewDidLoad () super.viewDidLoad () // Stel de BlinkingLabel in blinkingLabel.text = "Ik knipper!" blinkingLabel.font = UIFont.systemFontOfSize (20) view.addSubview (knipperendLabel) knipperendLabel.startBlinking () isBlinking = true // Maak een UIButton om het knipperende knopje toggleButton = UIButton te schakelen (frame: CGRectMaken (10, 60, 125, 30) ) toggleButton.setTitle ("Knipperen", voorState: .Normaal) toggleButton.setTitleColor (UIColor.redColor (), forState: .Normal) toggleButton.addTarget (self, action: "toggleBlinking", forControlEvents: .TouchUpInside) view.addSubview (toggleButton) func toggleBlinking () if (isBlinking) blinkingLabel.stopBlinking () else blinkingLabel.startBlinking () isBlinking =! isBlinking

Op dit punt zie je Xcode klagen met veel fouten in ViewController.swift. Dit komt omdat de pod voor BlinkingLabel is nog niet geïnstalleerd in het voorbeeldproject. Om dat te doen, schakelt u over naar de opdrachtregel en vanuit de hoofdmap van de BlinkingLabel map voer de volgende opdracht uit:

> cd Voorbeeld> podinstallatie Verbindingen analyseren Podspec voor 'BlinkingLabel' ophalen van '... /' Verbindingsafspraken downloaden BlinkingLabel installeren 0.1.0 (was 0.1.0) Project Pods genereren Clientproject integreren

Schakel vervolgens terug naar Xcode en selecteer de BlinkingLabel-Voorbeeld doel en klik op de Rennen knop.

Je zou zoiets als dit moeten zien:

Tik Knipperen schakelen om je nieuwe pod uit te proberen. De laatste stap bij het maken van je pod is het bijwerken van README.md. Open in Xcode README.md onder BlinkingLabel / Podspec-metadata / README.md. Je zult zien dat CocoaPods wat standaarddocumentatie voor je heeft toegevoegd. Stop daar niet, je kunt het beter maken. Voeg wat documentatie over de pod toe en voeg een screenshot toe. Vergeet niet dat een README vaak het eerste is dat iemand te zien krijgt als hij naar je pod kijkt. Het is belangrijk dat het van hoge kwaliteit is. Bekijk de mijne voor wat inspiratie.

7. Uw pod beschikbaar maken

Nu dat u een volledig functionele pod op uw lokale computer draait, is het tijd om te maken BlinkingLabel beschikbaar voor anderen voor opname in hun projecten. Op een hoog niveau wordt dit bereikt door uw nieuwe pod in de openbare Specs-repository te plaatsen.

De bril repository is de openbare plaats op GitHub waar alle openbare pods zijn geïndexeerd. Je bent eigenlijk niet gedwongen om GitHub te gebruiken om de broncode van je pod te hosten. U kunt bijvoorbeeld ook BitBucket gebruiken. De specificaties van je pod worden echter opgeslagen in de Specs-repository op GitHub.

Het is heel eenvoudig om uw pod aan de specs-repository toe te voegen. Er zijn drie stappen nodig voor het indienen van uw pod. Probeer deze stappen niet, want ik heb BlinkingLabel al openbaar gemaakt. Ze zijn alleen hier om als referentie te dienen.

Zorg er als voorwaarde voor dat uw lokale wijzigingen in de BlinkingLabel project directory worden toegevoegd aan git en naar de remote geduwd.

Stap 1: taggen

Tag je meest recente commit en druk deze op de afstandsbediening.

> git tag 0.1.0> git push oorsprong 0.1.0 Totaal 0 (delta 0), hergebruikt 0 (delta 0) Naar https://github.com/obuseme/BlinkingLabel.git * [nieuwe tag] 0.1.0 -> 0.1.0

Deze stap geeft aan dat u deze commit markeert als een specifieke release van uw pod. De naam van het label moet overeenkomen s.version in uw .podspec het dossier. De volgende stap zal dit valideren.

Stap 2: Validatie

Voer vervolgens de volgende opdracht uit vanaf de opdrachtregel om te controleren of alles correct is geconfigureerd tussen waar uw broncode is opgeslagen en uw .podspec het dossier:

 pod spec lint BlinkingLabel.podspec

Dit zou het volgende moeten uitvoeren:

> pod spec lint BlinkingLabel.podspec -> BlinkingLabel (0.1.0) Analyseerde 1 podspec. BlinkingLabel.podspec is geslaagd voor validatie.

Stap 3: Push to Specs Repository

Druk ten slotte de specificatie naar de bril repository door het volgende commando uit te voeren:

pod trunk push BlinkingLabel.podspec

Dit zou het volgende moeten uitvoeren:

> pod trunk push BlinkingLabel.podspec Update spec repo 'master' Podspec controleren -> BlinkingLabel (0.1.0) Actualisatie van de repository 'master' - Gegevens-URL: https://raw.githubusercontent.com/CocoaPods/Specs/f7fb546c4b0f80cab93513fc228b274be6459ad2/Specs /BlinkingLabel/0.1.0/BlinkingLabel.podspec.json - Logberichten: - 29 juni, 20:40: push voor 'BlinkingLabel 0.1.0' geïnitieerd. - 29 juni, 20:40: Push for 'BlinkingLabel 0.1.0' is gepusht (1.701885099 s).

8. Wat maakt een geweldige pod?

Er zijn letterlijk duizenden pods beschikbaar in de bril repository. Wanneer u naar een pod bladert, is het niet eenvoudig om de kwaliteit van een pod te bepalen. Wanneer u code van derden invoert in uw project, wilt u een hoog niveau van vertrouwen hebben in de code die u verzendt naar klanten. Historisch gezien moest een ontwikkelaar zijn eigen interpretatie maken van de kwaliteit van een willekeurige pod die hij vond.

Vanaf juni 2015 heeft CocoaPods een tool, de kwaliteitsindex, geleverd die een beknopt oordeel geeft over de kwaliteit van een bepaalde pod op basis van bepaalde statistieken. De uitgebreide en meest actuele statistieken zijn te vinden op GitHub.

Samengevat, hier zijn dingen die kunnen helpen het verbeteren van de Kwaliteitsindex van je pod:

• projectpopulariteit zoals gemeten door sterren, vorken, abonnees en bijdragers
• codedocumentatie
• README van hoge kwaliteit
• geschreven in Swift
• gebruik van de GPL-licentie
• niet veel openstaande problemen
• codekwaliteit verzekerd door geautomatiseerde tests
• lean installatiegrootte door de inbegrepen activa te minimaliseren
• kleinere, goed samengestelde, lessen

De Kwaliteitsindex van een pod kan zowel omhoog als omlaag gaan, afhankelijk van hoe goed een bepaald project voldoet aan deze statistieken.

Conclusie

Het maken van pods voor anderen is leuk en een goede manier om een ​​bijdrage te leveren aan de community. Deze zelfstudie heeft je laten zien welke stukjes code goede pods opleveren, hoe je je eerste pod kunt maken, hoe je hem openbaar moet maken en welke technieken een geweldige pod kunnen maken..

Je hebt nu de kennis om je eerste pod te maken. Ik zou graag horen welke pods je in gedachten hebt om te bouwen. Kom alsjeblieft terug en zet een link naar je pod zodra deze is gemaakt.