Primii pași cu UIKit

UIKit este cadrul pe care îl veți folosi cel mai des atunci când dezvoltați aplicații iOS. Definește componentele de bază ale unei aplicații iOS, de la etichete și butoane la vizualizări de tabelă și controlere de navigare. În acest articol, nu numai că vom începe explorarea cadrului UIKit, vom explora, de asemenea, intervalele unui proiect iOS și blocurile de bază ale aplicațiilor iOS.


Care este cadrul UIKit??

În timp ce cadrul Fundației definește clase, protocoale și funcții atât pentru dezvoltarea iOS și OS X, cadrul UIKit este orientat exclusiv către dezvoltarea iOS. Este echivalentul lui Setul de aplicații sau AppKit cadru pentru dezvoltarea OS X.

Ca și Fundația, UIKit definește clasele, protocoalele, funcțiile, tipurile de date și constantele. De asemenea, adaugă funcționalități suplimentare diferitelor clase ale Fundației, cum ar fi NSObject, NSString, și NSValue prin utilizarea categoriilor obiectiv-C.

Categoriile Obiectiv-C sunt o modalitate convenabilă de a adăuga metode suplimentare la clasele existente fără a fi nevoie de subclasare. Citiți acest tutorial de Aaron Crabtree dacă doriți să aflați mai multe despre categoriile obiectiv-C.

În loc să explorăm clasele-cheie ale UIKit, așa cum am făcut-o pentru cadrul Fundației, vom crea și călătorim printr-un nou proiect iOS și vom explora clasele pe care le întâlnim. Prin adoptarea acestei abordări, va deveni rapid clar în ce context este folosită o clasă și modul în care fiecare clasă se încadrează în schema mai largă a unei aplicații iOS și ce rol joacă.


Un nou început

Lansați Xcode și creați un nou proiect selectând Nou> Proiect ...  de la Fişier meniul. În secțiunea iOS din stânga, selectați cerere categorie. Din lista de șabloane de proiect, alegeți Vizualizare individuală șablon.

Șablonul Application Single View conține blocurile de bază ale unei aplicații iOS și, prin urmare, este un loc bun pentru a începe călătoria noastră.

Denumiți proiectul UIKit și introduceți numele organizației și identificatorul companiei. Introduceți un prefix de clasă, așa cum am explicat mai devreme în această serie și setați Dispozitive la iPhone.

Spuneți Xcode unde doriți să salvați noul proiect și asigurați-vă că ați pus proiectul sub control de versiune prin bifarea casetei de selectare etichetate Creați un depozit git pe My Mac. Revizuiți acest articol pentru mai multe informații despre controlul versiunii și beneficiile acestuia.


Fișiere și foldere

Am învățat câteva lucruri noi de la ultima dată când am creat un proiect iOS de la zero, deci este o idee bună să explorăm diferitele fișiere și foldere ale noului nostru proiect pentru a vedea dacă sună un clopot.

În Project Navigator, ar trebui să vedeți trei dosare la baza proiectului;

  • Produse
  • Cadrele
  • un dosar cu numele proiectului dvs., UIKit în acest exemplu
  • un folder al cărui nume se termină cu testeUIKitTests în acest exemplu

Să aruncăm o privire la conținutul fiecăruia dintre aceste dosare.

Produse

Produse dosarul conține în prezent două elemente. Primul element poartă numele proiectului nostru și are o extensie de .aplicaţia. Numele celui de-al doilea element se termină teste și are o extensie de .xctest. Nu voi acoperi testele unitare din această serie, astfel încât să puteți ignora al doilea element de acum.

Dosarul Produse conține aplicația-sau aplicațiile-create de proiect după compilarea codului sursă.

Ai observat asta UIKit.app este evidențiată în roșu? Ori de câte ori Xcode nu poate localiza un fișier, acesta evidențiază fișierul în roșu. Deoarece proiectul nu a fost încă compilat, Xcode nu a creat încă produsul.

Cadrele

Cadrele folder conține cadrele proiectul dvs. este legat împotriva. În articolul precedent, proiectul nostru a fost legat doar de cadrul Fundației. Acest proiect, totuși, se bazează pe un șablon de aplicație iOS și, prin urmare, este legat de patru cadre, Fundația, UIKit, Core Graphics și XCTest.

Este posibil să vă amintiți cadrul Core Graphics de la începutul acestei serii. Cadrul conține interfețele pentru API-ul de desen 2D (Quartz). Cadrul XCTest este legat de testarea unitară, pe care nu o voi acoperi în această serie.

Există o altă locație în proiectul nostru care specifică cadrul în care este legat proiectul. Selectați proiectul în Project Navigator, alegeți singurul element din Obiective din stânga și deschideți Construiți faze în partea de sus.

Prin deschiderea Link binar cu bibliotecile sertar, vi se prezintă aceeași listă de cadre pe care le-am văzut în folderul Cadru. Conectarea proiectului nostru cu un alt sistem de sisteme iOS este la fel de ușor ca și clic pe butonul plus din partea de jos a listei și selectând un cadru din listă.

Dosarul proiectului

Cea mai mare parte a timpului este petrecut în dosarul proiectului, care conține în prezent șase fișiere și un folder numit Susținerea fișierelor. Să începem să aruncăm o privire asupra conținutului dosarului Fișiere suport.

  • -Info.plist: Acest fișier, denumit în mod obișnuit fișierul "info-dot-plist" al unui proiect, este o listă de proprietăți care conține diferite setări de configurare. Majoritatea acestor setări pot fi modificate și prin selectarea proiectului în Project Navigator, alegerea țintei în Obiective listă și deschiderea GeneralCapacități, și Info file.
  • InfoPlist.strings: Dacă Info.plist conține valori care trebuie să fie localizate, atunci puteți face acest lucru prin specificarea acestora InfoPlist.strings. Localizarea aplicațiilor este ceva ce nu ne vom ocupa în această serie.
  • main.m: Acest fișier trebuie să fie familiar până acum. Cu toate acestea, când creați aplicații iOS, rareori modificați conținutul main.m. Conține aplicația principal funcție, care este în cazul în care toate magia începe. Chiar dacă nu vom modifica main.m, este esențial pentru aplicația dvs. iOS.
  • -Prefix.pch: Acesta este proiectul antet precomplicat fișier, pe care l-am întâlnit deja în această serie. După cum sugerează și numele, fișierele header aflate în fișierul antet precompilat sunt precompilate de Xcode, ceea ce reduce timpul necesar pentru a vă compila proiectul. Cadrele Fundației și UIKit nu se schimbă foarte des, astfel încât nu este nevoie să le compilați de fiecare dată când compilați proiectul. În plus față de precomprimarea fișierelor antet listate în fișierul antet precompilat, fiecare fișier sursă din proiect este prefixat cu fișierele antete listate.

Componentele aplicației

Acum, când știm ce sunt diferitele fișiere și foldere din proiectul nostru, este timpul să explorăm diferitele componente ale unei aplicații iOS. Pe măsură ce continuăm călătoria noastră, vom întâlni mai multe clase care aparțin UIKit. Fiecare clasă care aparține cadrului UIKit începe cu prefixul clasei UI. Amintiți-vă că clasele Fundației sunt prefixate cu NS.


Modelul-View-Controller Pattern

Înainte de a începe să explorăm cadrul UIKit, vreau să vorbesc despre modelul Model-View-Controller (MVC). Modelul MVC este unul dintre cele mai răspândite modele de programare orientate pe obiecte. Promovează reutilizarea codului și are legături strânse cu conceptul de separare a responsabilităților sau preocupărilor. Unul dintre obiectivele principale ale modelului MVC este separarea logicii de afaceri a aplicației de stratul de prezentare.

Cocoa Touch îmbrățișează modelul MVC și, prin urmare, este important să înțelegem ce este și cum funcționează. Cu alte cuvinte, înțelegând modelul MVC, va fi mult mai ușor să înțelegeți cum funcționează împreună diferitele componente ale unei aplicații iOS.

În modelul MVC, un model este în controlul logicii de afaceri a unei aplicații. Interacțiunea cu o bază de date, de exemplu, este responsabilitatea modelului. Vizualizarea prezintă datele gestionate de model către utilizator. Vederea gestionează interfața utilizator și intrarea utilizatorului.

Controlerul este adezivul dintre model și vedere. În timp ce modelul și vizualizarea nu știu despre existența celuilalt, controlorul cunoaște atât modelul, cât și viziunea.

Deoarece controlorul cunoaște atât modelul, cât și vederea, este adesea piesa cea mai puțin reutilizabilă a unei aplicații. Cu cât un obiect nu cunoaște mai bine mediul său și obiectele cu care acesta interacționează, cu atât reutilizarea acestuia va fi mai mare în proiectele viitoare.


UIApplication

Chiar dacă UIApplication clasa este o componentă cheie a fiecărei aplicații iOS, nu veți interacționa cu ea foarte des și veți rata, dacă vreodată, să simțiți nevoia de a subclasa UIApplication.

Când se lansează o aplicație, se creează un singur ton din această clasă. Vă amintiți ce este un obiect singleton? Aceasta înseamnă că numai o singură instanță a obiectului UIApplication clasa este creată în timpul vieții unei aplicații.

UIApplication instanța este punctul de intrare pentru interacțiunea cu utilizatorul și trimite evenimente către obiectele țintă corespunzătoare. Sensul exact al acestui lucru va deveni clar în câteva minute când vom arunca o privire asupra controlorilor de vizualizare.

În cele mai multe aplicații iOS, UIApplication instanța are un obiect delegat asociat cu acesta. Ori de câte ori creați un proiect iOS folosind unul dintre șabloanele furnizate, Xcode va crea pentru dvs. o clasă de delegați de aplicații. Uitați-vă la numele fișierelor sursă din dosarul proiectului din Project Navigator. Primele două fișiere sunt numite TSPAppDelegate.

Exemplul acestei clase este delegatul UIApplication Singleton. Înainte de a vă uita mai atent la TSPAppDelegate clasa, trebuie să înțelegem ce este modelul delegat.

Ole Begemann a scris un excelent articol despre secvența de lansare a unei aplicații tipice iOS. În acest articol, el vorbește despre diferitele componente implicate și despre rolul lor în timpul secvenței de lansare a aplicației. Vă recomandăm foarte mult să citiți acest articol dacă doriți să înțelegeți mai bine rolul UIApplication clasa, precum și misterios principal() funcția în main.m.


Modelul delegației

Modelul de delegat este utilizat în mod extensiv în Cacao și Cocoa Touch. În următorul articol al acestei serii, în care explorăm intrările și ieșirile dintr-o vizualizare de tabel, veți descoperi că opiniile de tabelă se bazează în mare măsură pe modelul delegat (și sursa de date).

Ca modelul MVC, delegarea este comună în programarea orientată pe obiecte. Modelul delegat în Cocoa Touch, cu toate acestea, este ușor diferit, deoarece folosește un protocol delegat pentru a defini comportamentul obiectului delegat.

Să mergem înainte și să aruncăm o privire la vederile mesei. Dacă ați petrecut orice perioadă de timp cu un iPhone sau iPad, atunci UITableView clasa ar trebui să fie familiară pentru tine. Acesta prezintă o listă ordonată de date pentru utilizator și face acest lucru foarte bine.

Cum se știe ce să facă o vizualizare de tabel când se utilizează un rând? Acest comportament este inclus în UITableView clasă? Cu siguranță nu, deoarece acest comportament variază de la aplicație la aplicație. Dacă ar trebui să includem acest comportament în UITableView nu ar fi foarte reutilizabil.

Vizualizarea tabelului contractează această responsabilitate față de un obiect delegat. Pune altfel, asta delegați această sarcină unui alt obiect, a delega obiect. Luați un moment pentru a inspecta referința de clasă a UITableView clasă. Are două proprietăți numite sursă de date și delega. delega este anunțat de vizualizarea tabelului ori de câte ori un utilizator dau un rând. Este responsabilitatea obiectului delegat de a răspunde la apăsarea utilizatorului.

Sursa de date a vizualizării de tabel este similară în ceea ce privește comportamentul. Principala diferență este reprezentată de vizualizarea tabelului solicită obiectul sursă de date pentru ceva, datele pe care trebuie să le afișeze.

Delegați și obiectele sursă de date, cum ar fi vizualizarea tabelului delega și sursă de date obiecte, sunt aproape întotdeauna clase personalizate, clase pe care le creați, deoarece implementarea lor este specifică aplicației.

Înainte să aruncăm o privire la TSPAppDelegate , este important să înțelegeți că un obiect delegat se conformează unui protocol delegat. În articolul precedent, am învățat deja despre protocoalele din Obiectiv-C și modul în care acestea definesc comportamentul prin definirea unei liste de metode pentru implementatorii săi.


Delegatul cererii

Acum, că știm ce este delegația, este timpul să explorăm TSPAppDelegate clasa pe care Xcode a creat-o pentru noi. La lansarea aplicației, aplicația creează o instanță a aplicației TSPAppDelegate clasă. De obicei, nu trebuie să instanțiați în mod explicit un obiect de delegat al aplicației.

Deschideți fișierul antet al TSPAppDelegate clasa (TSPAppDelegate.h) pentru a examina conținutul său. Dacă ignorăm comentariile din partea de sus, prima linie importă fișierele antet ale cadrului UIKit, astfel încât să putem lucra cu clasele și protocoalele sale.

#import 

Următoarea linie trebuie să fie familiară. Acesta este începutul interfeței TSPAppDelegate clasă așa cum este indicată de @interface directivă. Specifică numele clasei și superclasei clasei, UIResponder.

Între parantezele unghiulare sunt protocoalele la care se încadrează clasa. TSPAppDelegate clasa se conformează unui protocol, UIApplicationDelegate protocol.

@ interfață TSPAppDelegate: UIResponder 

Următorul rând este o declarație de proprietate, care ar trebui să pară familiarizată. Proprietatea, fereastră, este un exemplu de UIWindow, care este o subclasă de UIView. Cuvintele între paranteze, puternic și nonatomic, sunt atributele de proprietate opționale care specifică semantica de stocare și comportamentul proprietății. Acum le puteți ignora.

@property (puternic, nonatomic) fereastra UIWindow *;

Partea cea mai interesantă a interfeței TSPAppDelegate clasa este UIApplicationDelegate protocol. Aruncati o privire la referinta UIApplicationDelegate protocol pentru o listă completă a metodelor definite de protocol.

Protocolul definește zeci de metode și vă încurajez să explorați câteva dintre ele pentru a obține o idee despre capacitățile protocolului. Metoda cea mai interesantă pentru noi în acest moment este aplicare: didFinishLaunchingWithOptions:.

Cand UIApplication instanța a finalizat pregătirea cererii de lansare, va notifica delegatul nostru TSPAppDelegate de exemplu, că aplicația va termina lansarea - dar că nu a făcut-o încă.

De ce notifică delegatul aplicației acest eveniment? UIApplication instanța notifică delegatul său despre acest eveniment, astfel încât acesta să aibă posibilitatea de a se pregăti pentru lansarea aplicației. Mergeți la fișierul de implementare al TSPAppDelegate pentru a vedea ce vreau să spun. Prima metodă din fișierul de implementare este aplicare: didFinishLaunchingWithOptions: și ar trebui să arate mai mult sau mai puțin ca cea lipită mai jos.

- (BOOL): aplicație (UIApplication *) didFinishLaunchingWithOptions: (NSDictionary *) launchOptions return YES; 

aplicare: didFinishLaunchingWithOptions: metoda face trimitere la UIApplication instanță și un dicționar cu opțiuni, care nu ne interesează în acest moment. Implementarea metodei este destul de simplă. Tot ce face este să se întoarcă DA să-i spui UIApplication că aplicația este gata să lanseze.

storyboard

Proiectul Xcode conține un alt fișier interesant, Main.storyboard. Tabloul de bord definește cum va arăta interfața utilizator a aplicației noastre. În mod implicit, panoul de planuri este numit Main.storyboard. Selectați tabloul de bord pentru al deschide.

Tabloul de bord conține în prezent o vedere în spațiul central de lucru. În partea din dreapta a ferestrei Project Navigator puteți vedea o listă de elemente, care sunt obiectele pe care le vedeți în vizualizare. Elementul de sus este denumit Vizualizați scena controlerului, care conține un element copil etichetat Vizualizați controlerul.

 Vizualizați controlerul obiect are, de asemenea, un număr de elemente pentru copii, dar există unul care este de interes special pentru noi, obiectul numit Vedere. Rețineți discuția despre modelul MVC. Aici puteți vedea modelul MVC în acțiune. Modelul lipsește momentan, dar avem o viziune Vedere obiect și un controler, Vizualizați controlerul obiect.

Când aplicația noastră se lansează, storyboard-ul este folosit pentru a crea interfața de utilizator a aplicației. Controlerul de vizualizare este în mod automat instanțiat, la fel și vizualizarea controlerului de vizualizare. Vedere obiect în storyboard este gestionat de controlerul de vizualizare.

Așteptați un minut. Unde pot găsi clasa controlerului de vizualizare în tabloul de bord? Cum îmi pot schimba comportamentul pentru a crea o aplicație unică? Selectează Vizualizați controlerul obiect în stânga în storyboard și deschideți Inspectorul de identitate pe dreapta.

 Inspectorul de identitate vă spune tot ce trebuie să știți. În partea de sus, în secțiune Clasa personalizată, puteți vedea numele clasei controlerului de vizualizare, TSPViewController. Ați observat că cele două fișiere despre care nu am vorbit încă au același nume? Vom explora aceste fișiere în câteva momente.

Controlerul de vizualizare este instanțiat pentru noi, deoarece acesta este controlerul inițial de vizualizare a storyboard-ului. Acest lucru este indicat în tabloul de bord cu săgeata indicând tabloul de bord.

UIViewController

Dacă vă deschideți TSPViewController.h, veți observa că TSPViewController clasa este o subclasă de UIViewController. Ca TSPAppDelegate, UIViewController clasa este o subclasă de UIResponder. Vizualizarea controlorilor, sau a subclaselor acestora, intră în controlor categoria modelului MVC. După cum sugerează și numele, ei controlează o viziune, o instanță a UIView clasa, care se încadrează în vedere categoria modelului MVC.

Un controler de vizualizare gestionează o vizualizare și subdiviziuni ale vizualizării așa cum vom vedea mai târziu. Pentru a face acest lucru, controlerul de vizualizare trebuie să știe despre vizualizare. Cu alte cuvinte, trebuie să aibă o referință la opinie.

Controlorul de vizualizare din storyboard are o referință la vizualizare. Puteți verifica acest lucru selectând controlerul de vizualizare în tabloul de bord și deschizând Conectarea inspectorului pe dreapta.

În Conectarea inspectorului, ar trebui să vedeți o secțiune numită Prize. Termenul de ieșire este un cuvânt fantezist pentru o proprietate, pe care o puteți seta în tabloul de bord. Plasați cursorul cu mouse-ul peste priza denumită vedere și observați cum este evidențiată vederea din spațiul de lucru. Aceasta este conexiunea dintre controlerul de vizualizare și vizualizare.


UIView

Chiar dacă cererea dvs. poate avea doar o singură instanță UIWindow, poate avea multe vederi. UIView clasa este o componentă importantă a cadrului UIKit, deoarece multe clase moștenesc de la ea - fie direct, fie indirect.

Revedeți Main.storyboard selectând-o și uită-te la Biblioteca de obiecte în partea de jos a Inspector.

Navigați în Biblioteca de obiecte și trageți a eticheta și a buton la vedere în spațiul de lucru. Nu contează unde le poziționați în vedere, atâta timp cât sunt în vizualizarea controlerului.

Ați observat că au fost adăugate două obiecte noi Obiecte secțiune din stânga. Atât eticheta (UILabel) și butonul (UIButton) moștenire de la UIView. Ați observat că Eticheta și Buton obiectele sunt ușor indentate în comparație cu Vedere obiect? Acest lucru indică faptul că Eticheta și Buton obiectele sunt subieziuni ale Vedere obiect. O vizualizare poate avea una sau mai multe subreviewuri pe care le gestionează.

Așa cum am menționat mai devreme, UIView clasa este o componentă importantă a UIKit. O vizualizare gestionează o zonă sau un cadru dreptunghiular pe ecran. Administrează conținutul zonei, subdiviziuni și orice interacțiune cu conținutul vizualizării. UIView clasa este o subclasă de UIResponder. Veți învăța mai multe despre vizionările pe parcursul acestei serii.


Prize

Să aruncăm o privire la un exemplu pentru a ilustra relația dintre tabloul de bord, vizualizarea pe care o conține și controlerul de vizualizare. Aceste trei componente sunt importante și vreau să vă asigur că înțelegeți cum funcționează împreună.

Cu câteva minute în urmă, ați adăugat o etichetă și un buton la vizualizarea controlerului de vizualizare. Cum știe controlorul de vizualizare despre aceste obiecte? În prezent, acestea nu apar în Conectarea inspectorului, dar putem schimba asta, spunând controlorului de vizualizare despre ele.

Deschideți fișierul header al controlerului de vizualizare (TPSViewController.h) și adăugați o proprietate pentru etichetă și pentru buton.

@property IBOutlet UILabel * myLabel; @property IBOutlet UIButton * myButton;

Prin adăugarea IBOutlet cuvântul cheie la declarația de proprietate, proprietățile vor apărea în Inspectorul de conexiuni din storyboard și asta este ceea ce ne dorim.

Întoarceți-vă la storyboard, selectați Vizualizați controlerul obiect în Vizualizați scena controlerului, și deschideți Conectarea inspectorului pe dreapta. Noile proprietăți sunt listate acum în lista de Prize. Cu toate acestea, controlerul de vizualizare nu a făcut încă conexiune între noile proprietăți și obiectele din storyboard.

Acest lucru este ușor de remediat. Trageți de cercul gol din stânga mylabel ieșiți în etichetă în spațiul de lucru. Aceasta va crea această conexiune foarte importantă, astfel încât controlerul de vedere să știe despre etichetă. Faceți același lucru pentru buton.

Chiar dacă putem schimba textul etichetei în storyboard, să facem acest lucru în controlerul de vizualizare pentru a ilustra faptul că controlerul de vizualizare are acces la eticheta și butonul din storyboard.

Deschideți fișierul de implementare a controlerului de vizualizare (TPSViewController.m) și căutați viewDidLoad metodă. Modificați viewDidLoad pentru a reflecta implementarea de mai jos. Comentariile au fost omise pentru claritate.

- (vid) viewDidLoad [super viewDidLoad]; [self.myLabel setText: @ "Aceasta este o instanță a UILabel."]; 

Putem trimite mesaje către proprietatea etichetei solicitând controlorului de vizualizare, de sine, pentru ei mylabel proprietate. Prin trimiterea mesajului mylabel proprietate un mesaj de setText: și trecând un literal șir, actualizăm textul etichetei.

Rețineți că setText: este un accesor sau setter. Chiar dacă este posibil să folosiți notația de puncte Obiectiv-C (vezi mai jos), am folosit sintaxa mai tradițională, deoarece vă arată mai bine ce se întâmplă de fapt.

self.myLabel.text = @ "Aceasta este o instanță a UILabel";

Rulați aplicația în Simulatorul iOS făcând clic pe Alerga butonul din stânga sus și observați că textul etichetei este într-adevăr actualizat.


acţiuni

Am explorat o mulțime de lucruri noi în acest articol. Vreau să închei această tranșă vorbind despre acțiuni. La fel ca și magazinele, acțiunile nu sunt altceva decât metodele pe care le puteți vedea în tabloul de bord.

Să vedem cum funcționează acest lucru. Deschideți fișierul header al controlerului de vizualizare (TPSViewController.h) și adăugați următoarea declarație de metodă undeva în blocul de interfață al controlerului de vizualizare.

- (IBAction) changeColor: (id) expeditor;

Nu vă confundați cu IBAction cuvinte cheie. IBAction este identic cu vid, ceea ce înseamnă că metoda nu returnează nicio valoare. Dacă ne uităm mai atent la declarația metodei, putem observa că este nevoie de un argument de tip id, o referință la un obiect Obiect-C.

După cum presupune numele argumentului, argumentul metodei sau acțiunii este obiectul care a trimis mesajul la controlerul de vizualizare. Voi explica acest lucru în detaliu în doar puțin.

Revizuiți tabloul de bord, selectați Vizualizați controlerul obiect în Vizualizați scena controlerului, și deschideți Conectarea inspectorului. O nouă secțiune a apărut în Conectarea inspectorului numit Acțiuni primite iar acțiunea pe care tocmai am adăugat-o este menționată în această secțiune.

Glisați de la cercul gol din stânga acțiunii la butonul din spațiul de lucru. Ar trebui să apară o fereastră mică cu o listă de opțiuni. Lista conține toate evenimentele posibile la care butonul poate răspunde. Cel care ne interesează este Touch Up Inside. Acest eveniment este declanșat atunci când un utilizator atinge butonul și ridică degetul în timp ce se află în interiorul butonului.

Construiți și rulați din nou aplicația și atingeți butonul. Aplicația sa prăbușit și pentru dvs.? Cum sa întâmplat asta? Când ați apăsat butonul, a trimis un mesaj de schimba culoarea: la controlerul de vizualizare. Chiar dacă controlerul de vizualizare declară a schimba culoarea: , aceasta nu implementează încă această metodă.

Ori de câte ori este trimis un mesaj unui obiect care nu implementează o metodă corespunzătoare, se ridică o excepție și aplicația se blochează dacă excepția nu este capturată. Puteți verifica acest lucru executând încă o dată aplicația, atingând butonul și inspectând ieșirea din fereastra consolei.

Pentru a remedia acest lucru, trebuie să punem în aplicare schimba culoarea: metodă. Deschideți fișierul de implementare a controlerului de vizualizare (TPSViewController.m) și adăugați următoarea implementare a metodei undeva în blocul de implementare.

- (IBAction) changeColor: (id) expeditor NSLog (@ "Clasa expeditor>% @", [clasa expeditor]); NSLog (@ "Superclasa expeditorului>% @", [superclass expeditor]); int r = arc4random ()% 255; int g = arc4random ()% 255; int b = arc4random ()% 255; UICcolor * culoare = [UICcolor colorWithRed: (r / 255.0) verde: (g / 255.0) albastru: (b / 255.0) alfa: 1.0]; [auto.view setBackgroundColor: culoare]; 

Punerea în aplicare a directivei schimba culoarea: metoda este identică cu cea utilizată anterior în această serie. Cu toate acestea, am adăugat două în plus NSLog solicită implementarea sa să vă arate că expeditorul mesajului este într-adevăr butonul pe care l-am adăugat la storyboard.

Metoda însăși este destul de simplă. Noi generăm trei numere aleatorii între 0 și 255, treceți aceste valori la colorWithRed: verde: albastru: alpha: pentru a genera o culoare aleatorie și pentru a actualiza culoarea de fundal a vizualizării controlerului vizual cu culoarea generată aleator.

Rețineți că self.view face referire la punctul de vedere pe care controlerul de vedere îl gestionează și pe care l-am văzut mai devreme în tabloul de bord.

Construiți și executați aplicația o dată în plus, atingeți butonul și nu uitați să inspectați ieșirea din fereastra consolei Xcode. Veți observa că expeditorul este o instanță de UIButton și superclajul său este UIControl.


Concluzie

În acest articol, am analizat câteva clase ale cadrului UIKit și am analizat cu atenție diversele componente ale unei aplicații iOS. Vom explora și vom lucra cu cadrul UIKit în detaliu în restul seriei.

Dacă nu înțelegeți pe deplin diferitele concepte și modele, atunci sunt sigur că veți evolua în timp ce seria progresează. Nu ezitați să lăsați un comentariu dacă aveți întrebări despre acest articol.

Cod