iOS-projektin parhaat käytännöt ja työkalut

Avoimen lähdekoodin Xcode-projektimallilla

Työskennellessäni greenfield iOS -projekteissa jouduin usein aloittamaan uuden projektin tyhjästä. Suorittaessani niin, minä ja ryhmämme vietimme aina paljon aikaa projektin perusasetuksiin, kuten työkalujen integrointiin, projektirakenteen määrittämiseen, perustuntien kirjoittamiseen, ulkoisten kirjastojen integrointiin jne.

Päätin, että projektin käynnistykseen käytetty aika voidaan säästää ja prosessi voidaan enimmäkseen automatisoida. Kirjoitin kaikki käyttämämme tavalliset parhaat käytännöt ja työkalut ja valmistelimme projektimallin, jota minä ja tiimini voimme käyttää aloittaessamme uusia projekteja. Tämän mallin tulisi säästää projektin perustamisaikaa ja tarjota myös yhteinen perusta, johon jokainen tiimin jäsen on tottunut, jotta sinun ei tarvitse miettiä ja tutkia projektin rakennetta ja perustaa. He ovat aina samoja.

Jokainen malliin sisältyvä työkalu tai paras käytäntö ansaitsee erillisen artikkelin, mutta halusin yrittää koota yhteen kaikki kohdat ja antaa lyhyt selitys miksi sisällytin ne.

Cocoapods

En usko, että tämä tarvitsee esittelyä. Tämä on kirjasto iOS-projektien ulkoisten riippuvuuksien hallintaan. Se on ollut olemassa jo pitkään, ja se on vankka ja taistelutestattu tuhansissa (ellei miljoonissa) projekteissa. Siellä on vaihtoehtoisia riippuvuuspäälliköitä, kuten Carthage, mutta päätin mennä Cocoapodien kanssa, koska sillä on laajin avoimen lähdekoodin projekti, jota se tukee. Cocoapodien käyttö on erittäin helppoa, ja sen mukana tulee hakemisto, jonka avulla voit helposti löytää tarvitsemiasi paketteja.

Malliprojekti sisältää yksinkertaisen Podfile-tiedoston, joka sisältää Swiftlintin ja R.swiftin. Malli sisältää myös Gemfilen Cocoapods-version hallitsemiseksi, jota käytetään riippuvuuksien ratkaisemiseksi. Tämä on usein huomiotta jätetty parannus, joka estää ongelmia, jotka syntyvät, kun ryhmäsi kehittäjät asentavat riippuvuudet itse Cocoapodsin eri versioilla. Gemfile pakottaa käyttämään samaa Cocoapods-versiota koko joukkueessa.

Swiftlint

Swiftlint on erittäin hyödyllinen työkalu tiettyjen sääntöjen ja koodaustyylin valvomiseksi jokaiselle joukkueen ohjelmoijalle. Voit ajatella sitä automatisoituna koodin tarkistusjärjestelmänä, joka varoittaa ohjelmoijaa vaarallisista asioista, kuten voimien purkamisesta, voiman heittoista, voimankäynnistä jne., Mutta myös vahvistaa yhteistä koodaustapaa varmistamalla, että kaikki ohjelmoijat noudattavat samoja “koodityyliä” koskevia sääntöjä kuten sisennys- tai etäisyyssäännöt. Tällä on valtavia etuja siitä, että säästät koodin tarkistusaikaa vain suorittamalla nämä perustarkastukset, ja se myös tekee projektin kaikista tiedostoista tuttuja, mikä lisää niiden luettavuutta ja seurauksena niiden ymmärtämistä kaikilla kehittäjillä. Löydät luettelon kaikista säännöistä täältä. Mallineessa Swiftlint asennetaan Cocoapodien välityksellä ja sisällytetään rakennusvaiheisiin, joten se tuhoaa ja varoittaa kehittäjää jokaisessa projektirakennuksessa.

R.swift

R.swift on työkalu voimakkaasti kirjoitettujen, automaattisen täydennysresurssien, kuten kuvien, kirjasintyyppien ja lokalisaatioiden saamiseksi. Se tekee tämän skannaamalla projektisi ja luomalla resurssien saamiseksi tarvittavat nopeat luokat. Tämän kirjaston suurin myyntikohta on, että resurssien käytön aikana se tekee koodisi:

  • Täysin kirjoitettu - vähemmän casting ja arvata, mitä menetelmä tuottaa
  • Kokoaika valittu - ei enää virheellisiä merkkijonoja, jotka tekevät sovelluksen kaatumaan suorituksen aikana
  • Automaattisesti täydennetty - koskaan ei tarvitse arvata kyseisen kuvan / nibin / kuvakäsikirjan nimeä uudestaan

Harkitse seuraavaa koodia käyttämällä virallista merkkijono-sovellusliittymää:

anna kuvake = UIImage (nimeltään: “custom-icon”)

Jos kirjoitat kuvan nimen kirjoittamalla väärin, saat nollan täällä. Jos joku tiimisi jäsenistä muuttaa kuvaresurssin nimeä, tämä koodi palaa nollaksi tai kaatuu, jos pakotat kuvan kääntämään. Kun käytät R.swiftiä, tästä tulee:

anna kuvake = R.image.customIcon ()

Nyt voit olla varma, että kuvake todella esiintyy (kääntäjä varoittaa sinua, jos se ei johdu käännösajantarkistusten ansiosta) ja olet sury, et tee kirjoitusvirhettä kuvakkeen nimessä, koska käytät automaattista täydennystä.

R.swift asennetaan Cocoapodien kautta ja integroidaan malliin rakennusvaiheena ja generoi Swift-kääreluokat jokaiseen rakennukseen. Tämä tarkoittaa, että jos lisäät tiedoston / kuvan / lokalisoinnin / fontti / väri / nib jne., Se on käytettävissäsi R.swiftin avulla, kun käännät projektin.

Erillinen AppDelegate testiä varten

Hyvin usein huomioimatta jätetty tapa on erillinen TestAppDelegate-luokka testien suorittamisessa. Miksi se on hyvä idea? No, AppDelegate-luokka tekee yleensä paljon työtä sovelluksen käynnistyksen yhteydessä. Se voisi perustaa ikkunan, rakentaa sovelluksen peruskäyttöliittymärakenteen, rekisteröidä ilmoituksia varten, perustaa tietokannan ja jopa joskus soittaa API-kutsuja joihinkin taustapalveluihin. Yksikkötesteillä ei tulisi olla sivuvaikutuksia. Haluatko todella soittaa satunnaisia ​​api-puheluita ja määrittää sovelluksesi kaikki käyttöliittymärakenteet vain suorittaa joitain yksikkötestejä?

TestAppDelegate on myös loistava paikka saada koodi, jonka haluat suorittaa vain kerran testisarjan suorittamisen aikana. Se voi sisältää koodin, joka tuottaa pilkkaa, tukkia verkkopyyntöjä jne.

Malli sisältää main.swift-tiedoston, joka on sovelluksen tärkein tulopiste. Tässä tiedostossa on menetelmiä, joiden avulla voidaan tarkistaa, mikä ympäristö on sovellus parhaillaan, ja jos se on testiympäristö, se käynnistää TestAppDelegate-sovelluksen.

Kääntäjän suorituskyvyn profilointiliput

Swift on loistava kieli, helppokäyttöisempi ja paljon turvallisempi kuin Objective-C (IMO). Mutta kun se ensimmäisen kerran esiteltiin, sillä oli yksi suuri haittapuoli - kootusajat. Takaisin Swift 2 päivässä, työskentelin projektissa, jossa oli suunnilleen 40 kt riviä Swift-koodia (keskikokoinen projekti). Koodi oli erittäin raskas geneeristen ja tyyppisten päätelmien kanssa ja puhtaan rakenteen laatiminen kesti lähes viisi minuuttia. Kun teit pienenkin muutoksen, projekti kääntyi uudelleen, ja muutoksen näkeminen kesti noin 2 minuuttia. Se oli yksi huonoimmista kehittäjäkokemuksista, joita minulla on koskaan ollut, ja lopetin sen vuoksi melkein Swiftin käytön.

Ainoa ratkaisu tuolloin oli yrittää profiloida projektin käännösajat ja yrittää muuttaa koodiasi siten, että kääntäjä nopeutuisi. Tämän avustamiseksi Apple esittelee joitain epävirallisia kääntäjälippuja, jotka varoittavat sinua, kun muodostat menetelmäkappaleen tai lausekkeen tyypin ratkaiseminen kesti liian kauan. Lisäsin nuo liput malliprojektiin, joten sinua varoitetaan alusta alkaen pitkistä käännösajoista sovelluksellesi.

Nykyään rakennusajat ovat parantuneet dramaattisesti, ja sinun täytyy harvoin muokata koodiasi vain parantaaksesi rakennusaikoja. Mutta silti on parempi tietää etukäteen ja yrittää korjata ongelma, kun projekti tulee liian isoksi.

Kehitys- / lavastus- / tuotantokokoonpanot

Toinen hyvä käytäntö (tai voin sanoa välttämättömyyden) on erilliset kokoonpanot ja ympäristömuuttujat kehitys-, lataus- ja tuotantoympäristöille. Lähes jokaisessa sovelluksessa on nykyään oltava yhteys jonkinlaiseen taustapalveluun ja yleensä nämä palvelut otetaan käyttöön useissa ympäristöissä. Kehitysympäristöä käytetään päivittäisiin käyttöönottoihin ja ohjelmistoversioiden testaamiseen niiden koodi. Lavastusympäristöä käytetään vakaisiin julkaisuihin testaajille ja asiakkaille testattavaksi. Me kaikki tiedämme, mikä tuotantoympäristö on.

Yksi tapa tukea useita ympäristöjä iOS-projektissa on lisätä projektitason määrityksiä.

Projektitason kokoonpanot

Kun olet määrittänyt kokoonpanot, voit luoda Configuration.plist-tiedoston, joka sisältää muuttujat jokaiselle ympäristölle.

Configuration.plist

Projektia ajaessasi voit määrittää käytettävän kokoonpanon. Voit tehdä tämän rakennusmallissa.

Sinun on sitten lisättävä yksi ylimääräinen ominaisuus projektin Info.plist-tiedostoon. Tämän ominaisuuden arvo ratkaistaan ​​dynaamisesti suorituksen aikana nykyisen kokoonpanon nimeen.

Tämä kaikki on valmiiksi määritetty sinulle mallissa.

Ainoa jäljellä on kirjoittaa luokka, joka voi noutaa nämä muuttujat suorituksen aikana riippuen rakennusmallissa valitusta kokoonpanosta. Malli sisältää ConfigurationManager-luokan, joka voi hakea nykyisen ympäristön muuttujat. Voit tarkistaa luokan toteutuksen Githubista nähdäksesi kuinka se toimii.

readme

Jokaisella projektilla tulisi olla perus Readme, jossa on ainakin ohjeet riippuvuuksien asentamisesta ja projektin suorittamisesta. Sen tulisi sisältää myös kuvaus projektiarkkitehtuurista ja moduuleista. Valitettavasti kehittäjät eivät halua kirjoittaa dokumentaatiota (readme on osa sitä) ja olen nähnyt projektin, jota kehitettiin kuukausien ajan, ja heillä oli jopa perus Readme. Tämän peruskyselyn kirjoittamisen taakan poistamiseksi malli sisältää vakiolukeman, joka kattaa asennuksen ja projektirakenteen. Kun määrität uuden projektin mallin avulla, Readme sisällytetään automaattisesti.

Gitignore

Nykyään useimmat projektit käyttävät GIT: tä versionhallintajärjestelmänään. Kun käytät GIT: tä, sinun ei yleensä tarvitse sivuuttaa joitain projektin tiedostoja tai kansioita, kuten rakennuskansiota tai johdettua tietokansiota. Säästääksesi ongelmia, kun etsit iOS-projektiasi sopivaa gitignore-tiedostoa, malli sisältää tavallisen gitignore-tiedoston, jonka Github-avustajat tarjoavat.

Perusluokat syvälinkkien ja ilmoitusten käsittelemiseksi

Lähes jokaisessa sovelluksessa on nykyään käsiteltävä linkkejä ja ilmoituksia. Tätä varten kehittäjän on kirjoitettava pieni määrä kattilakoodikoodia AppDelegate-luokkaan. Malli on peittänyt, ja se tarjoaa myös perusluokkia, jotka helpottavat työskentelyä linkkien ja ilmoitusten kanssa.

Yhteenveto

Yhteenvetona voidaan todeta, että malli yrittää sisältää parhaat käytännöt ja integroi hyödyllisiä kolmansien osapuolien työkaluja. Tämän pitäisi säästää sinulle ja tiimillemme tunteja, jotka vietetään uuden projektin perustamiseen, ja luoda myös yhteinen ja vahva perusta muulle projektille. Palveleeko se sinua hyvin!

PS: Jos sinulla on malleja koskevia ongelmia tai ominaisuuspyyntöjä, jätä minulle kysymys Githubissa. Yritän ratkaista sen vapaa-ajallani.