I Swift kan vi hantera funktionalitet som beror på operativsystemets version genom att använda tillgänglighets- och otillgänglighetsattribut. Dessa attribut gör det möjligt att köra specifik kod beroende på vilken version av plattformen användaren kör. Till exempel, om vi vill att vår applikation ska fungera både på den senaste versionen av iOS och på tidigare versioner, kan vi använda olika mekanismer för att kontrollera detta.

Innan Swift introducerade otillgänglighetsattributet, använde vi kod som denna:

swift
Copy code
if #available(iOS 16, *) {

    // Funktionalitet för nyare versioner
} else {
    // Funktionalitet för iOS 15 och tidigare
}

Denna kod användes för att säkerställa att funktionaliteten i vår applikation skulle fungera på äldre versioner av operativsystemet. Med otillgänglighetsattributet kan vi dock skriva koden på ett mer läsbart sätt:

swift
Copy code
if #unavailable(iOS 16) {
    // Funktionalitet för iOS 15 och tidigare
}

En viktig skillnad mellan tillgänglighets- och otillgänglighetsattributen är att plattformen wildcard * inte är tillåtet med otillgänglighetsattributet. Syftet med detta är att undvika osäkerhet om vilka plattformar som ska betraktas som otillgängliga. Otillgänglighetsattributet kontrollerar endast de specifika plattformar som anges i listan. Här är ett exempel på hur vi kan använda otillgänglighetsattributet för flera plattformar:

swift
Copy code
if #unavailable(iOS 16, watchOS 9) {

    // Funktionalitet för iOS 15, watchOS 8 och tidigare
}

Med hjälp av otillgänglighetsattributet blir koden både mer läsbar och lättare att underhålla, särskilt när det handlar om plattformsspecifik logik. Denna mekanism förenklar också felsökning och gör det lättare att förstå var och varför viss funktionalitet är otillgänglig.

Utöver de grundläggande funktionerna i Swift för att hantera tillgänglighet och otillgänglighet, finns det flera viktiga aspekter att överväga. För det första, även om attributet #unavailable gör koden mer elegant, är det avgörande att vara noga med vilka versioner och plattformar som stöds och varför. I vissa fall kan det vara mer lämpligt att använda #available om vi behöver specifika funktioner från nyare versioner, medan #unavailable bör användas när en äldre version inte längre stöds. Det är också viktigt att överväga hur vi kommunicerar för dessa versioner till användaren, särskilt om en viss funktionalitet är otillgänglig.

Dessutom kan det vara bra att tänka på hur man hanterar fallback-lösningar när äldre plattformar inte har vissa funktioner. Här är det ofta nödvändigt att utveckla alternativa lösningar som erbjuder liknande funktionalitet, även om den inte är exakt densamma. Denna strategi kan hjälpa till att skapa en bättre användarupplevelse, särskilt när användare på äldre system förväntar sig en smidig och fungerande app trots tekniska begränsningar.

Hur skapar man och använder anpassade subscript i Swift?

I Swift används subscripts för att ge snabb åtkomst till element i samlingstyper som arrayer, ordböcker och andra typer som vi själva definierar. Subscripts är ett kraftfullt verktyg som tillåter oss att läsa och skriva till objekt på ett flexibelt sätt, vilket gör dem användbara när vi vill dölja detaljer om hur data lagras eller när vi vill tillåta en mer intuitiv syntax för användare av våra typer.

För att lägga till ett element i slutet av en array eller för att få antalet objekt i en array, kan vi använda funktioner eller egenskaper, som i följande exempel:

swift
Copy code
arrayOne.append(7)  // Lägger till 7 i slutet av arrayen

arrayOne.count  // Returnerar antalet objekt i arrayen

När vi skapar anpassade typer i Swift kan vi använda subscripts för att arbeta med interna datalager som en array eller en ordbok utan att exponera lagringsmetoden för externa användare. På detta sätt kan vi göra våra objekt mer flexibla och enklare att förändra utan att påverka den externa koden. Här är ett exempel på hur man skapar en subscript för att läsa och skriva till ett backend-array:

swift
Copy code
class MyNames {

    private var names = ["Jon", "Kailey", "Kai"]
    subscript(index: Int) -> String {
        get {
            return names[index]
        }
        set {
            names[index] = newValue
        }
    }
}

I detta exempel har vi en klass MyNames som har en intern array, och genom att använda en subscript kan vi läsa och skriva till denna array utan att behöva exponera den direkt. På så sätt förhindras användare av klassen att få åtkomst till arrayen direkt, vilket gör det enklare att byta lagringsmetod i framtiden (t.ex. från en array till en ordbok eller en databas). Dessutom gör subscripts det möjligt att lägga till validering av indata innan de sätts in i den interna strukturen, vilket säkerställer att data hålls korrekt.

För att skapa en instans av MyNames och använda subscripten kan vi göra så här:

swift
Copy code
let name = MyNames()

print(name[0])  // Visar 'Jon'
name[0] = "Kailey"
print(name[0])  // Visar 'Kailey'

I detta exempel ändrar vi värdet vid index 0 i arrayen. Istället för att ge direkt åtkomst till arrayen, kan vi genom subscripten utföra operationer på data och samtidigt dölja hur den lagras.

Läs- och skrivbara subscripts

En subscript i Swift kan vara både läs- och skrivbar, beroende på om vi deklarerar en setter eller ej. Om vi inte vill tillåta externa användare att ändra ett värde, kan vi skapa en read-only subscript. Här är ett exempel på en sådan subscript:

swift
Copy code
subscript(index: Int) -> String {
    return names[index]
}

I det här fallet behöver vi inte deklarera någon getter eller setter, eftersom Swift automatiskt gör subscripten read-only. Vi kan också uttryckligen deklarera en getter för att skapa en läsbar subscript:

swift
Copy code
subscript(index: Int) -> String {

    get {
        return names[index]
    }
}

I båda fallen är subscripten läsbar, men inte skrivbar. Det är viktigt att förstå att Swift inte tillåter write-only subscripts, så om du vill att en subscript bara ska vara skrivbar, kan du helt enkelt inte definiera en getter.

Beräknade subscripts

Förutom att bara returnera lagrade värden, kan subscripts också användas på liknande sätt som beräknade egenskaper. Här är ett exempel där vi använder en subscript för att beräkna ett värde:

swift
Copy code
struct MathTable {
    var num: Int
    subscript(index: Int) -> Int {
        return num * index
    }
}

I detta exempel använder vi en subscript för att multiplicera ett tal (num) med indexet som anges vid anrop. Här är hur man använder den:

swift
Copy code
var mathTable = MathTable(num: 5)

print(mathTable[4])  // Visar 20

Detta är ett exempel på en beräknad subscript, där värdet inte hämtas från någon datalager, utan snarare beräknas dynamiskt baserat på en annan parameter.

Användning av String som subscript-värde

Subscripts behöver inte alltid använda hela datatyper som Int; vi kan också använda andra typer, som String, som både input och output för subscripten. Här är ett exempel:

swift
Copy code
struct Hello {
    subscript(name: String) -> String {
        return "Hello \(name)"
    }
}

Användningen är enkel, och resultatet ger ett meddelande baserat på inmatningen:

swift
Copy code
var hello = Hello()

let greeting = hello["Jon"]
print(greeting)  // Visar "Hello Jon"

Statiska subscripts

Liksom statiska egenskaper och metoder, kan subscripts också vara statiska. Detta innebär att vi kan använda subscripten utan att skapa en instans av typen. Här är ett exempel på en statisk subscript:

swift
Copy code
struct Hello {

    static subscript(name: String) -> String {

        return "Hello \(name)"
    }
}

Här kan vi använda subscript utan att skapa ett objekt av Hello:

swift
Copy code
let greeting = Hello["Jon"]
print(greeting)  // Visar "Hello Jon"

Externa namn för subscripts

swift
Copy code
struct MathTable {
    var num: Int

    subscript(multiply index: Int) -> Int {

        return num * index
    }
    subscript(add index: Int) -> Int {
        return num + index
    }
}

Med dessa externa namn, kan vi nu välja vilken subscript som ska användas beroende på vad vi vill göra (multiplicera eller addera).

Hur man använder #expect(processExitsWith:) och andra byggblock i Swift Testing

I Swift Testing kan vi använda makrot #expect(processExitsWith:) för att köra kod i en dedikerad subprocess. Detta isolerar den från huvudtestaren och möjliggör att vi kan bedöma hur processen avslutas. När vi använder detta makro kan vi specificera att processen ska avslutas antingen med .success (normal avslutning) eller .failure (krasch eller assertion-fel). För att detta ska fungera måste testfunktionen vara markerad som asynkron, och #expect-blocket måste vänta på resultatet. Detta gör det möjligt för testet att suspendera sig själv medan Swift lanserar och övervakar subprocessen i bakgrunden.

För att förstå hur detta fungerar kan vi titta på ett exempel där vi testar en division med noll. Här definieras två heltal, där nämnaren är ett slumpmässigt tal mellan 0 och 1. En precondition säkerställer att division med noll inte är tillåten. Om denna förutsättning misslyckas, kommer Swift att utlösa ett "trap"-fel som normalt skulle krascha testköraren. Genom att använda #expect(processExitsWith: .failure) kan Swift nu köra koden i en subprocess och bekräfta att det verkligen misslyckas på det förväntade sättet. Om förutsättningen tas bort eller ändras så att divisionen genomförs, kommer testet att misslyckas, men inte på grund av en krasch utan eftersom processen inte avslutades med den förväntade "failure"-statusen.

Det finns några viktiga saker att tänka på när man använder exit-tester:

• Endast ett #expect(processExitsWith:) anrop är tillåtet per test.

• Subprocesser delar inte tillstånd med huvudtestaren – globala variabler, mocks eller sidoeffekter påverkar inte varandra.

• Tester som förväntar sig krascher måste alltid använda await, eftersom subprocesshantering är asynkron.

När vi har förstått hur exit-tester fungerar, kan vi gå vidare till nästa byggblock i Swift Testing: Traits.

En annan användbar funktion är att traits kan användas för att organisera våra tester genom att tilldela taggar. Taggar gör det enklare att filtrera och köra specifika tester i Xcode, vilket förenklar testhantering. Dessutom förenklar de skapandet av parameteriserade tester, där samma test kan köras flera gånger med olika parametrar. Argumenten kan definieras utanför testet, så att varje test som körs visas i Xcode sidofält och ger möjlighet att köra testerna med specifika argument vid behov.

Här är några exempel på hur traits kan användas:

swift
Copy code
@Test(.bug("FML1234", "A Bug")) // Problem i buggrapporten
@Test(.tag(.critical)) // Anpassad tagg
@Test(.enabled(if: required.isTrue)) // Villkorsstyrd aktivering
@Test(.disabled("Test Broken")) // Oaktiverat test
@Test(.timeLimit(.minutes(2))) // Tidsbegränsning för test

När vi nu har sett hur traits används, kan vi gå vidare till nästa byggblock, nämligen testsviter.

Här är exempel på hur man definierar sviter:

swift
Copy code
struct Project_Test {
    @Test func myTest() {
        // Testkod här
    }
}

@Suite("Suite Example") struct Project_Test {

    @Test func myTest() {
        // Testkod här
    }
}

Båda exemplen är sviter eftersom varje struktur som innehåller @Test-funktioner automatiskt betraktas som en svit.

För att bättre förstå användningen av Swift Testing kan vi titta på ett praktiskt exempel: att skapa en räknarapp. Vid skapandet av ett nytt projekt med Swift Testing genereras även UI-tester med XCTest. En enkel räknare är ett bra exempel för att demonstrera testkoncept eftersom det involverar grundläggande aritmetiska operationer som lätt kan verifieras med grundläggande tester.

I vårt exempel skapar vi en räknareapp där backend-koden för räknaren definieras i en struktur:

swift
Copy code
struct Calculator {

    static func add(_ one: Double, _ two: Double) -> Double {
        one + two
    }

    static func subtract(_ one: Double, _ two: Double) -> Double {

        one - two
    }
    static func multiply(_ one: Double, _ two: Double) -> Double {
        one * two
    }

    static func divide(_ one: Double, _ two: Double) -> Double {

        one / two
    }
}

När vi skapar räknarenappen med Swift Testing genereras tre moduler: en för själva applikationen, en för enhetstester och en för UI-tester. För att enhetstesterna ska kunna komma åt den interna koden i appens modul, används @testable-attributet, vilket gör att enhetstester kan få åtkomst till interna komponenter i applikationen som normalt inte skulle vara synliga utanför modulen.

För att möjliggöra detta måste vi aktivera testbarhetsinställningen genom att sätta "Enable Testability" till "Yes" för applikationens mål i Xcode.

Hur protokoll och deras sammansättning skapar flexibel och återanvändbar kod i protokollorienterad programmering

Protokollorienterad programmering är en kraftfull metod för att bygga flexibla och modulära system där huvudfokus ligger på användning av protokoll för att definiera metoder, egenskaper och krav för typer. Denna metod främjar återanvändning av komponenter och gör det möjligt att bygga komplex funktionalitet genom att kombinera små, specifika protokoll. En av de mest användbara funktionerna i protokollorienterad design är protokollkomposition, där en typ kan konformera sig till flera protokoll och på så sätt ärva krav och beteenden från varje.

swift
Copy code
for (_, vehicle) in vehicles.enumerated() where vehicle is LandVehicle {
    let vh = vehicle as? LandVehicle
    if vh?.landAttack == true {
        vh?.doLandAttack()
    }
    if vh?.landMovement == true {
        vh?.doLandMovement()
    }
}

Protokollärvning och sammansättning är grundläggande för att skapa högkvalitativ och lättunderhållen kod. Protokollärvning gör det möjligt för ett protokoll att ärva krav från andra protokoll. Till skillnad från klassarv, där en klass bara kan ärva från en annan klass, tillåter protokollärvning att ett protokoll ärver från flera andra protokoll, vilket leder till en flexibel och modulär struktur. Genom att använda protokollförlängningar kan vi också ge standardimplementeringar för metoder och egenskaper som definieras av ett protokoll, vilket minskar behovet av upprepning av kod och gör det lättare att underhålla.

Protokollkomposition är en annan viktig aspekt av protokollorienterad design. Genom att använda komposition kan vi skapa en typ som konformerar till flera protokoll och på så sätt sammansätta deras krav i ett gemensamt gränssnitt. Detta är särskilt användbart när vi har små, specialiserade protokoll som vi vill kombinera för att bygga mer komplexa strukturer utan att behöva skapa stora, tunga klasser. Ett exempel på detta kan ses när vi definierar två protokoll, Nameable och Contactable, som används för att definiera namn och kontaktinformation för en person:

swift
Copy code
protocol Nameable {
    var firstName: String { get }
    var middleName: String? { get }
    var lastName: String { get }
}
protocol Contactable {
    var emailAddress: String { get }
    var phoneNumber: String { get }
}

Dessa protokoll kan sedan användas som bas för att skapa ett Person-protokoll som ärver deras krav:

swift
Copy code
protocol Person: Nameable, Contactable {

    var birthDate: Date { get }
    var age: Int { get }
    func displayInfo()
}

Genom att skapa små och fokuserade protokoll som dessa kan vi bygga en modulär uppsättning komponenter som kan återanvändas på olika sätt. Vi kan exempelvis skapa ett Pet-protokoll som återanvänder Nameable för att definiera egenskaper för djur:

swift
Copy code
protocol Pet: Nameable {
    var numberOfLegs: Int { get }
}

swift
Copy code
extension Person {
    var age: Int {
        let now = Calendar.current
        let components = now.dateComponents([.year], from: birthDate, to: Date())
        return components.year ?? 0
    }
}

Denna metod innebär att alla typer som konformerar till Person (eller ett protokoll som ärver från Person) automatiskt får denna funktionalitet utan att behöva skriva om koden.