Målet med den här artikelserien är att ge dig en enkel och lättförståelig procedur som du kan använda varje gång du vill skapa en ny SwiftUI-app. Du kan se den som en "ritning" för alla dina framtida iOS-projekt skrivna i SwiftUI.
Även om du är helt nybörjare inom SwiftUI-utveckling borde du kunna följa den här guiden, eftersom vi kommer att gå igenom varje område steg för steg. Tillsammans lägger vi grunden för alla grundläggande byggstenar i en iOS-app, så att du kan använda och anpassa den där blueprint-appen till dina specifika projektkrav.
Genom den här serien kommer du att lära dig hur du:
Eftersom det finns mycket material att gå igenom och för att undvika att varje artikel blir för lång och tungrodd kommer vi att fokusera på den praktiska tillämpningen snarare än på teorin. Det innebär att du enkelt kommer att kunna följa varje steg i processen för att skapa en app, men vi kommer inte att go gå in på djupet i de teoretiska skälentill varfördet gjordes just på det sättet.
Med det sagt, låt oss kavla upp ärmarna och börja bygga vår SwiftUI-app!
Låt oss börja vår resa genom att skapa ett nytt XCode-projekt. Vi kommer att skapa en iOS-app, så låt oss välja den mallen.
Du kan ange vad du vill i ditt produktnamn och din organisationsidentifierare , men se till att du ställer in SwiftUI som ditt gränssnitt. Vi behöver inte aktivera kryssrutorna Använd kärndata eller Inkludera tester just nu, men gör gärna det i dina nästa projekt.
Toppen! Nu har vi ett nytt iOS-projekt. Vår första uppgift är att göra lite grundläggande projektkonfiguration. Låt oss öppna vårt huvudsakliga projektmål och titta på fliken Allmänt.
Här kan du ställa in många parametrar, till exempel appens visningsnamn, om din app stöder iPad-enheter och vilka orienteringar som är tillgängliga. Ett av de viktigaste besluten du måste fatta när du startar ett mobilprojekt är dock den lägsta operativsystemversionen . Eftersom vi använder SwiftUI, som bara stöds på iOS 13 och senare, är det inte meningsfullt att ställa in en lägsta operativsystemversion till något lägre än 13.0.
Jag skulle dock faktiskt rekommendera att höja den här siffran till 14.0 , den främsta anledningen är att SwiftUI på iOS 13 är riktigt, riktigt dåligt. Det har många buggar och är inte värt besväret eftersom du måste fixa många av dem manuellt, vilket kan göra hela din kodbas till en stor röra.
En rimlig motivering för att sätta den lägsta OS-versionen till 14.0 (eller en ursäkt, beroende på hur man ser på det 😀) är att, i skrivande stund, enligt Apples iOS-användningsspårare , använder 99 % av alla iPhone- och iPad-enheter som introducerats under de senaste fyra åren iOS 14 eller senare. Med tanke på detta är det rimligt att sätta denna begränsning, vilket kommer att göra ditt liv mycket enklare senare.
CocoaPods är inte den enda beroendehanteraren för iOS, men den är bland de mest bekväma. Så låt oss konfigurera den i vårt projekt. Öppna din terminal och kör följande kommando:
$ sudo gem install cocoapodsgo ra sedan till projektets rotmapp (den som innehåller projektfilen.xcodeproj) och kör följande:
$ pod initDetta skapar en Podfile som innehåller alla dina externa Pod-bibliotek. Varje gång vi gör en ändring i den här filen måste vi köra:
$ pod installNu kör vi det här kommandot. Vår Podfile är tom, så inga nya bibliotek kommer att installeras. Vi kommer dock att se ett mycket viktigt meddelande:
Det som just hände är att när man körde kommandot pod install genererades en arbetsyta som nu innehåller både vårt XCode-projekt (som innehåller vår appkod) och Pods-projektet (som innehåller våra CocoaPods-bibliotek).
I praktiken innebär det att du från och med nu aldrig kommer att arbeta direkt med din .xcodeproj -fil, utan du kommer att använda .xcworkspace -filen istället. Så nu är det dags att stänga ditt XCode-projekt och öppna din arbetsyta (i mitt fall heter den SwiftUIBlueprint.xcworkspace ).
Vi har precis aktiverat stöd för CocoaPods i vårt projekt, men vi använder inga bibliotek än. Låt oss ändra på det genom att installera vår första pod. Och vilken bättre pod att börja med än SwiftLint ! Syftet med det här verktyget är att upprätthålla Swifts stil och konventioner, vilket säkerställer att du (och alla andra som arbetar med projektet) skriver ren kod.
Vi installerar det här biblioteket genom att lägga till det i vår Podfile så att det ser ut så här:
Efter att ha sprungit pod install återigen i konsolen kan vi se att den senaste versionen av SwiftLint (i mitt fall version 0.47.0) nu är installerad:
Men som du kan se från SwiftLints readme-fil räcker detta inte för att få varningar och fel att visas i XCode-problemnavigatorn.
För att göra detta måste vi lägga till SwiftLint som en byggfas. Låt oss återigen öppna projektfilen med ” go ” och välja fliken”Build Phases”. Klicka på plusknappen och välj”New Script Run Phase”.
Låt oss döpa vår fas till SwiftLint och lägga in följande skript i den:
"${PODS_ROOT}/SwiftLint/swiftlint"När detta är klart bör ditt byggskript se ut så här:
Nu vore ett bra tillfälle att testa om SwiftLint fungerar. Låt oss öppna vår innehållsvy och göra något som utlöser en varning (till exempel lägga till för många tomma rader) och bygga.
Om du ser varningen om vertikalt whitespace-brott i din editor, då fungerar det! 🎉 Det här kraftfulla verktyget hjälper dig att hålla din kod ren och konsekvent.
Om du av någon anledning vill ignorera en specifik SwiftLint-varning finns det ett sätt att göra det. Skapa en fil som heter .swiftlint.yml i din projektrot. Du kan dock lägga den här filen i vilken projektmapp som helst, men i så fall skulle du behöva uppdatera ditt byggskript med lite extra data för att allt ska fortsätta fungera.
Låt oss säga att vi vill ignorera regeln för vertical_whitespace . I så fall skulle innehållet i vår .swiftlint.yml -fil vara:
Om vi bygger nu kommer vi att se att vår tidigare varning nu är borta:
Konfigurationsfilen .swiftlint.yml kan hjälpa dig att inaktivera alla SwiftLint-regler som du tycker är irriterande eller inte vill tillämpa i din app. Den kan vara särskilt användbar om du vill förhindra kodkontroller från att ske i externa bibliotek. Jag rekommenderar dock att du inte ignorerar SwiftLint-regler om det inte är absolut nödvändigt!
En annan viktig del av alla mobila projekt är lokaliseringen av alla dina meddelanden. Att konfigurera lokalisering tidigt är mycket viktigt. Du bör göra det så snart du skapar projektet, så att du inte behöver omstrukturera en stor del av din kodbas senare om du börjar stödja flera språk i din app. Men även om du inte planerar att stödja flera språk är det fortfarande bra att lokalisera dina strängar, så att du har dem alla på ett och samma ställe.
Låt oss börja med att öppna skärmen Projektinformation.
Som vi kan se i avsnittet ”Lokaliseringar” har vårt nya projekt två språk:”Base”och”English ” – utvecklingsspråk. Språket ”Base” skapas automatiskt som appens standardspråk, vilket troligen kommer att vara ” English ” om du utvecklar din app för den globala marknaden.
Vi kan dock se på höger sida att det finns "0 lokaliserade filer" . Låt oss ändra det genom att skapa vår Localizable.strings -fil.
Låt oss först organisera vårt projekt genom att skapa en ny mapp som heter StödfilerDen här mappen kommer att innehålla vår lokalisering och andra stödjande filer. I den här mappen skapar du en ny mapp med namnet Lokaliseringoch slutligen väljer du att lägga till en ny fil i den mappen.
I fönstret Ny fil söker du efter mallen Strängfil under kategorin Resurs och väljer den.
Låt oss döpa vår fil till Localizable.strings och klicka på Skapa.
Vi har nu vår första Localizable.strings -fil där vi kan ange våra strängar. Den är dock fortfarande inte lokaliserad. Som ett sista steg klickar du på knappen Lokalisera… till höger i redigeraren.
Toppen! Nu visar skärmen ”Projektinfo” att1 fil har lokaliseratsför vårt”English ” — utvecklingsspråk. Låt oss lägga till ett till språk så att vi kan testa om allt fungerar som det ska. Klicka på den lilla+-knappenlängst ner i avsnittet ”Lokalisering” och välj ett annat språk, till exempel tyska.
XCode kommer att känna igen Localizable.strings -filen som du redan skapat, så klicka bara på Slutför för att använda den som referens för det tyska språket.
Klart! Nu har vi två lokaliserbara filer, en för vart och ett av våra språk som stöds.
Dessa filer är dock helt tomma för tillfället. Låt oss ange en exempelsträng i båda språkfilerna och se om allt fungerar korrekt.
Det är en god idé att namnge dina lokaliserbara strängnycklarVynamn.Komponentnamn.Syfte, så några vanliga lokaliserbara nycklar kan vara:
LandingView.Titel LandingView.Subtitle LandingView.LoginButton.Titel LandingView.AreYouSureAlert.Titel LandingView.AreYouSureAlert.BeskrivningEftersom vi bara har en vy i vår app för tillfället, och den heter ContentView, låt oss lägga till dessa strängar i våra lokaliseringsfiler:
"ContentView.WelcomeMessage" = "Hej världen!";"ContentView.WelcomeMessage" = "Hej, värld!";
Slutligen, låt oss hoppa till vår ContentView och ändra Text komponenten så att den använder vår lokaliserade sträng istället för den nuvarande hårdkodade genom att ersätta Text ("Hej världen!") med Text(NSLocalizedString("ContentView.WelcomeMessage", kommentar: "")).
Nu är det dags att köra vår app för första gången i simulatorn!
Bra! Det verkar som att allt fungerar som förväntat. Men kommer appen att visa tyska språket när det behövs? Låt oss testa det genom att öppna Inställningar i iOS-simulatorn och navigera till Allmänt -> Språk och region -> iPhone-språk och sedan välja Tyska . Efter det kör vi appen igen.
Toppen! Nu har vi konfigurerat lokalisering i projektet, vilket kommer att göra stränghanteringen mycket enklare allt eftersom projektet växer i storlek. Det finns dock ytterligare en sak vi kan göra. Du kanske har märkt att vi använder våra lokaliseringssträngar genom att skriva:
NSLocalizedString("ContentView.WelcomeMessage", kommentar: "")Det här är en ganska otymplig kodbit för en så enkel uppgift, håller du inte med? Låt oss göra lokaliseringsfunktionen enklare genom att skapa ett String-tillägg i vårt projekt.
Det första vi ska göra är att skapa några mappar. Skapa en mapp som heter Koda i rotmappen eftersom det är där vi kommer att lägga all vår programkod. Skapa sedan en ny mapp inuti Koda kallad Verksamhetsnyttiga tjänsterSlutligen, här behöver du skapa en annan mapp som heter Tillägg, och inuti den här mappen lägger du till en ny Swift-fil som heter StringExtensions.swiftmed följande innehåll:
import Foundation
extension String {
var localized: String {
return NSLocalizedString(self, comment: "")
}
func localized(arguments: CVarArg...) -> String {
return String(format: self.localized, arguments: arguments)
}
}
Den här strängförlängningen vi just skapade ger oss två fördelar:
"StringKey".lokaliserad i stället för NSLocalizedString("StringKey", kommentar": "") varje gång.Låt oss prova detta genom att ändra vår nuvarande "Hej, världen!" meddelande att säga "God morgon, Peter!", var Peter är en parameter vi kommer att skicka från vår Innehållsvy.
Vi behöver ändra tre delar av vår kod:
"ContentView.WelcomeMessage" = "God morgon, %@!";"ContentView.WelcomeMessage" = "Guten Morgen, %@!";Text("ContentView.WelcomeMessage".localized(arguments: "Peter"))Så här ska dessa tre filer se ut efter denna ändring:
Nu ska vi starta appen och kolla in den!
Och där har du det! Vi har implementerat ett mycket praktiskt sätt att lokalisera våra strängar, vilket hjälper oss att organisera alla meddelanden som kan visas i vår app.
Vi är klara! 🤩
För tillfället, alltså. I det stora hela har vi bara precis börjat eftersom det finns många fler utmaningar att ta itu med när vi bygger vår första SwiftUI-app.
Men vi har redan slutfört några av de viktigaste stegen i alla iOS-appar. Du borde vara stolt över dig själv eftersom du nu har skapat och konfigurerat basprojektet i XCode, aktiverat stöd för CocoaPods, installerat SwiftLint för att säkerställa att din kod är bra och aktiverat lokalisering.
Grattis! 🥳🎉
Om du vill ladda ner ett projekt som innehåller allt vi har gjort hittills kan du göra det genom att klicka här .
I nästa artikel kommer vi att lära oss hur man konfigurerar arkitekturen för vårt projekt. Håll utkik efter mer!