Hvordan tolke iOS-referansedokumentasjon for bedre appdesign

Den tøffeste delen for meg da jeg begynte å programmere apper var å lese Apple-dokumentasjonen på iOS eller MacOS. Da jeg kom inn på flere API-er, ble ting enda mer komplisert. Du må forstå hvordan du kan lese API eller proprietære kodedokumenter for å forstå hvordan du oppretter et stykke kode, koble til webtjenester eller feilsøke endringer i kode.

For eksempel vil du veldig ofte se begrepet DEPRECATED, som betyr at et bestemt metodenavn ikke lenger brukes. Dette er veldig viktig, så la oss ta en titt på Apple Docs først. ( Figur A )

Figur A

TableViewController Class

Hver klasse har et referansedokument, som forteller en utvikler hva klassens metoder og egenskaper er. I dette tilfellet forteller ovennevnte oss at objektet for UITableViewController (UITVC):

  • Er en underklasse av UIViewController
  • Vedtar tabellvisningen Delegat- og DataSource-protokoller
  • Krever UIKit-rammeverket
  • Har noen ekstra referansedokumenter og prøver

Legg merke til på venstre sidelinje, det er en liste over oppgaver, egenskaper og forekomstmetoder. Dette forteller oss litt mer om hva et UITVC-objekt kan gjøre. Vi ser for eksempel at den har en initWithStyle-metode, som er en (-) forekomstmetode. Andre objekter som NSArray kan ha både (-) Forekomstmetoder og (+) Klassemetoder, men de er alle oppført her.

La oss analysere den viktigste forekomstmetoden, initWithStyle. ( Figur B )

Figur B

UITVC initWithStyle-metoden

Som vi nevnte ovenfor, vil du noen ganger støte på den beryktede DEPRECATED advarselen. Dette betyr at denne metoden er falt ut av bruk og vanligvis erstattet av en bedre metode. Hvis en metode er utdatert, vil den vanligvis ha en rød etikett ved siden av den som angir hvilken versjon av iOS den ble utskrevet i.

  • I dette tilfellet er denne metoden IKKE avskrevet. Så la oss ta en gander:
  • Vi får en kort beskrivelse av hva den gjør.
  • Så gir den oss metodesignaturen, det vil si hvilken kode vi bruker for å implementere den.
  • I dette tilfellet tar det også en parameter som heter stil. Det gir oss de to alternativene for den parameteren.
  • Vi blir også fortalt at det returnerer et UITVC-objekt eller null som er nyttig. Dette er viktig fordi hvis du bruker denne metoden for å tilordne resultatet til et annet objekt, bør du være sikker på hva slags resultat metoden returnerer.
  • Til slutt forteller den deg hvor du kan finne eksempelkode.
La oss se på et mer komplekst objekt, for eksempel NSMutableArray. ( Figur C )

Figur C

NSMutableArray Class Reference.

Det er ganske mange forskjeller.

Først av, legg merke til at dette kommer fra Mac Developer Library i stedet for iOS Developer Library som indikert av ikonet og etiketten øverst til venstre. Det er fordi dette objektet også finnes i Mac OS. Mens UITVC er et iOS-objekt.

For det andre kan du se at en av metodene er utdatert i OSX v.10.6.

Til slutt, legg merke til at dette objektet har både forekomst- og klassemetoder. Så la oss utforske en; et objekts mest grunnleggende metode, init. ( Figur D )

Figur D

Dette betyr at hvis du kaller vår standard måte å opprette et objekt på:

 Object Class * objectPointer = Object Class alloc 

Og så setter vi inn metodesignaturen

 - (id) initWithCapacity: (NSUInteger) numItems 

Så vi får dette:

 Object Class * objectPointer = Object Class alloc initWithCapacity: (NSUInteger) numItems; 

La oss se på riktig formatert kode:

 NSMutableArray * myArray = NSMutableArray alloc initWithCapacity: 10; 

Legg merke til at vi tok ut - (id) i begynnelsen av metodesignaturen fordi vi vil at den skal returnere et NSMutableArray-objekt. Og grunnen til at vi kan legge til denne metodesignaturen til NSMutableArray * myArray-opprettingslinjen, er fordi vi vet at NSMutableArray inneholder metodesignaturen i Class-filen. Til slutt ga vi inn verdien for parameteren og initialiserte oppstillingen vår med 10 spor.

Hopp til definisjon

Noen ganger vet vi ikke så mye om en klasse vi bruker i et prosjekt. Kanskje vi vil vite hvilke metoder vi kan kalle på et objekt. Det er her Jump To Definition i Xcode kommer inn. Hvis klassen du har importert til prosjektet ditt ikke har så fine referansedokumenter som Apple, kan du plassere markøren over metoden eller objektet og velge Jump to Definition. Dette tar deg til baseklassen der objektet eller metoden er definert.

La oss gjøre det for et eksempel jeg bare kom over. Jeg hadde jobbet med et spill ved å bruke Cocos2d. Cocos2d er et eksternt bibliotek eller rammeverk fra tredjepart. Disse begrepene er vanligvis utskiftbare, men de "betyr" det samme. Det er i utgangspunktet det du får når noen eller et selskap jobber med en haug med kode som hjelper deg med å utføre visse oppgaver.

For eksempel jobbet Cocos2d-skaperne på mange klasser for å lage Cocos2d. En slik klasse er CCAnimation, som tar inn forskjellige rammer og strenger dem sammen for å lage en animasjon. De har nylig gitt ut v.2.0, og denne klassen endret noen av metodesignaturene sine for å inkludere forbedringer antar jeg.

Hvis jeg åpner koden min i Xcode og prøver å kjøre min gamle kode ved å bruke v2.0 av Cocos2d, krasjer den og sier "Ukjent selektor sendt til instans". ( Figur E )

Figur E

CCAnimation Feil i Cocos2d v2.0
Dette betyr at forekomsten av CCAnimation ikke kjenner igjen den gamle metoden eller velgeren. Antagelig fordi de endret det gamle navnet for å imøtekomme nye strukturelle endringer. Så høyreklikk jeg over CCAnimation-anropet i koden min der appen krasjet. ( Figur F )

Figur F

Gå til Definisjon i XCode
Og når jeg hopper til definisjon, blir jeg tatt med til filen Class Implementation. ( Figur G )

Figur G

GG
CCAnimation Class File

Dette gir meg klassehenvisning for CCAnimation, den som blir brukt i prosjektet mitt, og forteller meg hvilke metoder klassen nå implementerer. Nå finner jeg bare metoden som passer bedre til mine behov.

Det er viktig å lære hvordan du går fra et krasj til dokumentasjonen som kan hjelpe deg med å fikse det krasjet. Du trenger i utgangspunktet å forstå hva årsaken til krasjet var (som vises i konsollen) og bruke logikk og erfaring for å sortere gjennom referansedokumentasjonen for å erstatte den gamle eller defekte koden med den riktige.

Designstrategi

Det er viktig å holde koden ren og ordnet. Dette er vanskelig å gjøre hvis du begynner å kode uten designdesign i tankene, og selv da kan det bli rotete. Du får det som kalles spaghettikode. Så her er et veldig raskt og enkelt tips.

Jeg starter normalt med å lage en papir- og penneskisse av oppsettet. Hvis du har lest noen tidligere innlegg eller sett på kurset mitt på Learnable.com, vil du ha sett at jeg starter appene mine med et håndtegnet oppsett. Jeg bruker ikke digitale verktøy for det fordi du ikke kan slå fleksibiliteten til skisse-sletting av en god gammeldags skrapeplate.

Uansett, her er tipset: Når jeg først har oppsettet og kjenner navnene på klassene mine, bruker jeg kommentarer til å plassere ideer. Med andre ord åpner jeg den første visningskontrolleren (iOS-appen) eller hovedhandlingslaget (spillet), og jeg begynner å legge inn kodelinjer som dette:

 // Call Opprett en fiende 

// Call Method for å få fienden til å bevege seg

// Ring Min Hovedspiller

// IF time = z og deretter Call Create Powerup

Ved å bruke kommentarer for å begynne å kode, kan du gå gjennom ideene i hodet ditt (som flyter rikelig) ned på 'papir' før det forlater hodet. Senere kan du gå tilbake til disse kommentarene og analysere dem for å finne ut hva du skal kalle metoden og hvilke parametere som skal inkluderes.

Legg merke til at jeg for eksempel ikke sa: HVIS tid ... skaper helse-power-up . Jeg sa Call call power-up fordi jeg på denne måten kan outsource disse tingene til generiske fabrikkmetoder.

Vi kan anta at hvert stykke kode blir stadig mer komplisert. Når det gjelder et spill, kan power-ups starte med bare ett slag (en helsepakke), men etter hvert kan du ha helsepakker med rødt, blått og gull eller forskjellige våpen i kraftklasse. Dette betyr at du vil lage veldig generiske metoder som createPowerups i stedet for createHealthPacks. Dette er mest fordi visse objekter vil dele mange vanlige oppgaver.

Videre, hvis du har organisert klassene dine riktig, vil du for eksempel kunne gi et Class Object-navn til en generisk metode og få det til å opprette det objektet for deg på et gitt tidspunkt og sted.

Tenk på følgende scenario. Du har forskjellige kraftvåpen i spillet eller appen din. Til å begynne med sier du bare noe som:

 - (id) createRaygun; 

Men når prosjektet ditt vokser og pistolene dine blir mer komplekse, vil du ende opp med dusinvis av forskjellige kanonmetoder. Det ville være praktisk å ha en mer generisk metode med flere parametere som:

 - (id) createGunWithImage: (UIImage *) bilde av Color: (NSString *) farge withPower: (NSNumber) power; 

På denne måten kan du kalle metoden for å lage pistolen og passere den noen få parametere og få en annen pistol hver gang, noe som er mye renere enn å ha mange forskjellige pistolmetoder.

Disse tingene kan virke veldig opplagte, men når du kommer til å kode et spill, eller app, er ideen din frisk i hodet, og du vil ikke at Strategic Planning skal bremse deg. Ellers ender du opp med spaghettikode. Det du ønsker er å få ideene dine "på papir" først. Så bekymre deg for å få disse ideene til å skje.

Planlegger i forkant av koding

Årsaken er at du blir opptatt av å finne ut HVORDAN Call Make-spiller flytter. De fleste av de gangene du ikke vet hvordan du gjør noe med flaggermus eller blir fanget i noe dumt som å erklære ivars versus egenskaper, eller du kan ikke huske det nøyaktige navnet på metodesignaturen du hadde i tankene om å gjøre noe . Når du får det til, har du mistet oversikten over hva du gjorde.

Så dette er hva jeg gjør; Jeg tar alle ideene mine og kommenterer dem i init-metoden. Så begynner jeg å lage de respektive tomme metodene for å utføre hver og en av disse ideene. For eksempel:

 - (void) createMainCharacter { 
 // Hent bilde (fra atlas eller fil og fra egen underklasse) 
 // AddChild til lag (eller batchnode) 
 // Plasser og ring karakterens initialiseringsmetoder 
 } 

På denne måten kan jeg se hva som må gjøres i laget mitt, og hva jeg kan gjøre på en annen metode eller underklasse. I dette tilfellet kan jeg ende opp med å kalle karakteren min fra sin egen underklasse i stedet for bare å si CCSprite * myCharacter. Dette hjelper meg også med å utelate detaljer som hører hjemme i den underklassen, slik at jeg ikke roter opp init-metoden eller lagklassen min med objektspesifikk kode.

Med andre ord skrev jeg at jeg trengte å plassere objektet mitt og kalle spillerens initialiseringsmetoder. Dette betyr at metodene for å gjøre initialiseringsmateriell for det objektet må ligge utenfor laget mitt, ergo, objektklasse-metodene.

Jeg tror dette er en god taktikk for å lage spill og apper, fordi, tro det eller ei, de vil bli mer komplekse, selv om du ikke har tenkt dem. Det vil gjøre koden din uleselig i fremtiden og med API-endringer eller nye ideer vil koden din være mye enklere å endre.

Legg merke til denne artikkelen fordi jeg vedder på deg noen måneder nede på veien, spesielt hvis du kommer i gang, vil du finne deg selv å drukne i spaghettikode. Du vil være glad for at du gjorde det!

Les også:

  • Fordelene ved å bruke designmønstre i iOS-utvikling
  • Utvikle iOS-appene dine, ellers vil de dø i naturen
  • Tips for å være en vellykket iOS-utvikler

© Copyright 2020 | mobilegn.com