Opprette din første kakao

Introduksjon

CocoaPods er et flott verktøy for å hjelpe med avhengighetsadministrasjon når du bygger iOS- eller OS X-applikasjoner. Etter å ha vært rundt og godt støttet i årevis, er CocoaPods modenhet tydelig. Selv om det er veldig vanlig å bruke CocoaPods i IOS- eller OS X-programvareprosjektene, er det mindre vanlig å faktisk lage en pod andre å bruke. Denne opplæringen vil gå deg gjennom å lage din første pod, og den vil gi deg noen tips om hva som kjennetegner en flott pod.

1. Installer KakaoPoder

Åpenbart, for å lage en pod, må du installere CocoaPods. Den er tilgjengelig som en Ruby perle fra RubyGems. For å installere CocoaPods, utfør følgende kommandoer fra kommandolinjen:

perle installasjon cocoapods

Denne opplæringen ble skrevet mot CocoaPods 0.37.2.

2. Steg for trinn Oversikt

Fra et høyt nivå er det fem trinn involvert for å lage din første pod:

1. Bestem ideen til din første pod.
2. Bruke pod lib kommandoen for å lage skjelett katalog struktur og tilhørende filer for pod.
3. Oppdater metadataene til podden din, for eksempel lisens og versjoninformasjon.
4. Legg til koden for din pod. Dette inkluderer både koden for pod selv og hvilken som helst kode som ville være nødvendig for et eksempel prosjekt.
5. Gjør poden tilgjengelig for alle.

3. Podstorming

Podstorming er egentlig ikke et ord, men det er på tide å brainstorm funksjonaliteten til den første podden din. Det er over 10 000 offentlig tilgjengelige pods indeksert i det offisielle spesifikasjonsregisteret. Folk har funnet alle slags ting å gjøre tilgjengelig som en pod. Her er noen forslag for å hjelpe deg med å starte podstorming, feil, jeg mener brainstorming:

• Verktøyskode: Har du en unik oppgave å utføre visse strengmanipulasjoner? Har du en favorittunderklasse som du skrev for å utføre en slank animasjon på en UIView? Spesifikk brukskode som dette er et godt eksempel på hva som kan omdannes til en pod. Det er ofte allerede godt fakturert og koblet fra andre eksisterende kodebaser.
• Tredjeparts pakker: Har du opprettet en wrapper rundt en annen tredjeparts API? Har du en app som du ønsker å gi kroker for andre apper å integrere med, for eksempel for godkjenning? Gir din bedrift en web-API for web-baserte ressurser som vil være nyttig for andre iOS-apper som enkelt kan integreres med? Hvis det er tilfelle, så gir en pod mening fordi det er en enkel måte for andre iOS-programmer å enkelt integrere med disse pakkene.
• UI-komponenter: Har du opprettet en buttery-smooth UI-widget som du vil at andre applikasjoner skal kunne bruke? Dette er mine favorittputer. Det er flott å kunne legge til en komplisert og herlig brukergrensesnitt til et program ved å bare inkludere en podavhengighet.
• Alt du vil at andre skal kunne bruke. Har du laget noe som du tror andre ville finne nyttige? Hvis det er tilfelle, slå det til en pod slik at andre enkelt kan bruke den.

Denne opplæringen vil gå deg gjennom å lage en pod som lar deg lage en UILabel det blinker. Vi ringer det BlinkingLabel.

4. Opprett prosjektet

Tid til å grave inn. Nå som du vet hvilken funksjonalitet poden din skal gi, er det på tide å lage den. De pod lib kommandoen er et viktig verktøy som vi skal bruke til to formål under etableringsprosessen.

1. pod lib lint vil validere at alt er bra med poden din og at den er klar til bruk av CocoaPods.
2. pod lib lage vil faktisk bidra til å gi deg et hopp ved å gi en standard katalogstruktur med en haug med boilerplate-filer som er nødvendige for en høy kvalitet pod. pod lib lage er ikke den eneste måten å lage pod på, men det er det enkleste.

Åpne et terminalvindu, naviger til en arbeidskatalog og utfør følgende kommando:

pod lib lage BlinkingLabel

• Når du blir spurt hvilket språk du vil bruke, svar Fort.
• Når du blir spurt om du vil inkludere et demo-program, svarer du Ja.
• Når du bestemmer deg for å lage et prøveprosjekt eller ikke, foreslår CocoaPods-teamet å spørre deg selv: "Skal denne Pod-skjermen ta med et skjermbilde?" I så fall er det en god idé å inkludere et prøveprosjekt.
• Når du blir spurt hvilken testramme du skal bruke, svar Ingen.
• Svar Nei til spørringen om visningsbasert testing.

Testing er utenfor omfanget av denne opplæringen, men ikke la den stoppe deg fra å undersøke dette videre etter denne opplæringen. Forholdet mellom tester og kodelinjer er en faktor som vurderes av CocoaPods kvalitetsindeks.

Når stillaset for din pod er satt opp, vil Xcode åpne ditt splitter nye prosjekt klar for at du skal jobbe på din pod.

5. Oppdaterer Podens Metadata

Det er tre hoveddeler av metadata som må inkluderes med din pod:

• .podspec: Denne filen beskriver informasjon om denne spesifikke versjonen av podden din. Din pods, versjonsnummer, hjemmeside og forfatternavn er noen eksempler på hva som er inkludert. Sjekk den offisielle referansesiden for mer informasjon.
• README: Hvis du har brukt GitHub før, vet du hvor viktig et README er. Et prosjektets README, skrevet i Markdown, vises på hjemmesiden til et prosjekt på GitHub. Et riktig README kan være forskjellen mellom noen som bruker prosjektet eller ikke. I tillegg er det en faktor som bidrar til en høy KakaoPods Kvalitetsindeks også.
  
• TILLATELSE: For å få din pod godkjent i Spec-depotet, må poden din inkludere en lisens. De pod lib lage kommandoen fyller automatisk LISENS-filen med MIT-lisensen, og det er det vi skal bruke til denne opplæringen.
  

Å få tak i .podspec i form, åpne den i Xcode. Du finner det under BlinkingLabel / Podspec Metadata / BlinkingLabel.podspec. Heldigvis har CocoaPods skapt en velbefolket mal for oss da vi kjørte ut pod lib lagekommando. Du er i ferd med å elske det verktøyet enda mer. De pod lib lint kommandoen vil automatisk validere .podspec fil for å sikre at den overholder beste praksis. Eller, hvis du er lat, kan du også bruke den til å finne ut det minste minimumet du trenger å gjøre for å skape et riktig .podspec fil.

Fra kommandolinjen, i roten til BlinkingLabel-prosjektet, utfør følgende kommando:

pod lib lint BlinkingLabel.podspec

Dette skal utføre følgende:

> pod lib lint BlinkingLabel.podspec -> BlinkingLabel (0.1.0) - WARN | Sammendraget er ikke meningsfylt. - WARN | Beskrivelsen er ikke meningsfylt. - WARN | Det oppsto et problem med å validere nettadressen https://github.com// BlinkingLabel. [!] BlinkingLabel passerte ikke validering. Du kan bruke '-no-clean'-alternativet for å kontrollere eventuelle problemer.

Verktøyet forteller deg at det er tre ting som må løses i .podspec fil:

• legg til mer informasjon i sammendraget
• legg til en skikkelig beskrivelse
• spesifiser en URL for podens hjemmeside

Her er noen anbefalte verdier for disse feltene:

• s.summary: En underklasse på UILabel som gir en blink.
• s.description: Dette CocoaPod gir muligheten til å bruke en UILabel Det kan bli startet og slutte å blinke.
• s.homepage: https://github.com/obuseme/BlinkingLabel (bytt obuseme med ditt GitHub brukernavn)

Men vent, hvis du har fulgt instruksjonene trinn for trinn, er det teknisk ikke et prosjekt på denne nettadressen ennå. Det er på tide å presse prosjektet ditt til et offentlig lager på GitHub. Mens det finnes andre alternativer for hosting av podene, er GitHub langt den vanligste.

For å skyve prosjektet ditt til GitHub, bla til GitHub, logg inn eller opprett en konto, og opprett en Ny Repository kalt BlinkingLabel. Deretter utfør kommandolinjene fra kommandolinjen:

git add. git commit -m "Initial Commit" git ekstern legg til opprinnelse https://github.com//BlinkingLabel.git // erstatte  med ditt github.com brukernavn git push -u origin master

På dette punktet, hvis du har gjort alt riktig og lint på .podspec filen igjen, bør den bestå validering.

> pod lib lint BlinkingLabel.podspec -> BlinkingLabel (0.1.0) BlinkingLabel bestått validering.

6. Legge til kode

Du har nå det grunnleggende skallet på en pod, men det gjør ingenting. Det er på tide å legge til noe funksjonalitet. Den kjekke tingen om prøveprosjektet som CocoaPods laget for deg, er at du samtidig kan skrive kode for både pod og eksempelprosjektet.

Finn først filen ReplaceMe.swift under Pods / Development Pods / BlinkingLabel / Pod / Classes / og slett den.

Deretter oppretter du en ny Swift-fil i samme katalog og heter den BlinkingLabel.swift. Erstatt innholdet i den nye filen med følgende:

offentlig klasse BlinkingLabel: UILabel public func startBlinking () la alternativene: UIViewAnimationOptions = .Repeat | .Autoreverse UIView.animateWithDuration (0.25, delay: 0.0, alternativer: alternativer, animasjoner: self.alpha = 0, fullføring: null) offentlig func stopBlinking () alpha = 1 layer.removeAllAnimations ()

Du har nettopp lagt til funksjonalitet til din første pod, en underklasse på UILabel. Underklassen gir en metode for å få etiketten til å blinke og en annen metode for å stoppe den fra å blinke.

For å sikre at det er enkelt for andre utviklere å forstå hvordan de skal brukes BlinkingLabel, legg til noen prøvekode til eksempelprosjektet. Åpen BlinkendeLabel / Eksempel på BlinkendeLabel /ViewController.swift og få det til å se slik ut:

importere UIKit-import BlinkingLabel klasse ViewController: UIViewController var isBlinking = false let blinkingLabel = BlinkingLabel (ramme: CGRectMake (10, 20, 200, 30)) tilsidesatte func viewDidLoad () super.viewDidLoad () // Oppsett BlinkingLabel blinkingLabel.text = "Jeg blinker!" blinkingLabel.font = UIFont.systemFontOfSize (20) view.addSubview (blinkingLabel) blinkingLabel.startBlinking () isBlinking = true // Opprett en UIButton for å bytte ut den blinkende la toggleButton = UIButton (ramme: CGRectMake (10, 60, 125, 30) ) toggleButton.setTitle ("Toggle Blinking", forState: .Normal) toggleButton.setTitleColor (UIColor.redColor (), forState: .Normal) toggleButton.addTarget (selv, handling: "toggleBlinking", forControlEvents: .TouchUpInside) view.addSubview (toggleButton) func toggleBlinking () hvis (erBlinking) blinkingLabel.stopBlinking () else blinkingLabel.startBlinking () isBlinking =! isBlinking

På dette punktet vil du se Xcode klage med mange feil i ViewController.swift. Dette er fordi pod for BlinkingLabel er ikke installert på eksempelprosjektet ennå. For å gjøre det, bytt til kommandolinjen og fra roten til BlinkingLabel katalog utføre følgende kommando:

> cd Eksempel> pod installere Analysere avhengigheter Hente podspec for 'BlinkingLabel' fra '... /' Last ned avhengigheter Installere BlinkingLabel 0.1.0 (var 0.1.0) Generere Pods prosjekt Integrere klient prosjekt

Deretter skifter du tilbake til Xcode og velger BlinkingLabel-Eksempel mål og klikk på Løpe knapp.

Du bør se noe slikt:

Tap Bytt blinkende å prøve ut din nye pod. Det siste skrittet i å lage din pod er å oppdatere README.md. I Xcode, åpne README.md under BlinkingLabel / Podspec Metadata / README.md. Du ser at CocoaPods har lagt til standard dokumentasjon for deg. Ikke hold deg der, du kan gjøre det bedre. Legg til litt dokumentasjon om podden og ta med et skjermbilde. Husk at et README er ofte det første som noen vil se når du ser på podmen din. Det er viktig at det er av høy kvalitet. Ta en titt på meg for litt inspirasjon.

7. Gjør din pod tilgjengelig

Nå som du har en fullt funksjonell pod som kjører på din lokale maskin, er det på tide å lage BlinkingLabel tilgjengelig for andre for inkludering i sine prosjekter. På høyt nivå er dette oppnådd ved å få din nye pod inn i det offentlige Specs-depotet.

De Specs depot er det offentlige stedet på GitHub hvor alle offentlige pods er indeksert. Du er faktisk ikke tvunget til å bruke GitHub til å være vert for podens kildekode. Du kan også bruke BitBucket for eksempel. Din pods spesifikasjon vil bli lagret i Specs-depotet på GitHub skjønt.

Det er veldig enkelt å ha din pod lagt til Specs-depotet. Det er tre trinn involvert for å sende inn podgen din. Ikke prøv disse trinnene, siden jeg allerede har gjort BlinkingLabel offentlig. De er bare her for å tjene som referanse.

Som en forutsetning må du sørge for at de lokale endringene dine endres BlinkingLabel prosjektkatalog legges til git og trykkes til fjernkontrollen.

Trinn 1: Merking

Merk ditt siste forpliktelse og trykk det til fjernkontrollen.

> git tag 0.1.0> git push opprinnelse 0.1.0 Totalt 0 (delta 0), gjenbruk 0 (delta 0) Til https://github.com/obuseme/BlinkingLabel.git * [ny tag] 0.1.0 -> 0.1.0

Dette trinnet indikerer at du merker denne plikten som en bestemt utgave av podmen din. Navnet på taggen skal samsvare s.version i din .podspec fil. Det neste trinnet vil validere dette.

Trinn 2: Validering

Kjør deretter kommandoen fra kommandolinjen for å bekrefte at alt er konfigurert riktig mellom hvor kildekoden er lagret og din .podspec fil:

 pod spec lint BlinkingLabel.podspec

Dette skal utføre følgende:

> pod spec lint BlinkingLabel.podspec -> BlinkingLabel (0.1.0) Analysert 1 podspec. BlinkingLabel.podspec bestått validering.

Trinn 3: Skubbe til Specs Repository

Til slutt skyver du specen til Specs depot ved å utføre følgende kommando:

pod trunk trykk BlinkingLabel.podspec

Dette skal utføre følgende:

> pod trunk push BlinkingLabel.podspec Oppdatere spec repo 'master' Validerende podspec -> BlinkingLabel (0.1.0) Oppdatering spec repo 'master' - Data URL: https://raw.githubusercontent.com/CocoaPods/Specs/f7fb546c4b0f80cab93513fc228b274be6459ad2/Specs /BlinkingLabel/0.1.0/BlinkingLabel.podspec.json - Logmeldinger: - 29. juni, 20:40: Trykk for 'BlinkingLabel 0.1.0' initiert. - 29. juni, 20:40: Trykk for 'BlinkingLabel 0.1.0' har blitt presset (1.701885099 s).

8. Hva gjør en stor pod?

Det er bokstavelig talt tusenvis av pods tilgjengelig i Specs oppbevaringssted. Når du surfer på en pod, er det ikke lett å bestemme en pods kvalitet. Når du innfører tredjepartskode i prosjektet ditt, vil du ha høy grad av tillit til koden du vil sende til kunder. Historisk måtte en utvikler lage sin egen tolkning av kvaliteten på en tilfeldig pod som de fant.

Fra juni 2015 har CocoaPods gitt et verktøy kalt kvalitetsindeksen som gir en oppsummert vurdering av kvaliteten på en gitt pod basert på visse beregninger. Den omfattende og mest oppdaterte beregningen finner du på GitHub.

Oppsummert, her er ting som kan bidra til å forbedre Kvalitetsindeks av din pod:

• prosjekt popularitet som målt av stjerner, gafler, abonnenter og bidragsytere
• kode dokumentasjon
• høy kvalitet README
• skrevet i Swift
• bruk av GPL lisensen
• ikke mange åpne problemer
• Kvalitetssikring sikret gjennom automatiserte tester
• lenk installasjonsstørrelse ved å minimere inkluderte eiendeler
• mindre, godt sammensatte, klasser

De Kvalitetsindeks av en pod kan enten gå opp eller ned basert på hvor godt et gitt prosjekt samsvarer med disse beregningene.

Konklusjon

Å lage pods for andre å bruke er morsomt og en god måte å bidra tilbake til samfunnet. Denne opplæringen har vist deg hvilke stykker kode som gir gode pods, hvordan du lager din første pod, hvordan du gjør den offentlig tilgjengelig, og hvilke teknikker kan gjøre for en flott pod.

Du har nå kunnskapen om å lage din første pod. Jeg vil gjerne høre hvilke pods du har i tankene å bygge. Vennligst kom tilbake og slipp en kobling til poden din når den er opprettet.