Alamofire vs URLSession: võrdlus Swifti võrgustike loomiseks

Alamofire ja URLSession aitavad teil Swiftis võrgutaotlusi esitada. URLSession API on osa alusraamistikust, samas kui Alamofire tuleb lisada välise sõltuvusena. Paljud arendajad kahtlevad, kas on vaja lisada lisasõltuvus millestki põhilisest, näiteks Swifti võrgundus. Lõpuks on võrgutasandi rakendamine suurepäraste URLSession API-de abil, mis on tänapäeval saadaval.

See ajaveebi postitus on siin, et võrrelda mõlemat raamistikku ja teada saada, millal lisada Alamofire välise sõltuvusena.

See näitab Alamofire tegelikku jõudu, kuna raamistik teeb palju asju lihtsamaks.

Mis on Alamofire?

Kui URLSession on leitav sihtasutuse standardses raamistikus, peame Alamofire'i leidmiseks minema Githubisse. See on avatud lähtekoodiga raamistik ja kuulub Alamofire Tarkvara Sihtasutusele. Raamistik on väga populaarne, kuna selle ajaveebi postituse kirjutamise hetkeseisu statistika kohta saate lugeda:

  • 164 kaastöötajat
  • 30K + tärni
  • 42 miljonit (!!) allalaadimist vastavalt CocoaPodsi statistikale ja 600K + rakendusele, mis seda kasutavad

Need statistid muudavad selle üheks populaarseimaks saadaval olevaks Swifti raamistikuks. See on hästi hooldatud, sageli kasutatav raamistik, mis peaks hõlbustama võrkude loomist oma rakendustesse.

Alamofire on oma nime saanud Alamo Fire lille järgi, mis on Texase ametliku osariigi lille Bluebonnet hübriidvariant.

Alamofire ja URLSession võrreldud

Olen oma Twitteri jälgijatelt küsinud, mida nad eelistavad kasutada: Alamofire või URLSession.

Selgub, et arendajad, kes eelistavad kasutada Alamofire'i või URLSessioni, on selgelt lahus. Siinkohal on suur küsimus, kas nad eelistavad seda ainult ise või kas nad valivad ka valitud raamistiku.

Alamofire'i reklaamitakse kui “Elegantset võrgundust Swiftis”, mis annab selle kavatsuse juba natuke ära. See on URLSessioni peal olev kiht eesmärgiga muuta ühised võrgufunktsioonid hõlpsamini rakendatavaks.

Funktsioonid, mida on Alamofire abil lihtsam rakendada

Alamofire sisaldab palju lisaloogikat peale võrgustaotluse loomise lihtsalt. Need funktsioonid võivad midagi muuta ja võivad teie enda loomisega võrreldes mõnikord palju aega kokku hoida.

Nende hoidla lugemisfunktsioonis reklaamitavate funktsioonide loetelu on pikk, millest ainult vähesed lisavad tõesti ainulaadset lisaväärtust:

  • Sertifikaadi kinnitamine. Selle välja sorteerimine ja ise üles ehitamine võib võtta veidi aega.
  • Taotleb uuesti proovimist. Kui päring ebaõnnestub näiteks autentimisvea tõttu, saate autentimisloki hõlpsalt värskendada ja sama päringu uuesti käivitada, ilma et peaksite rakenduskoodi puutuma.

Lisaks neile funktsioonidele on taotluste koostamise süntaks palju elegantsem ja hõlpsamini kasutatav. See säästab teid lisakoodide hulgast ja muudab valideerimise ja vigade käsitlemise palju lihtsamaks.

Sageli peetakse eeliseks võrgu juurdepääsetavuse haldurit. Kuid alates iOS 12-st saame kasutada ka uut NWPathMonitor API-d.

Võrgutaotluse loomine võrreldud

Ütleme nii, et meil on API, mis võimaldab meil luua uue tahvli pealkirjaga “New York Highlights”. Selle jaoks on Alamofire'i koodi kasutamine väga lihtne:

AF.request ("https://api.mywebserver.com/v1/board", meetod: .get, parameetrid: ["pealkiri": "New York Highlights"])
    .valideeri (olekukood: 200 .. <300)
    .responseDecodable {(vastus: DataResponse)
        vaheta vastust.tulemus {
        juhtum. edu (lase juhatusel):
            print ("Loodud tahvli pealkiri on \ (board.title)") // New York Highlights
        juhtum. rike (lase viga):
            print ("Tahvli loomine nurjus tõrkega: \ (error.localizedDescription)")
        }
}

Täpselt sama toimimine URLSession API-ga nõuab natuke rohkem tööd.

enum Viga: Swift.Error {
    juhtumi päring ebaõnnestus
}

// Koostage URL
var components = URLComponents (string: "https://api.mywebserver.com/v1/board")!
components.queryItems = ["pealkiri": "New Yorgi kõrghetked"]. kaart {(võti, väärtus)
    URLQueryItem (nimi: võti, väärtus: väärtus)
}

// Genereerige ja täitke taotlus
lase päring = proovi! URLRequest (URL: komponendid.url !, meetod: .get)
URLSession.shared.dataTask (koos: päringuga) {(andmed, vastus, viga)
    tee {
        valvur lase andmed = andmed,
            las vastus = vastus kui? HTTPURL vastus, (200 .. <300) ~ = response.statusCode,
            viga == pole veel ühtegi {
            // Andmeid polnud, valideerimine nurjus või ilmnes viga.
            viska viga ?? Error.requestFailed
        }
        lase pardal = proovida JSONDecoder (). dekodeerida (Board. Self, alates: andmed)
        print ("Loodud tahvli pealkiri on \ (board.title)") // New York Highlights
    } saagi {
        print ("Tahvli loomine nurjus tõrkega: \ (error.localizedDescription)")
    }
}

See näitab Alamofire tegelikku jõudu, kuna raamistik teeb palju asju lihtsamaks:

  • Taotlus luuakse ühe initsiaatori sees
  • URL-kodeerija kodeerib parameetreid vaikimisi
  • Valideerimine toimub lihtsa ühevooderdisega ja muudab valideerimise ebaõnnestumisel tugevalt trükitud veaks. Vastustulemus enum tagastab selle tõrke juhtumi sees.
  • Üldine lõpetamise tagasihelistamine hõlbustab vastuse dekodeerimist meie kohandatud tahvlitüüpi

Ainult see võib juba olla põhjus, miks valida Alamofire'i ja muuta teie elu lihtsamaks. URLSessioni kasutamisega valmistate tõenäoliselt oma ümbrise, mis nõuab hooldamist ja testimist. Alguses võib see tunduda parem sõltuvus võrreldes uue sõltuvuse lisamisega, kuid projektide arenedes võib kergesti juhtuda, et teie enda võrgukiht areneb ja muutub keerukamaks.

Kui halb oleks lisada Alamofire sõltuvusena?

Teeme selgeks, et projektile välise sõltuvuse lisamisel peate olema ettevaatlik. Kui seda ei hooldata, testitud või kasutatakse palju, võib see teie projektile lisada võimaliku riski. Lõpuks peate võib-olla ise arendamist jätkama.

Alamofire'i puhul ei pea te selle pärast tegelikult muretsema. Raamistik on hästi hooldatud, testitud ja kasutatav. Raamistik on üsna väike ja muudab võrgutaotluste kirjutamise elegantsemaks.

Järeldus: kuidas otsust teha?

Alamforet võrreldakse sageli AFNetworkinguga, mis on Objective-C samaväärne võrgustike loomise raamistik. Sel ajal oli võrgu loomine palju raskem ilma URLsession API-ta, mis eksisteerib alles iOS 7-st alates. Seetõttu oli oma elu natuke lihtsamaks muutmiseks ilmselgem valida selline raamistik nagu AFNetworking.

Tänapäeval on olemasolevaid URLSession API-sid vaadates võrgutaotluste koostamine palju lihtsam. See aga viib teid tõenäoliselt URLSessioni kohale oma võrgukihi loomise poole. Seda kihti tuleb katsetada ja see võib projekti arenedes kasvada keerukamaks.

Seda silmas pidades, võttes arvesse asjaolu, et Alamofire on hästi hooldatud ja paljudes projektides kasutatud, säästate arvatavasti palju vaeva ja aega, lisades sõltuvusena Alamofire'i.

Selles blogipostituses võrreldakse URLSessioni Alamofire 5-ga, mis on kirjutamise hetkel beetaversioonis. Lisateavet selle väljalase kohta saate lugeda siit.

Algselt avaldati SwiftLee-s.

Rohkem postitusi ja värskendusi: @twannl