Share
UIKit er det rammeverket du finner mest brukte når du utvikler iOS-applikasjoner. Det definerer kjernekomponentene i et iOS-program, fra etiketter og knapper til tabellvisninger og navigasjonsstyrere. I denne artikkelen vil vi ikke bare starte utforskningen av UIKit-rammen, vi vil også undersøke internalsiden til et iOS-prosjekt og de grunnleggende byggeblokkene i IOS-applikasjoner.
Mens rammeverket definerer klasser, protokoller og funksjoner for både iOS og OS X, er UIKit-rammen utelukkende rettet mot iOS-utvikling. Det er ekvivalent av Søkesett eller AppKit ramme for OS X utvikling.
Som Foundation definerer UIKit klasser, protokoller, funksjoner, datatyper og konstanter. Det legger også til tilleggsfunksjonalitet til ulike grunnklasser, for eksempel NSObject, NSString, og NSValue gjennom bruk av mål-C-kategorier.
Mål-C-kategorier er en praktisk måte å legge til ekstra metoder for eksisterende klasser uten behov for underklasse. Les denne opplæringen av Aaron Crabtree hvis du vil lære mer om Objective-C-kategorier.
I stedet for å utforske nøkkelklassene til UIKit som vi gjorde for stiftelsens rammeverk, vil vi skape og reise gjennom et nytt iOS-prosjekt og utforske klassene vi møter. Ved å ta denne tilnærmingen blir det raskt klart i hvilken sammenheng en klasse brukes og hvordan hver klasse passer i den bredere ordningen til et iOS-program og hvilken rolle det spiller.
Start Xcode og opprett et nytt prosjekt ved å velge Nytt> Prosjekt ... fra Fil Meny. I iOS-delen til venstre velger du applikasjon kategori. Fra listen over prosjektmaler velger du Enkeltvisningsprogram mal.
Enkeltvisningsprogrammalen inneholder de grunnleggende byggeblokkene i et iOS-program, og er derfor et godt sted å starte reisen vår.
Gi navnet navnet på prosjektet UIKit og skriv inn et organisasjonsnavn og bedriftsidentifikator. Skriv inn et klasse prefiks, som jeg forklarte tidligere i denne serien, og sett enheter til iPhone.
Fortell Xcode hvor du vil lagre det nye prosjektet, og sørg for å sette prosjektet under versjonskontroll ved å merke av i boksen merket Opprett git-depot på Min Mac. Gå gjennom denne artikkelen for mer informasjon om versjonskontroll og fordelene.
Vi har lært ganske mange nye ting siden sist vi opprettet et iOS-prosjekt fra begynnelsen, så det er en god ide å utforske de forskjellige filene og mappene til vårt nye prosjekt for å se om de ringer en klokke.
I Prosjektnavigator, du bør se tre mapper på roten av prosjektet;
La oss se på innholdet i hver av disse mappene.
De Produkter mappen inneholder for øyeblikket to elementer. Det første elementet heter navnet på prosjektet vårt og har en utvidelse av .app. Navnet på det andre elementet avsluttes i tester og har en forlengelse av .xctest. Jeg vil ikke dekke enhetstester i denne serien, så du kan ignorere det andre elementet for nå.
Produktmappen inneholder applikasjonen eller programmene - opprettet av prosjektet etter å ha samlet kildekoden.
Har du lagt merke til det UIKit.app er uthevet i rødt? Når Xcode ikke klarer å finne en fil, fremhever den filen i rødt. Fordi prosjektet ikke er utarbeidet ennå, har Xcode ikke opprettet produktet enda.
De rammer mappen inneholder rammene prosjektet ditt er koblet til. I den forrige artikkelen var prosjektet bare knyttet til stiftelsens rammeverk. Dette prosjektet er imidlertid basert på en iOS-applikasjonsmal og er derfor knyttet til fire rammer, Foundation, UIKit, Core Graphics og XCTest.
Du kan kanskje huske Core Graphics-rammen fra tidligere i denne serien. Rammen inneholder grensesnittene for (Quartz) 2D tegning API. XCTest-rammen er knyttet til enhetstesting, som jeg ikke vil dekke i denne serien.
Det er et annet sted i prosjektet som spesifiserer hvilke rammer prosjektet er koblet til. Velg prosjektet ditt i Prosjektnavigator, velg det eneste elementet i Targets delen til venstre, og åpne Bygg faser fanen øverst.
Ved å åpne Link binær med biblioteker skuff, presenteres du med samme liste med rammer som vi så i Rammer-mappen. Å koble prosjektet vårt mot et annet iOS-systemramme er like enkelt som å klikke på pluss-knappen nederst i listen og velge et rammeverk fra listen.
Det meste av tiden din blir brukt i prosjektmappen, som for øyeblikket inneholder seks filer og en mappe som heter Støtter filer. La oss begynne med å se på innholdet i mappen Støttefiler.
Accentsconagua
hoved- funksjon, som er der all den magiske starter. Selv om vi ikke vil endre main.m, det er viktig for ditt iOS-program.Nå som vi vet hva de forskjellige filene og mappene i prosjektet vårt er, er det på tide å utforske de ulike komponentene i et iOS-program. Når vi fortsetter vår reise, kommer vi over flere klasser som tilhører UIKit. Hver klasse som tilhører UIKit-rammen starter med klassepremiet UI. Husk at grunnklassene er prefiks med NS.
Før vi begynner å utforske UIKIT-rammen, vil jeg snakke om modell-View-Controller (MVC) -mønsteret. MVC-mønsteret er et av de mest utbredte mønstrene i objektorientert programmering. Det fremmer kodenes gjenbrukbarhet og har nær tilknytning til begrepet separering av ansvar eller bekymringer. Et av hovedmålene med MVC-mønsteret er adskillelsen av en applikasjons forretningslogikk fra presentasjonslaget.
Cocoa Touch omfatter MVC-mønsteret, og det er derfor viktig å forstå hva det er og hvordan det fungerer. Med andre ord, ved å forstå MVC-mønsteret, vil det være mye lettere å forstå hvordan de forskjellige komponentene i et iOS-program samarbeider.
I MVC-mønsteret har en modell kontroll over forretningslogikken til et program. Interaksjon med en database, for eksempel, er ansvaret for modellen. Visningen presenterer dataene som forvaltes av modellen til brukeren. Visningen styrer brukergrensesnittet og brukerinngangen.
Kontrolleren er limet mellom modellen og visningen. Mens modellen og visningen ikke vet om hverandres eksistens, vet styreren om både modellen og visningen.
Fordi kontrolleren vet om både modell og visning, er det ofte det minste gjenbrukbare stykket av et program. Jo mindre en gjenstand vet om miljøet og gjenstandene det samhandler med, desto større blir gjenbrukbarheten i fremtidige prosjekter.
UIApplicationSelv om UIApplication klassen er en nøkkelkomponent i hvert iOS-program, du vil ikke samhandle med det veldig ofte, og du vil sjelden, om noensinne, føle behovet for underklasse UIApplication.
Når et program lanseres, opprettes en singleton av denne klassen. Husker du hva en singleton-gjenstand er? Det betyr at bare ett objekt forekomst av UIApplication klassen er opprettet i løpet av et programs levetid.
De UIApplication eksempel er inngangspunktet for brukerinteraksjon og det sender hendelser til de aktuelle målobjektene. Den nøyaktige betydningen av dette vil bli klart om noen få minutter når vi tar en titt på visningskontrollere.
I de fleste iOS-applikasjoner, er UIApplication eksempel har et delegatobjekt tilknyttet det. Når du oppretter et iOS-prosjekt ved hjelp av en av de angitte maler, vil Xcode opprette en programdelegateklasse for deg. Ta en titt på navnene på kildefilene i prosjektmappen i Project Navigator. De to første filene heter TSPAppDelegate.
Eksemplet på denne klassen er delegaten til UIApplication Singleton. Før du tar en nærmere titt på TSPAppDelegate klasse, må vi forstå hva delegatmønsteret er.
Ole Begemann skrev en utmerket artikkel om lanseringssekvensen av et typisk iOS-program. I denne artikkelen snakker han om de ulike komponentene som er involvert og deres rolle i løpet av programstartingssekvensen. Jeg anbefaler på det sterkeste å lese denne artikkelen hvis du vil få en bedre forståelse av rollen til UIApplication klassen så vel som den mystiske hoved() fungere i main.m.
Delegatmønsteret brukes mye i kakao og kakao. I den neste artikkelen i denne serien, der vi undersøker inn og ut av en tabellvisning, vil du oppdage at tabellvisninger er avhengig av delegert (og datakilde) mønster.
Som MVC-mønsteret er delegasjon vanlig i objektorientert programmering. Delegemønsteret i Cocoa Touch er imidlertid litt annerledes fordi det bruker en delegatprotokoll for å definere oppførselen til delegatobjektet.
La oss hoppe videre og ta en titt på tabellvisninger. Hvis du har brukt mye tid med en iPhone eller iPad, så er UITableView Klassen skal være kjent for deg. Den presenterer en bestilt liste over data til brukeren, og det gjør denne jobben veldig bra.
Hvordan vet en tabellvisning hva som skal gjøres når en rad er tappet? Er denne oppførselen inkludert i UITableView klasse? Absolutt ikke, fordi denne oppførelsen varierer fra søknad til søknad. Hvis vi skulle inkludere denne oppførselen i UITableView klasse, ville det ikke være veldig gjenbrukbart.
Bordvisningen outsources Dette ansvaret til et delegatobjekt. Sett annerledes, det delegater denne oppgaven til et annet objekt, a delegat gjenstand. Ta et øyeblikk til å inspisere klassen referansen til UITableView klasse. Den har to egenskaper som heter datakilde og delegat. De delegat Meldes av tabellvisningen når en bruker tapper en rad. Det er ansvaret for delegatobjektet å svare på brukerens trykk.
Datakilden til tabellvisningen er lik med hensyn til atferd. Hovedforskjellen er at tabellvisningen spør Datakilden objekt for noe, dataene den trenger å vise.
Delegere og data kildeobjekter, for eksempel tabellvisningen delegat og datakilde objekter, er nesten alltid egendefinerte klasser, klasser du lager, fordi implementeringen er applikasjonsspesifikk.
Før vi tar en titt på TSPAppDelegate klasse, er det viktig å forstå at et delegatobjekt samsvarer med en delegatprotokoll. I den forrige artikkelen har vi allerede lært om protokoller i Objective-C og hvordan de definerer atferd ved å definere en liste over metoder for at adopsjonene skal implementere.
Nå som vi vet hvilken delegasjon er, er det på tide å utforske TSPAppDelegate klasse som Xcode opprettet for oss. Ved søknadsstart, oppretter applikasjonen en forekomst av TSPAppDelegate klasse. Du trenger vanligvis ikke å tydeliggjøre et programdelegasjonsobjekt.
Åpne headerfilen til TSPAppDelegate klasse (TSPAppDelegate.h) for å undersøke innholdet. Hvis vi ignorerer kommentarene øverst, importerer den første linjen topptekstfilene til UIKIT-rammeverket, slik at vi kan jobbe med sine klasser og protokoller.
#importere
Neste linje skal være kjent. Dette er starten på grensesnittet til TSPAppDelegate klasse som betegnet av @interface direktiv. Det spesifiserer navnet på klassen og klassens superklasse, UIResponder.
Mellom vinkelbeslag er protokollene klassen overholder. De TSPAppDelegate klassen er i overensstemmelse med en protokoll, den UIApplicationDelegate protokollen.
@interface TSPAppDelegate: UIResponder
Neste linje er en eiendomserklæring, som skal se kjent ut. Eiendommen, vindu, er en forekomst av UIWindow, som er en underklasse av UIView. Ordene mellom parenteser, sterk og nonatomic, er valgfrie egenskapsattributter som angir lagringssemantikk og oppførsel av eiendommen. Du kan ignorere dem for nå.
@property (strong, nonatomic) UIWindow * vindu;
Den mest interessante delen av grensesnittet til TSPAppDelegate klassen er UIApplicationDelegate protokoll. Ta en titt på referansen til UIApplicationDelegate protokoll for en komplett liste over metodene protokollen definerer.
Protokollen definerer dusinvis av metoder, og jeg oppfordrer deg til å utforske noen av dem for å få en ide om protokollens evner. Metoden som er mest interessant for oss på dette punktet er applikasjons: didFinishLaunchingWithOptions:.
Når UIApplication eksempel er ferdig med å forberede søknaden om lansering, vil den varsle delegaten vår TSPAppDelegate eksempelvis at søknaden vil fullføre lanseringen - men det har det ennå ikke.
Hvorfor informerer den programdelegatet av denne hendelsen? De UIApplication instans informerer sin delegat om denne hendelsen slik at den har mulighet til å forberede seg på søknadsstart. Gå over til implementeringsfilen til TSPAppDelegate å se hva jeg mener. Den første metoden i implementeringsfilen er applikasjons: didFinishLaunchingWithOptions: og det skal mer eller mindre se ut som det limte seg under.
- (BOOL) søknad: (UIApplication *) søknad didFinishLaunchingWithOptions: (NSDictionary *) launchOptions return YES;
De applikasjons: didFinishLaunchingWithOptions: Metoden gir en referanse til UIApplication forekomst og en ordbok med alternativer, som ikke er av interesse for oss på dette punktet. Metodens gjennomføring er ganske enkel. Alt det gjør er retur JA å fortelle UIApplication eksempelvis at søknaden er klar til å starte.
Xcode-prosjektet inneholder en annen interessant fil, Main.storyboard. Historiebrettet definerer hvordan brukergrensesnittet til søknaden vår vil se ut. Som standard er storyboardet oppkalt Main.storyboard. Velg storyboardet for å åpne det.
Historien inneholder for øyeblikket en visning i det sentrale arbeidsområdet. På høyre side av Prosjektnavigator Du kan se en liste over elementer, hvilke objekter du ser i visningen. Det øverste elementet heter Se kontroller scene, som inneholder et barnobjekt merket Vis kontrolleren.
De Vis kontrolleren objekt har også en rekke barnevarer, men det er en som er av spesiell interesse for oss, objektet heter Utsikt. Husk diskusjonen om MVC-mønsteret. Her kan du se MVC-mønsteret i aksjon. Modellen mangler for øyeblikket, men vi har en visning, den Utsikt objekt, og en kontroller, den Vis kontrolleren gjenstand.
Når applikasjonen lanseres, brukes storyboardet til å lage applikasjonens brukergrensesnitt. Visningsregulatoren blir automatisk opprettet og det er også visningsregulatorens visning. De Utsikt objekt i storyboardet styres av visningskontrolleren.
Vent litt. Hvor finner jeg klassen av visningskontrolleren i storyboardet? Hvordan kan jeg endre sin oppførsel for å skape et unikt program? Velg Vis kontrolleren objekt til venstre i storyboardet og åpne Identitetsinspektør til høyre.
De Identitetsinspektør forteller deg alt du trenger å vite. På toppen, i seksjonen Tilpasset klasse, Du kan se navnet på visningscontrollerens klasse, TSPViewController. Har du lagt merke til at de to filene vi ikke har snakket om ennå har samme navn? Vi vil utforske disse filene om noen få øyeblikk.
Visningsregulatoren er instantiated for oss, fordi det er den første kontrolleren til storyboardet. Dette er angitt i storyboardet ved pilen som peker på storyboardet.
UIViewControllerHvis du åpner TSPViewController.h, du vil legge merke til at TSPViewController klassen er en underklasse av UIViewController. Som TSPAppDelegate, de UIViewController klassen er en underklasse av UIResponder. Se kontroller, eller underklasser derav, faller inn i kontrolleren kategori av MVC mønsteret. Som navnet antyder, styrer de et syn, en forekomst av UIView klassen, som faller i utsikt kategori av MVC mønsteret.
En visningskontroller administrerer en visning og visningens undervisninger som vi ser senere. For å gjøre dette må visningsstyreren vite om visningen. Med andre ord, det må ha en referanse til visningen.
Visningsregulatoren i storyboardet har en referanse til visningen. Du kan bekrefte dette ved å velge visningsregulatoren i storyboardet og åpne Tilkoblingsinspektør til høyre.
I Tilkoblingsinspektør, Du bør se en seksjon som heter Utsalgssteder. Begrepet uttak er et fancy ord for en eiendom, som du kan sette i storyboardet. Hold musen over utløpet som heter utsikt og se hvordan visningen i arbeidsområdet er uthevet. Det er forbindelsen mellom visningskontrolleren og visningen.
UIViewSelv om søknaden din kun har en forekomst av UIWindow, det kan ha mange synspunkter. De UIView Klassen er en viktig del av UIKIT-rammen, fordi mange klasser arver av det - enten direkte eller indirekte.
revidere Main.storyboard ved å velge den og ta en titt på Objektbibliotek på bunnen av Inspektør.
Bla gjennom Objektbiblioteket og dra en merkelapp og a knapp til utsikten i arbeidsområdet. Det spiller ingen rolle hvor du plasserer dem i visningen så lenge de er i visningsregulatorens visning.
Du har lagt merke til at to nye objekter er lagt til i objekter delen til venstre. Både etiketten (UILabel) og knappen (UIButton) arve fra UIView. Har du merket at Merkelapp og Knapp objekter er litt innrykk i forhold til Utsikt gjenstand? Dette indikerer at Merkelapp og Knapp objekter er undervisninger av Utsikt gjenstand. En visning kan ha en eller flere undervisninger som den klarer.
Som jeg tidligere nevnte, UIView Klassen er en viktig del av UIKit. En visning styrer et rektangulært område eller en ramme på skjermen. Den håndterer innholdet i området, underviews og eventuelle interaksjoner med visningens innhold. De UIView klassen er en underklasse av UIResponder. Du lærer mye mer om visninger i løpet av denne serien.
La oss ta en titt på et eksempel for å illustrere forholdet mellom storyboardet, visningen den inneholder og visningsregulatoren. Disse tre komponentene er viktige, og jeg vil sørge for at du forstår bare hvordan de jobber sammen.
For noen minutter siden la du en etikett og en knapp til visningskontrollørens visning. Hvordan vet visningsansvarlig om disse objektene? For øyeblikket vises de ikke i Tilkoblingsinspektør, men vi kan endre det ved å fortelle visningskontrollen om dem.
Åpne visningscontrollerens headerfil (TPSViewController.h) og legg til en egenskap for etiketten og for knappen.
@property IBOutlet UILabel * myLabel; @property IBOutlet UIButton * myButton;
Ved å legge til IBOutlet Søkeord til eiendomsdeklarasjonen, egenskapene vil vises i Connections Inspector i storyboardet og det er det vi vil ha.
Gå tilbake til storyboardet, velg Vis kontrolleren objekt i Se kontroller scene, og åpne Tilkoblingsinspektør til høyre. De nye egenskapene er nå oppført i listen over Utsalgssteder. Visningskontrolleren har imidlertid ikke gjort forbindelse mellom de nye egenskapene og objektene i storyboardet.
Dette er lett å rette opp. Dra fra den tomme sirkelen til venstre for mylabel utløp til etiketten i arbeidsområdet. Dette vil skape den all-viktige tilkoblingen slik at visningscontrolleren vet om etiketten. Gjør det samme for knappen.
Selv om vi kan endre teksten på etiketten i storyboardet, la oss gjøre dette i visningsregulatoren for å illustrere at visningskontrolleren har tilgang til etiketten og knappen i storyboardet.
Åpne visningscontrollerens implementasjonsfil (TPSViewController.m) og se etter viewDidLoad metode. Endre viewDidLoad metode for å gjenspeile implementeringen nedenfor. Kommentarene er utelatt for klarhet.
- (void) viewDidLoad [super viewDidLoad]; [self.myLabel setText: @ "Dette er en forekomst av UILabel."];
Vi kan sende meldinger til etikettegenskapen ved å spørre visningskontrolleren, selv-, for dens mylabel eiendom. Ved å sende mylabel eiendom en melding av setText: og passerer en streng bokstavelig, oppdaterer vi etikettens tekst.
Noter det setText: er en accessor eller setter. Selv om det er mulig å bruke Objective-Cs punktnotering (se nedenfor), har jeg brukt den mer tradisjonelle syntaksen, da det bedre viser deg hva som egentlig skjer.
self.myLabel.text = @ "Dette er en forekomst av UILabel";
Kjør din søknad i iOS Simulator ved å klikke på Løpe knappen øverst til venstre og merk at etikettens tekst er oppdatert.
Vi har utforsket mange nye ting i denne artikkelen. Jeg vil avslutte denne avgiften ved å snakke om handlinger. Akkurat som utsalgssteder er handlinger ikke noe mer enn metoder som du kan se i storyboardet.
La oss se hvordan dette virker. Åpne visningscontrollerens headerfil (TPSViewController.h) og legg til følgende metodedeklarasjon et sted i visningskontrollens grensesnittblokk.
- (IBAction) changeColor: (id) sender;
Ikke bli forvirret av IBAction søkeord. IBAction er identisk med tomrom, noe som betyr at metoden returnerer ingen verdi. Hvis vi tar en nærmere titt på metoden deklarasjonen, kan vi se at det tar ett argument av typen id, en referanse til et objektiv-c objekt.
Som argumentnavnet tilsier, er argumentet for metoden eller handlingen objektet som sendte meldingen til visningskontrolleren. Jeg vil forklare dette mer detaljert på litt.
Gå tilbake til storyboardet, velg Vis kontrolleren objekt i Se kontroller scene, og åpne Tilkoblingsinspektør. En ny seksjon har dukket opp i Tilkoblingsinspektør oppkalt Mottatte handlinger og handlingen vi nettopp har lagt til er oppført i denne delen.
Dra fra den tomme sirkelen til venstre for handlingen til knappen i arbeidsområdet. Et lite vindu med en liste over alternativer skal vises. Listen inneholder alle mulige hendelser som knappen kan svare på. Den som interesserer oss er Berør på innsiden. Denne hendelsen utløses når en bruker berører knappen og løfter fingeren mens den er inne i knappen.
Bygg og kjør din søknad igjen og trykk på knappen. Skjedde programmet også for deg? Hvordan skjedde dette? Når du tastet på knappen, sendte den en melding om changeColor: til visningskontrolleren. Selv om visningsansvarlig erklærer a changeColor: metode, implementerer den ikke denne metoden ennå.
Når en melding sendes til et objekt som ikke implementerer en tilsvarende metode, oppheves et unntak, og programmet krasjer hvis unntaket ikke er fanget. Du kan bekrefte dette ved å kjøre programmet enda en gang, trykke på knappen og inspisere utgangen i konsollvinduet.
For å rette opp dette, må vi implementere changeColor: metode. Åpne visningscontrollerens implementasjonsfil (TPSViewController.m) og legg til følgende metodeimplementering et sted i implementeringsblokken.
- (IBAction) changeColor: (id) avsender NSLog (@ "Sender Class>% @", [sender klasse]); NSLog (@ "Sender Superclass>% @", [sender superclass]); int r = arc4random ()% 255; int g = arc4random ()% 255; int b = arc4random ()% 255; UIColor * farge = [UIColor colorWithRed: (r / 255.0) grønn: (g / 255.0) blå: (b / 255.0) alfa: 1.0]; [self.view setBackgroundColor: color];
Gjennomføringen av changeColor: Metoden er identisk med den vi brukte tidligere i denne serien. Men jeg har lagt til to ekstra NSLog kaller til gjennomføringen for å vise deg at avsenderen av meldingen er faktisk den knappen som vi la til på storyboardet.
Metoden i seg selv er ganske enkel. Vi genererer tre tilfeldige heltall mellom 0 og 255, pass disse verdiene til colorWithRed, grønn, blå: a: å generere en tilfeldig farge, og oppdatere bakgrunnsfargen til visningskontrollens visning med tilfeldig generert farge.
Noter det self.view refererer til visningen som visningskontrolleren styrer og som vi så tidligere i storyboardet.
Bygg og kjør programmet enda en gang, trykk på knappen, og ikke glem å inspisere utdataene i Xcodes konsolvindu. Du vil legge merke til at avsenderen er en forekomst av UIButton og dens superklasse er UIControl.
I denne artikkelen har vi utforsket noen få klasser av UIKit-rammen, og vi tok en nærmere titt på de ulike komponentene i et iOS-program. Vi vil utforske og arbeide med UIKit-rammen nærmere i resten av denne serien.
Hvis du ikke forstår de ulike konseptene og mønstrene fullt ut, er jeg sikker på at du vil når serien går fremover. Ikke nøl med å legge igjen en kommentar hvis du har spørsmål om denne artikkelen.
