Az iOS projekt legjobb gyakorlatai és eszközei

Nyílt forráskódú Xcode projekt sablonnal

Amikor zöldmezős iOS projektekkel dolgoztam, gyakran egy új projektet kellett elindítanom a semmiből. Eközben én és a csapatom mindig sok időt töltöttek az alapvető projekt-beállításokon, mint például az eszközök integrálása, a projekt szerkezetének felállítása, az alap osztályok írása, a külső könyvtárak integrálása stb.

Úgy döntöttem, hogy megtakarítható a projekt indításához szükséges idő, és a folyamat többnyire automatizálható. Leírtam az összes általánosan használt bevált gyakorlatot és eszközt, és elkészítettem egy projekt sablont, amelyet én és a csapatom felhasználhatott új projektek indításakor. Ez a sablon megtakaríthatja a projekt elkészítésének idejét, és közös alapot is biztosíthat, amelyhez minden csapat tagja hozzá lesz szokva, hogy ne kelljen gondolkodnia és feltárnia a projekt felépítését és az alapokat. Mindig ugyanazok lesznek.

A sablonban szereplő minden egyes eszköz vagy bevált gyakorlat önmagában érdemel egy cikket, de megpróbáltam összefoglalni az egyes pontokat és röviden magyarázni, miért építettem be őket.

Cocoapods

Nem hiszem, hogy ehhez bevezetésre van szükség. Ez a könyvtár az iOS-projektek külső függőségeinek kezelésére. Ez hosszú ideje működik, és robosztus és csatatesztelés alatt áll több ezer (ha nem millió) projektben. Vannak alternatív függőségi menedzserek is, mint például Carthage, de úgy döntöttem, hogy a Cocoapods-szal megyek, mert a legszélesebb körű nyílt forráskódú projektet támogat, amelyet támogat. A Cocoapods használata nagyon egyszerű, és egy keresési mutatóval rendelkezik, amely lehetővé teszi a szükséges csomagok könnyű felfedezését.

A sablonprojekthez tartozik egy egyszerű Podfile, amely tartalmazza a Swiftlint és az R.swift fájlokat. A sablon tartalmaz egy Gemfile-et a Cocoapods verzió kezelésére, a függőségek megoldására. Ez egy gyakran figyelmen kívül hagyott fejlesztés, amely megakadályozza a problémák felmerülését, amikor a csapata fejlesztői függőségeket telepítenek a Cocoapods különféle verzióival. A Gemfile ugyanazt a Cocoapods verziót használja az egész csapatra.

Swiftlint

A Swiftlint nagyon hasznos eszköz bizonyos szabályok és kódolási stílus betartatására a csapat minden programozója számára. Gondolhat egy automatizált kód-áttekintő rendszerre, amely figyelmezteti a programozót olyan veszélyes dolgokra, mint az erő kibontakozása, erő kiáltása, erőpróbálások stb., De egyúttal érvényesíti a közös kódolási stílust is, biztosítva, hogy minden programozó ugyanazokat a „kódstílus” szabályokat kövesse. mint például a behúzás vagy a távolságszabályok. Ennek óriási előnyei vannak, ha nemcsak a kód-áttekintési időt takarítja meg az alapvető ellenőrzések elvégzésével, hanem a projekt összes fájljának ismerősnek tűnik, ami növeli azok olvashatóságát és ennek eredményeként az összes fejlesztő általi megértését. Az összes szabályt itt találja. A sablonban a Swiftlint a Cocoapodson keresztül kerül telepítésre, és beillesztésre kerül az Összeállítási fázisok lépésben, így minden projektkészítésnél rávilágít és figyelmezteti a fejlesztőt.

R.swift

Az R.swift eszköz erősen gépelt, automatikus kiegészítésű erőforrások, például képek, betűkészlet-összetevők és lokalizációk előállításához. Ez a projekt beolvasásával és az erőforrások megszerzéséhez szükséges gyors osztályok létrehozásával történik. A könyvtár legnagyobb értékesítési pontja az, hogy erőforrások használata közben készíti el a kódját:

  • Teljesen gépelve - kevesebb casting és kitalálás, hogy melyik módszer fog visszatérni
  • Összeállított idő ellenőrizve - nincs több olyan hibás karakterlánc, amely miatt az alkalmazás összeomlik futásidejűleg
  • Automatikusan kitöltött - soha nem kell újra kitalálnia ezt a kép / nib / storyboard nevét

Vegye figyelembe a következő kódot a hivatalos karakterlánc-API használatával:

let icon = UIImage (elnevezés: „custom-icon”)

Ha elírja a kép nevét, itt nulla lesz. Ha a csapat valamelyik tagja megváltoztatja a képforrás nevét, akkor ez a kód nullát ad vissza, vagy összeomlik, ha kényszeríti a kép kibontását. Az R.swift használatakor ez lesz:

let icon = R.image.customIcon ()

Most már biztos lehet benne, hogy az ikon valóban létezik (a fordító figyelmezteti Önt, ha nem a fordítási időellenőrzésnek köszönhetően), és ha szomorú, akkor nem fog elírni az ikon nevét, mivel automatikus kiegészítést fog használni.

Az R.swift a Cocoapodson keresztül telepítve van, és a sablonba építési fázisként integrálódik, és minden egyes összeállítással létrehozza a Swift csomagoló osztályokat. Ez azt jelenti, hogy ha hozzáad egy fájlt / képet / lokalizációt / betűtípust / színt / csíkot stb., Akkor az elérhető lesz az R.swift használatával, miután összeállította a projektet.

Külön tesztelje az AppDelegate alkalmazást

A tesztek futtatásakor gyakran figyelmen kívül hagyott bevált gyakorlat az, hogy külön TestAppDelegate osztály legyen. Miért jó ötlet? Nos, az AppDelegate osztály általában sok munkát végez az alkalmazás indításakor. Beállíthat egy ablakot, felépítheti az alkalmazás alapvető felhasználói felületének felépítését, regisztrálhat értesítésekre, beállíthat egy adatbázist, és akár API-hívásokat is kezdeményezhet valamilyen háttér-szolgáltatáshoz. Az egységtesztnek nem lehetnek mellékhatásai. Valóban nem szeretne véletlenszerű API-hívásokat kezdeményezni és beállítani az alkalmazás összes felhasználói felületének felépítését, csupán néhány egységteszt futtatása érdekében?

A TestAppDelegate kiváló hely egy olyan kódhoz is, amelyet csak egyszer futtat a tesztkészlet végrehajtása során. Tartalmazhat olyan kódot, amely gúnyokat, hálózati kéréseket generál

A sablon tartalmaz egy main.swift fájlt, amely az alkalmazás fő belépési pontja. Ez a fájl olyan módszerekkel ellenőrzi, hogy milyen környezetben fut az alkalmazás, és ha ez a tesztkörnyezet, akkor meghívja a TestAppDelegate-et.

A fordító teljesítményének profilozására szolgáló zászlók

A Swift nagyszerű nyelv, könnyebben használható és sokkal biztonságosabb, mint az Objective-C (IMO). De amikor először bevezették, volt egy nagy hátránya - fordítási idők. A Swift 2 napja alatt egy olyan projekten dolgoztam, amely nagyjából 40 ezer sor Swift kódot tartalmazott (egy közepes méretű projekt). A kód nagyon nehéz volt a generikus és típusú következtetésektől függően, és közel 5 percbe telt a tiszta felépítés összeállítása. Ha még egy apró változtatást elvégzett is, a projekt újrafordul, és körülbelül 2 percbe telt, hogy megnézze a változást. Ez volt az egyik legrosszabb fejlesztői tapasztalat, ami valaha volt, és ezért szinte abbahagytam a Swift használatát.

Akkoriban az egyetlen megoldás az volt, hogy megpróbáltam profilozni a projekt fordítási idejét, és megpróbáltam megváltoztatni a kódot oly módon, hogy ez gyorsabbá tegye a fordítót. Ennek elősegítésére az Apple bevezet néhány nem hivatalos fordítói zászlót, amelyek figyelmeztetnének egy metóstörzs összeállításakor vagy a kifejezés típusának meghatározásakor túl sokáig tart. Ezeket a zászlókat hozzáadtam a sablonprojekthez, így már a kezdetektől figyelmeztetést kapsz az alkalmazásod hosszú fordítási idejéről.

Manapság drasztikusan javultak az építkezési idők, és nagyon ritkán kell módosítania a kódot, hogy javítsa az építkezési időket. De mégis jobb, ha előre tudunk, majd próbáljuk megoldani a problémát, amikor a projekt túl nagyra válik.

Fejlesztő / szakaszos / produkciós konfigurációk

Egy másik jó gyakorlat (vagy mondhatom, hogy szükség van rá), hogy külön konfigurációk és környezeti változók legyenek a fejlesztési, átmeneti és termelési környezetek számára. Manapság szinte minden alkalmazásnak kapcsolódnia kell valamilyen háttér-szolgáltatáshoz, és általában ezeket a szolgáltatásokat több környezetben telepítik. A fejlesztői környezetet használják a napi telepítésekhez és a fejlesztők számára a kóduk teszteléséhez. A szakaszos környezetet tesztelők és ügyfelek stabil kiadásaihoz használják. Mindannyian tudjuk, hogy mi a termelési környezet.

Az iOS-projektek több környezetének támogatásának egyik módja a projekt szintű konfigurációk hozzáadása.

Projekt szintű konfigurációk

Miután meghatározta a konfigurációkat, létrehozhat egy Configuration.plist fájlt, amely tartalmazza az egyes környezetek változóit.

Configuration.plist

A projekt futtatásakor meghatározhatja, hogy melyik konfigurációt kell használni. Ezt megteheti az összeállítási sémában.

Ezután egy további tulajdonságot hozzá kell adnia az Info.plist fájlba. Ennek a tulajdonságnak az értékét dinamikusan oldjuk meg az aktuális konfiguráció neve futási idején.

Mindezt előre beállítottuk a sablonban.

Csak annyit kell hagyni, hogy írjon egy osztályt, amely ezeket a változókat le tudja tölteni futási időben, az összeállítási sémában kiválasztott konfigurációtól függően. A sablon tartalmaz egy ConfigurationManager osztályt, amely lekérheti az aktuális környezet változóit. Ellenőrizheti az osztály megvalósítását a Githubon, hogy megnézze, hogyan működik.

Olvass el

Minden projektnek rendelkeznie kell egy alapvető Readme-mel, amely legalább ismerteti a függőségek telepítésének és a projekt futtatásának útmutatásait. Tartalmaznia kell a projekt architektúrájának és moduljainak leírását is. Sajnos a fejlesztők nem szeretnek dokumentációt írni (a readme ennek része), és láttam olyan projektet, amelyet hónapokig fejlesztettek ki, és még alapszintű Readme-vel is rendelkeztek. Az alapvető readme írásának terheinek elkerülése érdekében a sablon tartalmaz egy standard readme-et, amely lefedi a telepítést és a projekt szerkezetét. Amikor egy új projektet a sablon használatával állít be, akkor a Readme automatikusan bekerül.

Gitignore

Manapság a legtöbb projekt a GIT-t használja verziókezelő rendszerként. A GIT használatakor általában nem szabad figyelmen kívül hagyni a projekt egyes fájljait vagy mappáit, például a build mappát vagy a származtatott adat mappát. Az iOS-projektnek megfelelő gitignore fájl keresése során felmerülő problémák elkerülése érdekében a sablon tartalmazza a Github közreműködői által biztosított szabványos gitignore fájlt.

Alap osztályok a mélylinkek és az értesítések kezelésére

Manapság szinte minden alkalmazásnak kezelnie kell a mélylinkeket és az értesítéseket. Ehhez a fejlesztőnek be kell írnia valamilyen mennyiségű kazánlemez kódot az AppDelegate osztályba. A sablon lefedi, és alapszintű osztályokat is kínál, amelyek megkönnyítik a mélylinkek és értesítések kezelését.

összefoglalás

Összefoglalva: a sablon megkísérel beépíteni a bevált gyakorlatokat, és integrálja a hasznos harmadik fél eszközöit. Ez megtakaríthat Önnek és csapatunknak az új projektbeállításra fordított óráit, valamint közös és erős alapot nyújthat a projekt többi részéhez. Jól szolgálhat!

PS: Ha bármilyen kérdése van, vagy bármilyen szolgáltatási igény van a sablonra, hagyjon nekem egy kérdést a Githubon. Szabad időben megpróbálom megoldani.