Share
Velkommen tilbake til den tredje avgiften i begynnelsen iOS Development videoserie. I denne leksjonen vil vi se på Interface Builder og hvordan vi kan bruke den i iOS-prosjekter.
Notatene under er komplementære til videoen. Hvis du har spørsmål om noe som er nevnt i videoen, vennligst ikke nøl med å spørre i kommentarseksjonen.
Først vil vi se på grensesnittet Builder-grensesnittet. Ved åpning av en XIB vil du se 4 forskjellige vinduer. Bibliotekvinduet, Vis / Vindu, Dokumentvindu og Attributter, Størrelse, Tilkoblinger og Identitetsvindu. Hvis du ikke ser en eller noen av disse vinduene, må du kontrollere at Interface Builder kjører ved å åpne vinduene på Verktøy-menyen.
Biblioteket er der alle UIKit-objektene er tilgjengelige for bruk i prosjektet. Bare å dra objektet på vinduet vil legge det til visningen. Biblioteket er delt inn i 3 seksjoner.
Hvis du ønsker å bruke en UITabBar i søknaden din, må du ikke dra en UITabBar inn på visningen. Hvordan du bruker UITabBar, UINavigationBar og Search baren, er ved hjelp av en kontroller. En kontroller strekker seg fra disse objektene og håndterer automatisk grunnleggende funksjonalitet for disse objektene. Ved å bruke en UITabBar-kontroller, håndteres automatisk overgangen og styringen av forskjellige UIViewControllers.
Alle de viktigste UIKIT-objektene stammer fra UIView-klassen. I kakao er alt utviklet på en arvet, treaktig måte. Ingen funksjonalitet dupliseres når den kan arves. Hva jeg mener med dette er UIButton-objektet, som et eksempel, er en etterkommer av UIView-klassen. På grunn av dette arver UIButton alfa, innholdsmodus, størrelse og andre egenskaper som UIView-klassen har, men den strekker seg også på de med ekstra funksjonalitet, som å fungere som en knapp.
Ovennevnte skjermbilde fra Interface Builder viser at UIButton-klassen arver fra UIControl-klassen, som igjen arver fra UIView-klassen og så videre. Alt dette er basert på NSObject-klassen som du finner som base for en hvilken som helst kakaoklasse. Hver av disse klassene, arvet fra hverandre, bringer funksjonalitet fra hverandre og deretter strekker seg.
Dette vinduet lar deg endre egenskaper og innstillinger på et valgt UIView-objekt. Avhengig av brukergrensesnittet kan det tillate deg å endre skrifttypeinnstillinger, objektets stil, bakgrunnsfarger eller opasitet.
Tilkoblingsseksjonen viser alle tilgjengelige handlinger som objektet kan svare på, samt eventuelle koblede uttak eller handlinger.
Størrelsesdelen gjør som du forventer. Du kan endre objektets X & Y-koordinater, samt de fysiske dimensjonene. Dette inkluderer også autosizing-alternativene som styrer hvordan elementet vil endre størrelsen i tilfelle en skjermrotasjon eller dimensjonsendring.
Identitetsdelen er ikke vanlig, men det har noen interessante felt. Hvis du har utvidet et UIKit-objekt og vil bruke din egen klasse i stedet for standardinnstillingen, kan du overføre objekternes grunnklasse. Det er noen alternativer rundt tilgjengelighet og Interface Builder interne felt som notater og lar å navngi objekter.
Når skjermen roterer på en iOS-enhet, kan du klare hvordan UI-objektene vil endre posisjonen deres eller hvis de strekker seg for å fylle det nye vinduet. Dette kan alle administreres med dette enkle, lille verktøyet i Interface Builder.
Boksen til venstre er hvor du bestemmer hvordan objektet skal skaleres og boksen til høyre er en animert visualisering av hvordan objektet skal utføres når layoutrammen er endret.
Den ytre boksen til venstre er hvor du setter "ankrene" eller hvilke sider objektet vil låse på. En hvilken som helst side som er valgt, gjør objektet til den siden når skjermdimensjonene endres. Den indre firkanten har kontroller for strekking. Når objektet er låst på 2 sider og skjermen endrer bredden, kan objektet bli fortalt å strekke seg med skjermen. Det er verdt å ha et spill med disse innstillingene og se resultatene fra forskjellige konfigurasjoner.
Når du trenger å koble koden din med et objekt i Interface Builder, bruker du IBAction og IBOutlet. Disse søkeordene er et flagg for Interface Builder å vite at det er en eiendom tilgjengelig for å være koblet til kontrolleren. Du kobler deretter til det tilsvarende objektet med handlingen eller uttaket. En IBAction er hvordan et objekt kan kommunisere tilbake til koden din når en hendelse skjer, når en knapp trykkes, bruker du en IBAction for å ringe en metode tilbake i kontrolleren. En IBOutlet er den inverse, hvordan kontrolleren din kan kommunisere med et objekt i Interface Builder og visningen når som helst.
Å lage en IBOutlet er like enkelt som å legge til flagget når du definerer objektegenskapen i kontrolleren din.
@interface HelloInterfaceBuilderViewController: UIViewController IBOutlet UILabel * myText; @property (nonatomic, behold) IBOutlet UILabel * myText;
En IBAction er lik. Når du definerer en metode i headerfilen, legger du til IBAction-flagget som returtype.
@interface HelloInterfaceBuilderViewController: UIViewController // ... IBOutlets og egenskaper ... - (IBAction) buttonPressed: (id) sender;
Koble disse til er en enkel oppgave i Interface Builder.
Når du lager en IBAction: Klikk på objektet i vinduet, hold kontroll, dra til "File Owner" i dokumentvinduet, slipp musen og kontroller deretter. Velg handlingen som skal kobles til fra rullegardinmenyen som er oppgitt.
Når du lager en IBOutlet: Klikk på "File Owner" i dokumentvinduet, hold kontrollen, dra fra "File Owner" til objektet i vinduet, slipp musen og kontroller deretter. Velg uttaket fra rullegardinmenyen som følger med.
Det er ingen solid yay eller nei om dette emnet. Den felles konsensus er at bruk av Interface Builder og XIB er ikke mer intensiv enn å bygge objekter i kontrolleren din. Det er noen bivirkninger ved å gå hverken.
Når du bruker XIB, er det enkelt å overtale visninger med objekter og ikke vurdere minnekonsekvensene. I de fleste tilfeller er det ikke noe å bekymre seg for, men i sensitive deler av et program, er en UITableView et av disse følsomme områdene, og overbelastning av grensesnittet kan føre til at applikasjonen senkes. Husk at hvert objekt i en visning har sin egen minneallokering og er opprettet når visningen er lastet inn i programmet, er nøkkelen.
XIB-mindre programmering tillater objektallokering i det nøyaktige øyeblikk når objektet kreves og deallokering så snart det ikke er nødvendig. Dette holder applikasjonen lett og lydhør, så lenge ingenting lekker (glem å allokere en gjenstand). Men siden dette er gjort innen kode er det ingen visuell fremstilling av hva som er opprettet til søknaden er i simulatoren. Interface Builder lar visningen bli opprettet interaktivt, en WYSIWYG editor. Så som et resultat kan noen av de XIB-mindre visningene se robot eller blid fordi utvikleren ikke har finesset designet.
Det er ingen bestemt beslutning. Hvis en vei føles bedre for deg så er det helt greit. Det er ingen merkbare ytelsesforskjeller mellom de fleste tilfeller.
avklaring: I skjermbildet blir det nevnt at XIB er konvertert fra XML til et grensesnitt på enheten ved kjøring. Det er ikke slik det er. XIB er kompilert til en NIB når du bygger applikasjonen og brukes i søknaden som en NIB. XIB-filtypen ble opprettet for å tillate Source Code Management-tjenester, for eksempel SVN og Git, å utføre bedre med en XML-basert fil (slik at diff kan utføres) i stedet for en kompilert binær fil.
Accentsconagua