Vai jums ir ideja par lietotni, bet trūkst programmēšanas zināšanu, lai sāktu to veidot? Šajā iknedēļas emuāru sērijā How to Unleash Your Inner App Developer es jūs, kas nav programmētājs, soli pa solim iepazīstināšu ar iPhone, iPod touch un iPad lietotņu izveides procesu. Pievienojieties man katru nedēļu šajā piedzīvojumā, un jūs pieredzēsit, cik jautri var būt savu ideju pārvēršana realitātē! Šī ir sērijas 13. daļa. Ja jūs tikai tagad sākat darbu, pārbaudiet sērijas sākums šeit . (Šī ziņa ir atjaunināta uz Swift 1.2, iOS 8 un Xcode 6.3)
Šajā ziņojumā ir ietverta daļa no vissvarīgākās informācijas, kas jums jāzina, lai izveidotu labi izstrādātu lietotni, kas viegli pielāgojas lietotāju pieprasītajām izmaiņām, pastāvīgajām izmaiņām, ko Apple veic iOS ierīcēs, un pastāvīgi mainīgajai iOS ierīču ainavai. Tas viss ir saistīts ar stabilu lietotņu arhitektūru. Mēs veiksim ātru atkāpi no iAppsReview lietotni šonedēļ, lai apskatītu vienkāršāku Kalkulators lietotne, lai palīdzētu mums izveidot labus arhitektūras principus.
Vārds arhitektūra parasti rada priekšstatus par ēkas būvniecības plānošanu. Neatkarīgi no tā, vai būvējat kaut ko tik mazu kā suņu māja vai tik lielu kā debesskrāpis, stabila arhitektūra ir svarīga, lai pārliecinātos, ka dizains ir saprātīgs. Tas ir tikpat pareizi, veidojot programmatūru. Neatkarīgi no tā, vai veidojat nelielu lietotni vai lielu biznesa lietojumprogrammu, laba arhitektūra var atvieglot programmatūras projektēšanu, izveidi un paplašināšanu.
Dizaina modeļi glābšanai
Nesen, kad man vajadzēja uzbūvēt šķūni, nevis sākt no nulles, es apmeklēju internetu, lai redzētu, kādus arhitektūras plānus dalās citi cilvēki. Zināju, ka citi jau no pieredzes ir iemācījušies, ko darīt un ko nedarīt. Es gribēju mācīties no citu pieredzes un kļūdām, nevis pieļaut tādas pašas kļūdas pats.
Šis pats princips attiecas uz programmatūras izveidi. Ar izmēģinājumu un kļūdu palīdzību , citi programmatūras izstrādātāji ir destilējuši savu pieredze tajā, ko mēs saucam dizaina modeļi. Saskaroties ar konkrētu problēmu, varat meklēt dizaina modeļu sarakstu, lai redzētu, ko citi izstrādātāji ir darījuši jūsu situācijā. Lai gan tas ir mazliet smags lasījums, visprecīzākais dizaina modeļu avots ir grāmata Dizaina modeļi: atkārtoti lietojamas objektorientētas programmatūras dizaina elementi autors Gamma, Helms, Džonsons, Vlissides . Nedaudz vieglākai lasīšanai par dažiem konkrētiem dizaina modeļiem iOS izstrādi, skatiet Apple rakstu vietnē šo saiti .
Pārmaiņu paredzēšana
Jūsu lietotne mainīsies ne tikai dažas reizes, bet vairākas reizes — un tas notiek pat pirms tās izlaišanas App Store! Pēc tās izlaišanas jūsu lietotne mainīsies vēl vairāk, jo cilvēki to izmantos, sniegs atsauksmes un ieteiks uzlabojumus.
Ja jūsu lietotne ir izstrādāta, lai paredzētu izmaiņas, šis process ir daudz vienkāršāks. Ja jūsu lietotnes dizains neparedz izmaiņas, jūs gaida daudz nogurdinoša un nevajadzīga pārstrādāšanas. Ja saņemat izmaiņu pieprasījumu no lietotāja un atklājat, ka lietotne ir pilnībā jāpārstrādā, lai ieviestu izmaiņas, jūs neveicāt savu arhitekta darbu. Jūs vēlaties pārliecināties, vai esat izstrādājis savu lietotni, izmantojot arhitektūru, kas paredz izmaiņas, lai padarītu šo procesu pēc iespējas vienmērīgāku.
Kur jūs ievietojat savu kodu?
Iekšā iepriekšējā ziņa , es apspriedu trīs galvenās lietotnes daļas:
- Lietotāja interfeiss
- Galvenā loģika
- Dati
Šīs atsevišķās daļas paturēšana prātā, veidojot lietotni, ir lielisks sākums stabilas arhitektūras izveidē, kas paredz izmaiņas. Ja šīs dažādās daļas ir pārāk cieši saistītas, jūs izveidojat situāciju, kad nevarat mainīt vienu lietotnes daļu, nemainot citu.
Galu galā koda ievietošanas vieta ir saistīta ar to, cik viegli ir rakstīt, paplašināt un uzturēt lietotni. Koda ievietošana loģiskās, paredzamās vietās arī palīdz izvairīties no spēles 'Kur ir šis kods?' ko daudzi izstrādātāji spēlē ikdienā.
Iepazīstinām ar modeļa skata kontrolieri
Formālāks veids, kā aplūkot trīs galvenās lietotnes daļas, ir modeļa skata kontrollera (MVC) dizaina modelis. Šis modelis ir pastāvējis daudzus gadus, un tas palīdz jums saglabāt skaidru nošķiršanu starp jūsu lietotnes galvenajām daļām.
Es daudzus gadus izmantoju Model View Controller un tā daudzos brālēnu modeļus. Tāpēc, kad 2008. gadā pirmo reizi nonācu pie iOS platformas, es biju ieinteresēts dzirdēt, ka Apple mudināja izmantot MVC modeli iOS lietotņu izstrādē.
Tālāk ir norādīts, kā MVC modelis tiek kartēts ar jūsu lietotnes galvenajām daļām.
- Modelis → Dati
- Skats → Lietotāja interfeiss
- Kontrolieris → Core Logic
Sadalīsim to, vispirms apskatot tradicionālo MVC modeļa ieviešanu, un pēc tam varam apskatīt Apple ieviešanu.
Modelis
Modelis ir jūsu lietojumprogrammas dati, un operētājsistēmā iOS tas parasti izpaužas kā entītijām . Vienība parasti attēlo objektu reālajā pasaulē. Piemēram, ja veidojat lietotni, kas apstrādā klientu pasūtījumus, iespējams, ir Klients vienība, Pasūtiet entītija un Produkts entītija. Ja veidojat kāršu spēļu lietotni, iespējams, jums ir a Dīleris vienība, Spēlētājs entītiju, un kāršu komplektu, kas sastāv no atsevišķiem Kart entītijām.
Entītijai ir rekvizīti, kas atspoguļo tā reālās pasaules objekta atribūtus, pēc kura tā ir modelēta. Piemēram, klienta entītijai varētu būt Kompānijas nosaukums , interneta adrese , tālrunis , adrese , un citi rekvizīti, kuros ir šī informācija par katru klientu, kā parādīts 1. attēls .
 |
| 1. attēls — A Customer Entity ir īpašības, kas atspoguļo tā pārstāvētā reālās pasaules objekta atribūtus. |
Skatīt
Skats ir lietotnes daļa, ar kuru lietotājs mijiedarbojas tieši, un tajā ir ietverti lietotāja interfeisa objekti, piemēram, pogas, teksta lauki, slīdņi un tā tālāk. Tādēļ Apple katru lietotnes ekrānu, kas ir pilns ar informāciju, dēvē par a skats .
Kontrolieris
Kontrolieris darbojas kā starpnieks starp modeli un skatu. Kontrolieris ir vieta, kur atrodas jūsu lietotnes galvenā loģika. 2. attēls parāda mijiedarbību starp modeli, skatu un kontrolieri.
 |
| 2. attēls — modeļa, skata un kontrollera mijiedarbība |
MVC shēmā lietotājs mijiedarbojas ar skatu — viņš var pieskarties, pieskarties, saspiest vai švīkāt lietotāja interfeisa objektam. Atbildot uz to, View nosūta zvanu kontrolierim, un kontrolieris kaut ko veic, pamatojoties uz šo mijiedarbību. Piemēram, lietotājs var mainīt informāciju teksta laukā un pieskarties a Gatavs pogu. Kontrolieris varētu ņemt šo jauno informāciju un atjaunināt modeļa entītiju.
Dažreiz, saglabājot modeļa entītiju, tā iegūst jaunas vai noklusējuma vērtības. Modelis var aktivizēt notikumu, kas kontrolierim paziņo: “Man ir atjaunināti dati”. Pēc tam kontrolieris var atjaunināt skatu, un jaunie dati var tikt parādīti lietotāja interfeisā.
Kontrolieris ir vieta, kur jums vajadzētu ievietot savas lietotnes pamata loģiku. Piemēram, lietotnē Kalkulators var būt kalkulatora kontrollera objekts, kas saskaita, atņem, reizina un dala.
Bažu nošķiršana
MVC ir lielisks veids, kā “nošķirt problēmas” — nošķirt trīs lietotnes daļas. MVC diagrammā, kas parādīta 2. attēls , ir sakaru līnijas starp modeli un kontrolieri un starp kontrolieri un skatu, taču jūs nekad neredzēsit saziņu starp modeli un skatu. Tas ļauj jūsu datus un pamata loģiku izmantot neatkarīgi no lietotāja interfeisa. Kad veidojat universālu iOS lietotni (tādu, kas darbojas gan iPhone, gan iPad), tas ir ļoti svarīgs apsvērums!
Apple MVC ieviešana
Dizaina modeļi ir lielisks rīks, lai ātri izveidotu augstas kvalitātes lietotnes. Tomēr esmu atklājis, ka konkrēta modeļa ieviešana var neatbilst modeļa sākotnējam nolūkam. Piemēram, es biju pārsteigts par Apple izmantoto MVC modeli, jo tā nebija tradicionāla ieviešana. Tas nav tikai akadēmisks, ziloņkaula torņa jautājums. Diemžēl Apple ieviestā MVC nenodrošina skaidri noteiktas robežas starp trim galvenajām lietotnes daļām, kas ir viss MVC modeļa mērķis.
Domāju, ka arhitektūras principu izpratnei nekas vairāk nepalīdz kā reāla piemēra skatīšanās. Tāpēc esmu izveidojis lietotnes paraugu, kas atbilst Apple MVC modelim, un pēc tam esmu atkārtoti izveidojis lietotni, izmantojot labāku MVC ieviešanu.
Kalkulatora parauga lietotne ar Apple MVC
Pirmā manis izveidotā lietotne ir kalkulators, kas izskatās un darbojas tāpat kā iebūvētais iOS kalkulators. To var lejupielādēt no šo saiti . Veiciet šajā sadaļā norādītās darbības, lai uzzinātu, kā šī lietotne darbojas aizkulisēs.
- Atveriet lietotni Xcode. Lai to izdarītu, varat atlasīt Fails > Atvērt... no Xcode izvēlnes dodieties uz Lejupielādes mapē, urbt tajā KalkulatorsDemo mapi un veiciet dubultklikšķi uz Calculatordemo.xcodeproj failu.
- Programmā Project Navigator atlasiet Galvenais.stāstījums failu, un jūs redzēsit ainu, kas parādīta 3. attēls.
 |
| 3. attēls — galvenā aina KalkulatorsDemo projektu |
- Lai redzētu, kā lietotne izskatās izpildes laikā, vispirms pārliecinieties, vai Xcode Shēma vadība ir iestatīta uz iPhone 6 un pēc tam noklikšķiniet uz Skrien pogu. Kad programma tiek parādīta simulatorā, noklikšķiniet uz jebkura cipara un pēc tam noklikšķiniet uz operatora, piemēram, mīnusa zīmes. Ievērojiet, ka ap operatoru tiek parādīts izcēlums, tāpat kā iebūvētajā kalkulatorā. Tas norāda pašlaik atlasīto darbību.
- Noklikšķiniet uz cita skaitļa un vienādības zīmes, un jūs redzēsiet, ka kalkulators darbojas pilnībā. Varat izmantot atmiņas taustiņus, saskaitīt, atņemt, lasīt un notīrīt kalkulatora atmiņu. Varat pat izmantot izplatītākos kalkulatora saīsnes.
- Turiet nospiestu jebkuru ciparu vai operatora taustiņu un ievērojiet, ka ēnojums nedaudz mainās, norādot, ka poga ir nospiesta.
Tagad apskatīsim Kalkulatora lietotni izstrādes laikā, lai noskaidrotu, kas tai liek.
- Dodieties atpakaļ uz Xcode un noklikšķiniet uz Stop pogu.
- Ar Galvenais.stāstījums atlasīto failu, parādiet dokumenta kontūras paneli, atlasot Redaktors > Dokumenta kontūra no Xcode izvēlnes. Kā parādīts 4. attēls , dokumenta kontūra parāda visu pašlaik atlasītās ainas lietotāja saskarnes objektu hierarhisku skatu. Ir pieci attēli (tiek identificēti ar sufiksu 'img'), un ir diezgan daudz pogu objektu.
 |
| 4. attēls. Lietotāja interfeisa objekti dokumenta kontūras rūtī |
- Tagad dodieties uz Project Navigator, izvērsiet Atbalsta faili grupu un izvēlieties CalculatorBackground.png failu. Tas parāda attēlu Interfeisa veidotāja redaktorā ( 5. attēls ).
 |
| 5. attēls — Kalkulators fona attēls |
Jūs varat būt pārsteigts, redzot, ka pogas nav atsevišķi attēli. Kalkulatora fons ir viens attēls, kurā ir iekļautas visas darbības laikā redzamās pogas! Kā, palaižot lietotni, tiek radīta ilūzija par atsevišķām pogām? Virs katras pogas ir neredzama taisnstūra poga.
- Lai to redzētu, atgriezieties un atlasiet Galvenais.stāstījums failu programmā Project Navigator. Noklikšķiniet uz numura 9 pogu. Kā redzat iekšā 6. attēls , esat atlasījis neredzamu pogu, kas atrodas tieši virs pogas.
 |
| 6. attēls. Neredzama poga atrodas virs katras pogas galvenās lietotnes attēlā. |
Kad ir atlasīta neredzamā poga, dodieties uz atribūtu inspektoru (trešā poga no labās puses inspektora rīkjoslā). Ievērojiet, ka galvenē Inspektora rūts augšpusē tas norāda, ka atlasītais objekts ir a Poga . Pēc noklusējuma šī poga ir neredzama, ļaujot parādīt cipara pogu zem tās esošajā attēlā.
Darbības laikā, kad lietotājs pieskaras neredzamai pogai virs cipara, citam attēlam, CalculatorButtons.png , tiek parādīts neredzamās pogas zonā. Šis attēls Alfa vērtība ir iestatīta tā, lai tā lielākoties būtu caurspīdīga. Tāpēc izpildes laikā pieskaroties vienai no šīm pogām, tā izskatās nedaudz tumšāka, radot nospiešanas iespaidu. Kad izpildes laikā tiek pieskarties darbības pogai, tiek padarīts redzams slēptais izcēluma attēls, kurā ap atlasīto pogu ir redzama balta apmale.
Ainas augšpusē ir displejs Kalkulators. Šī ir vienkārši etiķete ar to Izlīdzināšana iestatīts uz Labi-Pamatots sēžot virsū zaļgani pelēkam skatam. Nospiežot ciparu pogas un veicot aprēķinus, kalkulatora pašreizējā vērtība tiek saglabāta mapē tekstu Etiķetes īpašums.
Kalkulatora pamatloģika
Tagad apskatīsim tuvāk kodu skata kontrollerī, kas saistīts ar šo ainu, lai redzētu, kā kalkulatora lietotāja interfeiss mijiedarbojas ar loģikas pamatkodu.
Kā parādīts 7. attēls , ir trīs darbības metodes, kas saistītas ar kalkulatora pogām, kas atrodamas ViewController klase:
- darbībaPieskāries: ir savienots ar visām darbības pogām.
- izceltOperācija: ir savienots ar saskaitīšanas, atņemšanas, reizināšanas un dalīšanas pogām. Izmantojot šo metodi, tiek pievienots izcēlums ap atlasīto pogu un noņemts no iepriekš iezīmētās pogas.
- pieskāriena skaits: ir savienots ar visām ciparu pogām, ieskaitot komata pogu.
Visas šīs metodes ir atkarīgas no lietotāja interfeisa, jo tās ir tieši saistītas ar lietotāja interfeisa vadīklām.
 |
| 7. attēls. Kalkulatora darbības metodes |
Lai skatītu sarakstu ar citām Kalkulatora pamata loģikas metodēm, kas atrodamas ViewController klase, pārbaudiet 8. attēls . Visas kalkulatoram nepieciešamās metodes ir atrodamas ViewController .
 |
| 8. attēls. Kalkulatora metodes ViewController klasē. |
9. attēls sniedz augsta līmeņa pārskatu par mijiedarbību starp kalkulatora ciparu pogām lietotāja saskarnē un ViewController klasē.
 |
| 9. attēls – kalkulatora ciparu pogas mijiedarbība ar kodu |
- Lietotājs pieskaras ciparu pogai.
- Skatu kontrolieris pieskāriena skaits: sauc darbības metodi.
- Iekš pieskāriena skaits: metodi, tiek veikta kāda lietotāja interfeisa apstrāde un pēc tam skata kontrollera apstrāde procesa numurs: metode tiek saukta.
- The procesa numurs: metode izpilda kalkulatora pamata loģiku jauna skaitļa apstrādei un atgriež jauno kalkulatora vērtību.
- Iekš pieskāriena skaits: metodi, atgriešanās vērtība no procesa numurs: metode tiek saglabāta tekstu īpašums lblKopā etiķete.
Tagad īsi apskatīsim, kā mijiedarbojas lietotāja interfeiss un skata kontrollera kods, kad tiek atlasīta darbība, kā aprakstīts 10. attēls .
 |
| 10. attēls. Darbības poga un koda mijiedarbība |
- Lietotājs pieskaras darbības pogai.
- Skatu kontrolieris darbībaPieskāries: sauc darbības metodi.
- Iekš darbībaPieskāries: metodi, pēc lietotāja interfeisa apstrādes koda izpildīšanas skata kontrollera veikt Operāciju: metode tiek saukta.
- The veikt Operāciju: metode izpilda kalkulatora pamata loģiku darbības veikšanai un atgriež kalkulatora jauno vērtību.
- Iekš darbībaPieskāries: metodi, atgriešanās vērtība no veikt Operāciju: metode tiek saglabāta tekstu īpašums lblKopā etiķete.
Kas ir nepareizi ar šo arhitektūru?
Šķiet, ka kalkulatora lietotne darbojas labi. Tas saskaita, atņem, reizina, dala un pareizi veic visas pārējās darbības. Kas tad par problēmu?
Pārbaudiet spēcīgo saikni starp kalkulatora lietotāja interfeisu un skata kontrolleri, kā parādīts attēlā 11. attēls . Objektorientētās programmēšanas terminos tas ir pazīstams kā cieša sakabe .
 |
| 11. attēls — cieša saikne starp kalkulatora lietotāja interfeisu un galveno loģiku |
Kalkulatora lietotāja saskarne ir nedalāmi saistīta ar skata kontrolleri. Skata kontrollerī ir rekvizīti un metodes, ar kurām ir tieši savienotas lietotāja interfeisa vadīklas. Saskaņā ar Apple dokumentāciju skats parasti ir saistīts ar vienu skata kontrolleri. Galu galā skata kontrolleris ir lietotāja interfeisa objekts. Problēma nav ciešā savienojuma starp skatu un skata kontrolleri — tas ir pilnīgi labi. Problēma ir galvenā loģika, kas atrodas skata kontrollerī. Kāpēc tā ir problēma?
Laba lietotne bieži vien kļūst par savu panākumu upuri. Pieņemsim, ka izlaižat lietotni Kalkulators ar tās pašreizējo arhitektūru. Ja tas labi darbojas App Store, varat apsvērt zinātniskā kalkulatora lietotnes izveidi. Vai nebūtu lieliski atkārtoti izmantot dažas lietotnes Kalkulators funkcionalitātes, jo zinātniskais kalkulators dara visu, ko dara parastais kalkulators, un vēl vairāk?
Diemžēl, tā kā kalkulatora galvenā loģika ir apglabāta skata kontrollerī, nav tīra veida, kā atkārtoti izmantot šo loģiku citā lietotnē. Tas ir 'iestrēdzis' lietotāja saskarnes nezālēs.
Labāka MVC ieviešana
Tātad, kā novērst šo problēmu? Kalkulatora pamata loģika ir jānovieto citā vietā, kur varat tai piekļūt no vairākām lietotnēm vai no vairākiem skatu kontrolleriem vienā lietotnē. Ja jums nevajadzētu ievietot savu galveno loģiku skatu kontrollerī, kur to vajadzētu ievietot?
Biznesa kontroliera objekti
Atbilde ir a biznesa kontroliera objekts (pazīstams arī kā a biznesa objekts vai domēna objekts ). Biznesa objekts nodrošina neitrālu vietu galvenās loģikas ievietošanai, ko var atkārtoti izmantot no jebkura lietotāja interfeisa, tostarp skatu kontrolleriem. Kā parādīts 12. attēls , varat izveidot a Kalkulators biznesa klase, kurā ievietojat visas Kalkulatora galvenās loģikas metodes.
 |
| 12. attēls. Kalkulatora biznesa objekta ieviešana |
Šajā attēlā kalkulatora lietotāja saskarne un skata kontrolleris ir cieši saistīti, un tas ir labi — tie abi ir lietotāja interfeisa objekti. Kad lietotāji izpildes laikā pieskaras kalkulatora pogām, skata kontrollerī tiek tieši izsauktas darbības metodes.
Vienīgais kods, kas jāievieto skata kontrollerī, ir kods, kam ir kāds sakars ar lietotāja interfeisu. Tomēr, ja ir jāveic galvenā loģika, skata kontrollerim ir jāizsauc atbilstoša metode Kalkulators biznesa objekts.
Ar savu galveno loģiku Kalkulators klasē, jūs varat viegli izveidot a Zinātniskais kalkulators apakšklase, kas pārmanto visas galvenās funkcionalitātes Kalkulators un paplašina to, pievienojot darbības, kā parādīts attēlā 13. attēls .
 |
| 13. attēls. Kalkulatora pamata loģiku var viegli paplašināt, ja tas pieder pie savas klases. |
Citas biznesa objektu izmantošanas priekšrocības
Veidojot biznesa objektus, jūs veidojat objektu attēlojumu reālajā pasaulē. Iekš Kalkulators lietotnē, jūs veidojat reālās pasaules kalkulatora attēlojumu. Nekustamā īpašuma lietotnē varat izveidot Māja , Pircējs , Īpašnieks , un Nekustamā īpašuma aģents biznesa klases, kas pārstāv reālās pasaules vienības ( 14. attēls ).
 |
| 14. attēls. Biznesa objekti attēlo reālās pasaules objektus. |
Biznesa objektu izveide palīdz pārvarēt kaut ko, ko sauc par semantiskā plaisa . Semantiskā plaisa ir atšķirība starp reālās pasaules objektiem un to, kā jūs modelējat vai aprakstāt šos objektus savās lietojumprogrammās. Daudzās lietotnēs šī atšķirība ir ļoti liela, jo izstrādātājs nav izveidojis nevienu biznesa objektu. Jūs atklāsiet, ka, samazinot semantisko plaisu, izveidojot biznesa objektus, kas attēlo reālās pasaules objektus, jūsu lietotnes ir daudz vieglāk izstrādāt, izveidot, uzturēt un paplašināt.
Jūs modelējat reālās pasaules objektu atribūtus, izmantojot īpašības, un jūs modelējat to uzvedību, izmantojot metodes. Piemēram, mājai ir tādi atribūti kā adrese, vairākas guļamistabas, vairākas vannas, cena un tā tālāk, ko var aprakstīt vai modelēt pēc klases īpašībām. Mājai var būt arī tāda uzvedība kā 'laišana tirgū', 'izņemšana no tirgus' un tā tālāk, ko var modelēt kā metodes biznesa objektu klasē.
Vēl viens biznesa objektu izmantošanas ieguvums ir tas, ka tas palīdz izvairīties no spēles 'Kur ir kods?' Es minēju iepriekš. Visa galvenā loģika, kam ir kāds sakars ar mājas īpašnieku, ir Mājas īpašnieks biznesa objekts. Viss kods, kam ir kāds sakars ar nekustamā īpašuma aģentu, ir atrodams Nekustamā īpašuma aģents biznesa objekts, un viss kods, kam ir kāds sakars ar lietotāja interfeisu, atrodas skatu kontrollerī.
Biznesa objektu izmantošana arī palīdz izvairīties no koda dublēšanas. Ja neizmantojat biznesa objektus, ir viegli izveidot dublikātu kodu, jo bieži aizmirstat, ka esat jau izveidojis kādu funkcionalitāti citā skata kontrollerī. Ja izmantojat biznesa objektus, ir mazāka iespēja biznesa klasē izveidot divas metodes, kas veic tieši to pašu funkciju.
Uzlabotā kalkulatora parauga lietotne
Tagad, kad esat redzējis, kā nē lai izstrādātu lietotni, apskatīsim jauno un uzlaboto CalculatorPlusDemo lietotnes paraugs, kas izmanto kalkulatora biznesa objektu, kuru varat lejupielādēt no šo saiti .
Pēc projekta atvēršanas programmā Xcode, dodieties uz Project Navigator, izpētiet CalculatorPlusDemo mezglu un pēc tam izvērsiet Lietotāja interfeiss un Galvenā loģika grupas. Kā redzat iekšā 15. attēls , saskaņā Lietotāja interfeiss grupa ir storyboard un skata kontrollera lietotāja interfeisa faili. Saskaņā Galvenā loģika grupa ir Kalkulators biznesa objektu klases faili.
 |
| 15. attēls - CalculatorPlusDemo projektu faili |
Apskatīsim uzlaboto ziņojumu plūsmu CalculatorPlusDemo lietotne. 16. attēls sniedz augsta līmeņa pārskatu par to, kas notiek, kad lietotājs pieskaras ciparu pogai.
 |
| 16. attēls — uzlabotā kalkulatora ciparu pogas un koda mijiedarbība |
- Lietotājs pieskaras ciparu pogai.
- The pieskāriena skaits: skata kontrollerī tiek izsaukta darbības metode, kas satur lietotāja saskarnei raksturīgu kodu.
- Pēc lietotāja interfeisa apstrādes koda izpildes skata kontrolleris izsauc kalkulatoru procesa numurs: metodi.
- Kalkulatora objekts procesa numurs: metode izpilda pamata loģiku jauna skaitļa apstrādei un atgriež kalkulatora pašreizējo vērtību.
- Skata kontrolleris ņem vērtību, kas atgriezta no kalkulatora procesa numurs: metodi un saglabā to tekstu īpašums lblKopā etiķete.
Tagad apskatīsim augsta līmeņa pārskatu par to, kas notiek, kad lietotājs pieskaras darbības pogai, kā parādīts attēlā 17. attēls .
 |
| 17. attēls — uzlabotā kalkulatora darbības pogas koda mijiedarbība |
- Lietotājs pieskaras darbības pogai.
- The darbībaPieskāries: skata kontrollerī tiek izsaukta darbības metode, kas satur lietotāja saskarnei raksturīgu kodu.
- Pēc lietotāja interfeisa apstrādes izpildes skata kontrolleris izsauc kalkulatora objektu veikt Operāciju: metodi.
- Kalkulatora objekts veikt Operāciju: metode izpilda pamatdarbības loģiku un atgriež kalkulatora pašreizējo vērtību.
- Skata kontrolleris ņem vērtību, kas atgriezta no kalkulatora veikt Operāciju: metodi un saglabā to tekstu īpašums lblKopā etiķete.
Galvenā atšķirība šeit ir tā, ka veikt Operāciju: metode ir pārvietota no ViewController klasei uz Kalkulators klasē.
Secinājums
Runājot par modeļa skata kontrollera dizaina modeli, jūs uzzinājāt, ka View un View Controller veido jūsu lietotāja interfeisu, un kopā tie ir Skatīt MVC shēmā.
Tu arī ir iemācījušies, ka jūsu lietotnes pamatloģikai ir jābūt ietvertai biznesa objektos, kas attēlo reālās pasaules entītijas. Šie biznesa objekti ir Kontrolieris iekš MVC modelis.
Bet kā ir ar modeli? Kā jau minēju šajā ziņojumā, modelis ir jūsu lietotnes dati, un tas parasti ir uzņēmējdarbības vienību veidā. Savā nākamajā ierakstā es runāšu par iOS tehnoloģiju, kas pazīstama kā Core Data un kas izmanto kaut ko, ko sauc par entītiju objektiem. Šie entītiju objekti ir biznesa objektu attēla otra puse, kas papildinās jūsu izpratni par MVC modeli.