I september 2019 släpptes iOS 13 till allmänheten, vilket inkluderade ett nytt UI-ramverk som heter SwiftUI. Detta ramverk har funnits i nästan två år nu, så nu är det en bra tid att svara på några av de populära frågorna i iOS-communityn:
Låt oss börja med att ta en titt på några av de nya funktionerna som kommer med SwiftUI. Visst, vi kan inte täcka allt i en enda artikel, men vi täcker precis tillräckligt för att du ska få en bra bild av vad du kan förvänta dig av det här nya ramverket. Skriv gärna dina egna erfarenheter och upptäckter av SwiftUI i kommentarfältet i artikeln!
En av SwiftUIs största fördelar är enkelheten i att skapa och strukturera UI-kontroller, med det slutgiltiga målet att "bli den kortaste vägen till en bra app". Eftersom SwiftUI är samma API som finns inbyggt i iOS, iPadOS, macOS, watchOS och tvOS kan utvecklare snabbt bygga inbyggda appar för alla Apples plattformar. Detta uppnås genom många olika designbeslut och filosofier som ingår i ramverket.
Vissa av dessa förändringar är enkla och lätta att förstå, medan andra kan innebära ett stort paradigmskifte i hur vi tänker och kodar jämfört med "gamla UIKit".
Innan vi går in på detaljerna ska vi först titta närmare på en av de viktigaste nya funktionerna för snabb native iOS-utveckling.
Previews är en ny SwiftUI-driven funktion i XCode 11 som minimerar den tid som krävs för att bygga, köra och konfigurera dina vyer och låter dig fokusera på själva skapandet av användargränssnittet.
Vi har alla varit där - den långa och mödosamma återkopplingsloopen. Du får några ritningar för en ny funktion och efter att ha skrivit lite kod vill du kolla hur den ser ut. Så du kör appen i en simulator eller på en fysisk enhet, navigerar till den skärm du har arbetat med och verifierar ditt arbete. Men sedan inser du att utfyllnaden på din knapp behöver ökas lite. Så du ändrar koden, bygger om projektet och kör appen igen. Navigera till rätt skärm. Verifiera. Hittar en annan liten sak som behöver ändras, t.ex. teckenstorlek eller kanske en färg. Bygg om. Kör. Navigera. Verifiera. Skölj och upprepa.
Det största problemet med det här tillvägagångssättet? Istället för att ägna den mesta tiden åt att koda appen eller få feedback, ägnar du dig åt tråkiga arbetsmoment som att bygga, köra, konfigurera och navigera genom appen för att komma till ett läge där du kan verifiera om du har gjort ett bra jobb. Det måste finnas ett sätt att påskynda denna process, eller hur? Lyckligtvis tillåter XCode Previews dig just det - att hoppa över alla tråkiga saker och hoppa direkt till den viktigaste (och roligaste) delen, som är kodning!
När du aktiverar förhandsgranskningar bygger XCode din app på ett specifikt sätt. Den kompilerar filen som du för närvarande tittar på separat från resten av appen och injicerar implementeringen i appen. Eftersom mängden kod som behöver kompileras om efter varje ändring är mycket mindre än resten av din app, gör XCode detta för varje ändring som du gör. Och för ändringar som inkluderar bokstavliga värden som strängar eller siffror - ingen omkompilering krävs - XCode injicerar bara värdet i appen, vilket ger omedelbar "refresh-as-you-type" feedback!
Vill du testa hur en viss vy ser ut med olika indata? Eller kanske hur den ser ut utan några data alls? Du är nyfiken på hur din app ser ut i mörkt läge? Eller på olika iPhone-enheter? Allt detta är inte bara möjligt utan också extremt enkelt att åstadkomma med funktionen Previews.
I följande exempel kan vi se hur enkelt det är att generera flera förhandsvisningar för samma vy:
Om du vet hur man skriver en SwiftUI-vy vet du också hur man skapar en förhandsgranskningskomponent. Du behöver bara anpassa dig till en Leverantör av förhandsgranskning protokollet, som är en del av SwiftUI ramverk. Detta innebär att du måste importera SwiftUI för att använda det. Tänk på att på grund av SwiftUI:s integration med andra Apple-ramverk kan du använda Previews i UIKit, AppKit och WatchKit på samma sätt som i SwiftUI. Det här protokollet har bara ett krav: Du måste tillhandahålla en förhandsvisningar egendom som kommer att rymma ditt innehåll. Vad du lägger in där är upp till dig.
Eftersom XCode-förhandsvisningar bokstavligen kör din kod kan du använda all anpassad logik eller kontext i dina förhandsvisningar och till och med injicera körtidskonfigurationer som AnvändarFörval eller miljöobjekt. Förhandsgranskningen kommer alltid att vara synkroniserad med din vy, vilket gör att du kan prova olika konfigurationer extremt snabbt.
Innan SwiftUI hade utvecklare UIKit, AppKit och WatchKit UI-ramar som använder imperativ programmeringsparadigm. SwiftUI å andra sidan använder deklarativ programmering sparadigm. Så, vad är skillnaden?
Imperativ programmering är ett programmeringsparadigm som använder satser som ändrar ett programs tillstånd. Ett imperativt program består av kommandon som datorn ska utföra. Det fokuserar på att beskriva hur ett program fungerar genom att implementera algoritmer i explicita steg.
Deklarativ programmering är ett programmeringsparadigm där program beskriver sina önskade resultat utan att uttryckligen lista kommandon som måste utföras. Det fokuserar på vad snarare än på hur.
Enkelt uttryckt, i imperativ programmering måste du tillhandahålla en steg-för-steg-instruktion som krävs för att åtgärda ett problem. I deklarativ programmering är allt du bryr dig om att problemet är löst - du bryr dig inte omhur!
För att detta ska vara möjligt måste ramverket naturligtvis tillhandahålla ett domänspecifikt språk (DSL) som kan göra grovjobbet och leverera slutresultatet åt dig.
Det finns många fördelar med deklarativ programmering.
Några av dem är
Om du har erfarenhet av React Native kommer du att märka att arbetet med SwiftUI är väldigt likt! Jag skulle till och med vilja påstå att med SwiftUI får du det bästa av två världar, eftersom utvecklingen av inbyggda iOS-appar nu kombinerar enkelheten och snabbheten i React Native med robustheten i Swift, som ett typsäkert och starkt typat språk, vilket innebär mer hastighet och mer kontroll.
Ett exempel på ett framgångsrikt verktyg för deklarativ programmering är relationsdatabasen. Den tillhandahåller ett domänspecifikt språk som heter SQL, som döljer de lägre nivåerna för användaren, fokuserar på vad som ska hämtas och gör det snabbt.
Låt oss ge ett konkret SwiftUI-exempel på detta deklarativa paradigm. Om du i SwiftUI lägger till eller tar bort en rad från en listvy kommer SwiftUI automatiskt att känna av förändringar i din datainsamling, syntetisera tillägg och borttagningar och rendera dem med sina standardrenderingsanimationer. Du behöver inte skriva någon ytterligare kod och du behöver inte hantera det beständiga datatillståndet själv. Det är kraften i deklarativ kod!
SwiftUI-vyer definieras deklarativt, som en funktion av deras indata. När en input ändras kommer SwiftUI att hämta en uppdaterad version av vyn. En uppdaterad version kommer att visas bara baserat på vad som har ändrats.
Istället för att bygga våra vyer bit för bit som vi gjorde i UIKit, kan vi initiera dem som en komplett kodstruktur. För att lägga till undervyer i containervyer, istället för att anropa funktioner som addSubview()listar vi helt enkelt innehållet i containervyn i en speciell förslutning, som kallas Vybyggare.
Några av de enklaste containervyerna i SwiftUI är HStack och VStacksom placerar sina undervyer i en horisontell respektive vertikal stapel. Andra behållare inkluderar ZStack, ScrollView, Toggle, Lista och många andra. Även en Knapp kontroll är en behållare - den kan innehålla en Text, Bild eller något annat som en tappbar vy!
Till exempel är koden för att skapa en vy som innehåller en bildkontroll och en textkontroll placerade vertikalt ovanför varandra så här enkel:
VStack {
Bild("Bildnamn")
Text("Någon text")
}Vi kan omedelbart se att det krävs mycket färre rader kod för att uppnå detta än i UIKit, och kodstrukturen i sig ger oss en bra uppfattning om hur den här vyn kommer att se ut i appen. Syntaxen är mycket tydlig och lättläst, och användningen av hakparenteser och indrag gör att vi kan skilja mellan containervyer och de vyer som representerar innehåll. Detta gäller för alla kontroller, eftersom de flesta kontrollerna i SwiftUI också är behållare.
Att bara stapla kontroller är inte tillräckligt för ett bra användargränssnitt. Dina textkontroller måste ha ett teckensnitt och en färg. Dina skärmar behöver en bakgrundsfärg. Dina knappar behöver utfyllnader. Tabellraderna behöver avstånd. Dina bilder kan behöva en hörnradie. Och kanske vill du ha skuggor eller till och med animationer!
Hur gör man detta på ett enkelt SwiftUI-sätt? Svaret är...
Enkelt uttryckt skapar en view modifier en ny modifierad vy från en befintlig vy. View-modifierare är extremt kraftfulla och du kan skriva hur många som helst utan att oroa dig för prestandan eftersom SwiftUI kollapsar dem bakom kulisserna på ett effektivt sätt.
Du kan också kedja ihop dem. Här är ett exempel:
HStack {
Image("Image")
.frame(width: 44)
.padding(10)
Text("Some text")
.font(Font.custom("System", size: 10))
.foregroundColor(.black)
}
.padding(.horizontal, 10)
.padding(.vertical, 5)
.frame(height: 60)
.background(.primary)
.cornerRadius(10)View-modifierare är lätta och optimerade, eftersom deras lagring av egenskaper distribueras genom vyhierarkin, i stället för att alla egenskaper ärvs av varje enskild vy, vilket är fallet vid vanligt klassarv.
Ordningen på vymodifierarna är viktig, eftersom var och en av dem påverkar den resulterande vy som har skapats av alla de tillämpade modifierarna ovan. Naturligtvis kan du också skapa och återanvända egna vymodifierare:
VStack {
. . .
}
.modifier(MyCustomModifier())
Alla dessa mekanismer tillsammans gör att det finns en enkel regel att följa: Du bör föredra små vyer med ett enda syfte! Skapa sedan större, mer komplexa vyer med hjälp av komposition. Hela poängen är att komponera små bitar för att skapa en större vy.
Här är ett exempel på en enkel anpassad vy som representerar en chattcell. Den här vyn innehåller en bildkontroll som visar användarens avatar, en textkontroll som visar deras senaste meddelande och cirkulära indikatorer för deras onlinestatus och om meddelandet lästes eller inte. På vänster sida kan vi se hur detta ser ut i SwiftUI-kod, och på höger sida kan vi se våra celler i aktion via XCode-förhandsvisningar, där varje förhandsvisningscell innehåller olika indata.
Som du kan se i exemplet gör SwiftUI ViewBuilder-syntaxen att du enkelt kan använda villkor i din deklarativa kod, och det hela känns väldigt naturligt. Du bör skjuta in dina villkor i vymodifierare så mycket som möjligt för att få bästa resultat.
SwiftUI är ett nytt ramverk, och även med alla fördelar som det ger är UIKit "storebror" för iOS-utveckling, och det kommer inte att försvinna när som helst snart. Även om SwiftUI får nya funktioner snabbt kommer du säkert att komma till en punkt där du inte kan skapa något i SwiftUI, vilket du kunde uppnå i UIKit.
Är detta en show-stopper? Nej, det är det inte alls! Du kan bädda in UIKit-vyer inuti SwiftUI-vyhierarkin genom att använda ett protokoll som kallas a UIViewRepresentabel. Genom att använda detta protokoll kan du skapa UIKit-vyer vars skapande- och uppdateringsprocesser är parallella med SwiftUI-vyernas.
Nu när vi har en mycket tydligare bild av SwiftUI och några av de fördelar som det introducerade, låt oss svara på resten av de frågor som ställdes i början av artikeln.
Jag har använt SwiftUI professionellt i ungefär ett år nu, och ja, den app jag arbetar med är live på AppStore. Så i det avseendet kan jag säga att SwiftUI verkligen kan användas i en produktionsapp.
Vi byggde dock appen helt från grunden i SwiftUI, så det handlade inte om en migrering från gammal UIKit-kod. Det var ett djärvt och riskfyllt beslut att go med SwiftUI i ett nytt projekt när ramverket fortfarande var i sin linda, men idag kan jag med säkerhet säga att det lönade sig fullt ut. Användningen av SwiftUI ökade vår utvecklingshastighet enormt och idag är projektet i ett mycket gott skick. Det fanns dock några nackdelar:
UIViewRepresentabel.LazyVStack inuti en ScrollView för att visa långa listor, kommer du att stöta på en del allvarliga skakningar. Detta kan undvikas genom att använda Lista kontroll istället, men det är långt ifrån perfekt, och det är upp till Apple att åtgärda problemet i nästa SwiftUI-release.LazyVGrid, ProgressView och ScrollViewLäsare.Slutsatsen är att vi lyckades lösa alla problem vi ställdes inför, och med tiden kommer Apple att tillhandahålla ett bättre och stabilare ramverk som kommer att göra apputvecklingen enklare och roligare.
SwiftUI kommer utan tvekan att bli framtidens utveckling för alla Apples plattformar och du bör definitivt sätta igång och lära dig det. Det kommer dock att ta lång tid att få den adoption som UIKit för närvarande har. Sanningen är att UIKit är ett moget ramverk som har utvecklats, testats grundligt och kontinuerligt förbättrats under lång tid.
Så det är bäst att inte tänka på SwiftUI som en ersättning, utan mer som ett välkommet tillägg som kan göra vårt liv enklare. Och om du försöker få ett jobb som iOS-utvecklare är UIKit-kunskap absolut obligatorisk eftersom det är vad befintliga kodbaser använder.
Det är svårt att ge ett entydigt svar på den här frågan. Om du planerar att starta ett helt nytt iOS-projekt, så ska du absolut go för det och börja med SwiftUI – du kommer inte att ångra dig.
Men om du redan har en stor kodbas som är byggd med UIKit kommer det förmodligen inte att vara en enkel uppgift att migrera. Visst, i SwiftUI kan du hitta matchande UI-kontroller till de flesta av deras UIKit-motsvarigheter, men den verkliga svårigheten ligger i det faktum att du ska byta från ett imperativt kodningsparadigm till ett helt annat deklarativt, så svårigheten med denna uppgift beror till stor del på storleken och komplexiteten i ditt projekt. Sammantaget skulle jag starkt föreslå att du åtminstone överväger bytet och börjar med att ersätta enskilda vyer i din app med SwiftUI.
Ett annat möjligt tillvägagångssätt är att använda SwiftUI endast för de nya funktionerna i din app. Detta är möjligt även om du inte släpper iOS-versioner under 12, eftersom du fortfarande kan använda tillgänglighets-API: erna för att skriva vyer som endast är tillgängliga på iOS-versionerna som stöder SwiftUI. Detta kommer att göra din kod framtidssäker och du behöver inte skriva om den om några år.
I den här artikeln har vi bara skrapat på ytan av SwiftUI och svarat på några av de vanligaste frågorna i samband med det. Det finns många fler viktiga ämnen som du bör kolla in om du är intresserad av SwiftUI-utveckling, till exempel animationer, navigering, tillståndshantering, designmönster och MVVM.
Här är några användbara artiklar som du kan kolla in för att få lite mer insikt:
➡️ SwiftUI - Så här skapar du ett projekt