iOS-i projekti parimad tavad ja tööriistad

Avatud lähtekoodiga Xcode projekti malliga

IOS-i haljasaladel töötades pidin sageli alustama uut projekti nullist. Seda tehes kulutasid mina ja mu meeskond alati palju aega põhiprojektide seadistamisele, nagu tööriistade integreerimine, projekti struktuuri seadistamine, põhiklasside kirjutamine, väliste raamatukogude integreerimine jne.

Otsustasin, et projekti käivitamiseks kulutatud aega saab kokku hoida ja protsessi saab enamasti automatiseerida. Panin kirja kõik tavapärased parimad tavad ja tööriistad, mida kasutasime, ja koostasin projekti malli, mida mina ja mu meeskond saaksime uute projektide alustamisel kasutada. See mall peaks kokku hoidma projekti seadistamise aega ja pakkuma ka ühise aluse, millega iga meeskonna liige harjub, nii et te ei pea projekti ülesehitust ja sihtasutusi läbi mõtlema ja uurima. Nad jäävad alati samaks.

Kõik mallis sisalduvad tööriistad või parimad tavad väärivad eraldi artiklit, kuid tahtsin proovida iga punkti kokku võtta ja selgitada lühidalt, miks ma need lisasin.

Kakaapood

Ma ei usu, et see vajaks sissejuhatust. See on raamatukogu iOS-i projektide väliste sõltuvuste haldamiseks. See on kestnud pikka aega ning see on vastupidav ja lahinguproovitud tuhandetes (kui mitte miljonites) projektides. Seal on ka muid sõltuvushaldjaid, näiteks Carthage, kuid otsustasin minna koos Cocoapodsiga, kuna sellel on kõige laiem avatud lähtekoodiga projekt, mida ta toetab. Cocoapodide kasutamine on väga lihtne ja sellega on kaasas otsinguindeks, mis võimaldab teil hõlpsalt leida vajalikke pakette.

Malli projektiga on kaasas lihtne Podfile, mis sisaldab Swiftlinti ja R.swifti. Malli juurde kuulub ka Gemfile Cocoapodsi versiooni haldamiseks, mida kasutatakse sõltuvuste lahendamiseks. See on sageli tähelepanuta jäetud parandus, mis hoiab ära probleemide ilmnemise, kui teie meeskonna arendajad installivad sõltuvusi Cocoapodsi enda erinevate versioonide abil. Gemfile kasutab kogu meeskonnas sama Cocoapodsi versiooni.

Swiftlint

Swiftlint on väga kasulik tööriist teatavate reeglite ja kodeerimisstiili jõustamiseks iga meeskonna programmeerija jaoks. Võite mõelda sellest kui automatiseeritud koodide ülevaatussüsteemist, mis hoiatab programmeerijat selliste ohtlike asjade eest nagu jõu lahtipakkimine, jõu väljalaskmine, jõu proovimine jne, kuid rakendab ka ühist kodeerimisstiili, tagades, et kõik programmeerijad järgivad samu „koodistiili“ reegleid nagu taande või vahekauguse reeglid. Sellel on tohutu kasu, kui mitte ainult säästate koodide ülevaatuse aega nende põhikontrollide tegemise abil, vaid see muudab ka kõik projekti failid tuttavaks, mis suurendab nende loetavust ja selle tulemusel nende mõistmist kõigi väljatöötajate poolt. Kõigi reeglite loendi leiate siit. Mallis on Swiftlint installitud Cocoapodide kaudu ja kaasatud ehitusetappide sammu, nii et see visandab ja hoiatab arendajat iga projekti ehitamise ajal.

R.swift

R.swift on tööriist tugevalt trükitud ja automaatselt täidetavate ressursside (nt pildid, fondiühendid ja lokaliseerimine) saamiseks. Selleks skannitakse teie projekti ja genereeritakse ressursside saamiseks vajalikud kiirklassid. Selle raamatukogu suurim müügiargument on see, et ressursside kasutamise ajal muudab see teie koodi:

  • Täielikult kirjutatud - vähem ülekandmist ja aimamist, milline meetod tagasi tuleb
  • Kontrollitud kompileerimise aeg - enam pole mingeid valesid stringe, mis muudavad teie rakenduse töö ajal krahhiks
  • Automaatselt lõpule viidud - mitte kunagi ei pea seda pildi / tihvti / süžeeskeemi nime uuesti arvama

Ametliku stringi API abil kaaluge järgmist koodi:

lase ikoonil = UIImage (nimega: “kohandatud ikoon”)

Kui jätate pildi nime valesti, saate siin nulli. Kui mõni teie meeskonna liige muudab pildiressursi nime, naaseb see kood nulliks või krahhi, kui sunnite pildi lahti pakkima. R.swifti kasutamisel saab see:

lase ikoon = R.image.customIcon ()

Nüüd võite olla kindel, et ikoon on tõesti olemas (kompilaator hoiatab teid, kui see ei õnnestu tänu kompileerimise ajakontrollidele) ja kui te olete surm, ei tee te ikooni nime trükiviga, kuna kasutate automaatse täitmise funktsiooni.

R.swift installitakse Cocoapodide kaudu ja integreeritakse malli ehitamise faasina ning see genereerib Swift-mähkimisklassid iga ehituse korral. See tähendab, et kui lisate faili / pildi / lokaliseerimise / fondi / värvi / nibu jne, on see pärast projekti kompileerimist R.swifti abil saadaval.

Testide jaoks eraldi AppDelegate

Sageli tähelepanuta jäetud hea tava on testide läbiviimisel omada eraldi TestAppDelegate klassi. Miks see on hea mõte? Noh, tavaliselt teeb AppDelegate klass rakenduse käivitamisel palju tööd. See võib akna üles seada, ehitada rakenduse kasutajaliidese põhistruktuuri, registreerida teatisi, seadistada andmebaasi ja mõnikord isegi API-kõnesid mõnele taustateenusele. Ühiktestidel ei tohiks olla mingeid kõrvaltoimeid. Kas te ei soovi tõesti juhuslikke api-kõnesid teha ja kogu rakenduse kasutajaliidese ülesehitust seadistada, et ühikuid testida?

TestAppDelegate on ka suurepärane koht, kus on kood, mida soovite testi komplekti täitmise ajal käitada ainult üks kord. See võib sisaldada koodi, mis genereerib mõnitusi, torkab võrgutaotlusi jne.

Mall sisaldab faili main.swift, mis on rakenduse peamine sisenemispunkt. Selles failis on meetodid, mis kontrollivad, millises keskkonnas rakendus praegu töötab, ja kui see on testkeskkond, kutsub see välja TestAppDelegate.

Kompilaatori jõudluse profileerimise lipud

Swift on suurepärane keel, seda on lihtsam kasutada ja palju turvalisem kui Objective-C (IMO). Kuid kui seda esmakordselt tutvustati, oli sellel üks suur varjukülg - kompileerimise ajad. 2 päeva tagasi Swiftis töötasin projekti kallal, mille SWIFT-kood oli umbes 40 000 rida (keskmise suurusega projekt). Kood oli geneeriliste ravimite ja tüübi põhjal väga raske ning puhta konstruktsiooni koostamiseks kulus peaaegu viis minutit. Kui teete isegi väikese muudatuse, kompileeritakse projekt uuesti ja muudatuse nägemiseks kulus umbes 2 minutit. See oli üks halvimaid arendaja kogemusi, mis mul kunagi olnud, ja lõpetasin selle tõttu peaaegu Swifti kasutamise.

Ainuke lahendus toona oli projekti kompileerimise aegade proovimine ja profiilimine ning teie koodi muutmine viisil, mis muudaks kompilaatori kiiremaks. Selle hõlbustamiseks tutvustab Apple mõnda mitteametlikku kompilaatori lippu, mis hoiataks teid meetodikorpuse koostamisel või avaldise tüübi lahendamisel liiga kaua. Lisasin need lipud malliprojekti, nii et teid hoiatatakse algusest peale teie rakenduse pikkade kompileerimisaegade jaoks.

Tänapäeval on ehitamisaegu dramaatiliselt parandatud ja peate väga harva oma koodi näpistama, et ehituse aega paremaks muuta. Kuid ikkagi on parem teada saada, kui proovite probleemi lahendada, kui projekt muutub liiga suureks.

Arendajate / lavastuste / produktsioonide konfiguratsioonid

Teine hea tava (või võib öelda, et vaja on) on eraldi konfiguratsioonid ja keskkonnamuutujad arendus-, lavastus- ja tootmiskeskkondade jaoks. Tänapäeval peab peaaegu iga rakendus olema ühendatud mingisuguse taustateenusega ja tavaliselt kasutatakse neid teenuseid mitmes keskkonnas. Arenduskeskkonda kasutatakse igapäevaseks juurutamiseks ja seadmetele koodi kontrollimiseks. Lavastuskeskkonda kasutatakse testijate ja klientide testimiseks stabiilsete väljaannete jaoks. Me kõik teame, mis on tootmiskeskkond.

Üks viis iOS-i projekti mitme keskkonna toetamiseks on lisada projekti tasemel konfiguratsioonid.

Projekti tasemel konfiguratsioonid

Kui olete konfiguratsioonid määratlenud, saate luua faili Configuration.plist, mis sisaldab iga keskkonna muutujaid.

Configuration.plist

Projekti käivitamisel saate täpsustada, millist konfiguratsiooni tuleks kasutada. Seda saate teha ehitamisskeemis.

Seejärel peate projekti Info.plist faili lisama veel ühe atribuudi. Selle atribuudi väärtus lahendatakse dünaamiliselt jooksva konfiguratsiooni nime järgi.

See kõik on mallil teie jaoks eelkonfigureeritud.

Ainus, mis üle jääb, on kirjutada klass, mis saab need muutujad käituse ajal alla laadida, sõltuvalt ehitamisskeemis valitud konfiguratsioonist. Malli sisaldab klassi ConfigurationManager, mis saab praeguse keskkonna muutujaid. Saate selle klassi rakendamist Githubis kontrollida, kuidas see töötab.

Readme

Igal projektil peaks olema põhiline Readme, milles on vähemalt juhised sõltuvuste installimiseks ja projekti käivitamiseks. Samuti peaks see sisaldama projekti arhitektuuri ja moodulite kirjeldusi. Kahjuks ei meeldi arendajatele dokumentatsiooni kirjutamine (readme on selle osa) ja ma olen näinud mitu kuud arendatavat projekti ja neil oli isegi põhiline Readme. Selle põhilise lugemiskohustuse kirjutamise koorma eemaldamiseks sisaldab mall standardset lugemismeetodit, mis hõlmab installimist ja projekti ülesehitust. Kui seadistate malli abil uue projekti, kaasatakse automaatselt ka Readme.

Gitignore

Tänapäeval kasutab enamik projekte GIT-i oma versioonikontrollisüsteemina. GIT-i kasutamisel ei taha tavaliselt ignoreerida mõnda projekti faili või kausta, näiteks ehitamiskaust või tuletatud andmete kausta. Teie iOS-i projektile vastava gitignore-faili otsimisega seotud probleemide säästmiseks sisaldab mall standardset gitignore-faili, mille pakuvad Githubi toetajad.

Alusklassid sümmeetriliste linkide ja teatiste käsitlemiseks

Tänapäeval peab peaaegu igas rakenduses käsitlema sisulinke ja teatisi. Selleks peab arendaja kirjutama AppDelegate klassis teatud koguse katlamaja koodi. Mall on kaetud ja pakub ka põhiklasse, mis muudavad sügavate linkide ja teatistega töötamise lihtsamaks.

Kokkuvõte

Kokkuvõtlikult proovib mall kaasata parimaid tavasid ja integreerib kasulikke kolmandate osapoolte tööriistu. See peaks säästa teie ja meie meeskonna töötunde, mis kulutatakse uue projekti seadistamisele, ning loob ka ühise ja tugeva aluse ülejäänud projekti jaoks. Kas see teeniks teid hästi!

PS: Kui teil on malli kohta mingeid probleeme või funktsioone, jätke mulle küsimus Githubis. Püüan selle vabal ajal lahendada.