Share
Denne artikkelen er en utforskning av webtjenesteprotokoller, vanlige datautvekslingsformater og beste praksis. Hvis du er interessert i å skape ypperlige mobile applikasjoner som kobler til nettet, les videre!
Å velge et riktig protokoll- og datautvekslingsformat for å sende data mellom mobilappen og nettverket er en av de viktigste beslutningene å gjøre under utviklingsprosessen. De vanligste og mest brukte protokollene er REST, XML-RPC og SOAP.
Alle disse protokollene transporterer data over HTTP-protokollen. XML-RPC- og SOAP-protokollene er XML-baserte, mens REST-tjenester kan stole på forskjellige dataformater, de to vanligste egenskapene XML og JSON. Spesielt SOAP er verdsatt og vedtatt av bedriftsapplikasjoner fordi det strengt håndhever datamodeller, og det beskriver offentlige grensesnitt gjennom WSDL, noe som gjør det mulig å lage noen utviklingsverktøy (for eksempel Microsoft Visual Studio for .NET) automatisk opprette objekter og metoder for å konsumere tjenestene bare ved å legge til en referanse til tjenesten WSDL til prosjektet.
XML er imidlertid by-design mindre effektiv enn JSON når den opererer i et begrenset nettverksscenario som båndbredde som mobil utvikling. Mobil datanettverk (WWAN) er vanligvis mindre pålitelige enn kablede (LAN) eller trådløse (WLAN) nettverk, fordi klienter på reise kan enkelt slippe inn og ut av dekningsområder. Enkelte brukere abonnerer heller ikke på "flate" dataplaner og belastes faktisk av nettverkstrafikk.
Så mens du utvikler for mobil, bør du alltid velge enkelhet og trafikkreduksjon.
La oss sammenligne vanlig XML til JSON med et eksempelrespons:
XML
Hei, enhet!
JSON
returnValue: "Hei, enhet!"
Som du kan se, JSON har en mindre nyttelast fordi det bare trenger å vikle dataene sine med parentes (krøllete for objekter, firkant for arrays) og anførselstegn, mens XML trenger en full rotnode og åpningsavslutningstegn for hvert element eller gruppe. Lagring på disse kodene kan redusere responsbelastningen betydelig, og jo flere data du overfører, desto større vil nyttelasten "padding" være med XML.
Dessuten krever SOAP og XML-RPC mer komplekse XML-datastrukturer (som SOAP "konvolutt"), og legger ekstra vekt på nyttelasten.
Av denne grunn anbefaler jeg at du velger JSON for appens datautvekslingsformat og HVILE for overføringsprotokollen, med mindre XML, SOAP eller XML-RPC er eksplisitt kreves for dine behov. Skulle du trenge å håndheve en datamodell, kan du oppnå det med JSON også ved å bruke JSON Schema eller WSDL 2.0.
For referanser og videre lesning om de diskuterte protokollene og dataformatene, sjekk ut følgende:
Siden de fleste webtjenester opererer over offentlige nettverk, er det et av de mest kritiske problemene du må ta opp å beskytte dataene som skal utveksles mellom tjenestene og appen. Mange webtjenester gir ekstern funksjonalitet til godkjente brukere, så private brukerdata og autentiseringsinformasjon må overføres over nettverket også.
Personlige data, kontodata og legitimasjon skal aldri reise i klartextform over et offentlig nettverk, så dette betyr at webtjenesten og appene skal implementere kryptering. Den gode nyheten er at de fleste vanlige protokoller transporterer data over HTTP, slik at du kan stole på velkjent, klarert og robust HTTP SSL / TLS-protokoll (HTTPS) som har omfattende støtte både på server side og på klientsiden.
Aktivering av SSL på vanlige webservere er ganske enkelt (det er mange nyttige ressurser for Apache, IIS og Nginx). Alt du trenger å gjøre er å kjøpe et SSL-sertifikat og sette det opp på serveren din. I en I verste fall, Du kan også utstede et selvsignert sertifikat som gir deg gratis kryptering, men jeg vil ikke anbefaler å gjøre det. Noen CA'er utsteder billige sertifikater, og fordelene du får ved å jobbe med et klarert, signert sertifikat, er verdt ekstrakostnaden (dvs. hindre man-i-midterangrep ved å bruke PKI). Bruk av selvsignerte sertifikater kan også kreve ekstra koding eller til og med programspesifikke "hacks", siden noen nettverksbiblioteker vil nekte usikre HTTPS-tilkoblinger (sjekk disse artiklene om Android, # 1 og # 2 og om iOS).
Aktivering av SSL på klientsiden er en no-brainer: Vanlige programmeringsspråk har vanligvis HTTP-klasser og biblioteker som gir opprinnelig HTTP-SSL-støtte og vil "automatisk" ta seg av kryptering bare ved å bruke "https: //" nettadresser i stedet for "http : // "Nettadresser for å forbruke webtjenester.
Hvis du velger et lavpris SSL-sertifikat, må du bare forsikre deg om at enhetene og operativsystemene du vil utvikle, har utstederens CA-rot sertifikat buntet ut i boksen, ellers vil de ikke stole på sertifikatet.
Du bør aldri be brukerne å lappere, endre eller hacke sine systemer for å kjøre appene dine, og hvis du gjør det, ikke forvent at mange av dem skal overholde dem..Web Services-transaksjoner er ment å være atomisk, interoper og skalerbar, så webtjenester er vanligvis statsløs (sjekk denne interessante diskusjonen om betydningen av "statsløse" forbindelser).
Mange webtjenester gir brukerrelatert funksjonalitet og tilgang til sensitiv informasjon. Naturligvis krever det autentisering. Fordi slike transaksjoner er statsløse, behøvde du tradisjonelt å signere forespørsler med en brukerspesifikk nøkkel, som gir godkjenning med hver ekstern metallsamtale. Selv når data over HTTPS overføres, er brukerens legitimasjon mest utsatt når de overføres via et offentlig nettverk. Kryptering er noen ganger ødelagt.
Dette dilemmaet er hvor tokenbasert autentisering som OAuth kommer til nytte. Ved hjelp av tokenbasert autentisering må du bare sende en brukerens legitimasjonsinformasjon en gang. Hvis brukeren er godkjent, vil de bli forsynt med tokens som kan brukes til å godkjenne påfølgende eksterne metallsamtaler.
En tokenes gyldighet spenner over en begrenset levetid og kan tilbakekalles når som helst av utstederen (dvs. server-side). Med tokenbasert autentisering kan du også dele de samme brukeridentifikasjonene mellom forskjellige programmer og tjenester uten at de koblede tjenestene / appene noensinne har kjennskap til de riktige brukerens legitimasjon. Videre holder denne autentiseringsmetoden sikkert en lokal cache for legitimasjonene på brukerens enhet, slik at brukeren kan bli "husket" og ikke trenger å autentisere hver gang han vil bruke appen (skrive komplekse passord på håndholdte kan være en ekte smerte og kan dårlig skade app vurderinger).
OAuth er det vanligste tokenbaserte auth-rammeverket, og det har blitt vedtatt av store spillere som Google, Twitter, Facebook og så videre. Ved å la brukerne bruke sine eksisterende kontoer igjen, hoppe over irriterende registreringsskjemaer og holde kontroll over tilgangen til deres personlige data, kan du øke brukerbasen din betydelig..
Noen OAuth-leverandører krever at deres egen SDK importeres i appene dine for å aktivere godkjenning, ellers er det mange ferdige OAuth-biblioteker rundt det du kan plugge inn i appen din. Det finnes også rammer som oauth-php tilgjengelig for å bygge tilpassede OAuth-leverandører.
Jeg vil foreslå skilting som et Android OAuth klient bibliotek og oauthconsumer for iOS.
Alle disse bibliotekene kommer med nyttige eksempler og er enkle å implementere. Men å bygge skiltkildene på maskinen din eller importere dem til appen din, kan være litt vondt, men du trenger ikke å gå gjennom prosessen. I stedet kan du bare importere JAR-binærene i prosjektet ditt, og du bør angis. På iOS, ville dette lignes på å importere et statisk bibliotek (* .a fil) til prosjektet ditt.
Den vanligste autentiseringsmetoden for SOAP-baserte tjenester er en SOAP-utvidelse kalt HTTP Basic Authentication (noen ganger kalt Digest Authentication). Dette er en standard, godt støttet prosedyre som er integrert i alle de vanligste webserverne som Apache, Nginx og IIS. Den er basert på et brukernavn-passordspar som må sendes til serveren via HTTP-overskrifter.
Normalt trenger du ikke å manuelt implementere grunnleggende auth i dine applikasjoner, da den også støttes bredt på de vanligste programmeringsspråket. .NET-rammen er avhengig av NetworkCredential-klassen for å levere grunnleggende og fordøye auth-referanser til HTTP-forespørsler, PHP støtter det gjennom cURL og Java gjennom Authenticator.
Skulle du måtte implementere Basic Auth selv, trenger du bare å legge til denne overskriften på dine forespørsler:
Grunnleggende brukernavn: passord
Verdiene "brukernavn" og "passord" må være base64-kodet.
Vær oppmerksom på det HTTP Basic Auth brukes best i kombinasjon med HTTPS-protokollen, som det overfører legitimasjon i klartekst form. Digest Auth er litt tryggere, fordi det faktisk har sperret passordverdien, men HTTPS anbefales likevel for å unngå hash bruteforce-angrep.
Flere detaljer og detaljer om dette emnet finnes i IETF RFC 2617-notatet.
Når du velger en godkjenningsmetode eller integrerer kjente tjenester (for eksempel sosiale nettverk), bør du også ta hensyn til de innfødte bibliotekene som er bygget inn i mange avanserte plattformer som iOS og Android. Dette kan spare mye tid og mange linjer med kode.
Android gir et fint rammeverk for sentralisering av brukerkontohåndtering, klassen AccountManager. Den offisielle Android Developer-guiden gir litt fin dokumentasjon for denne klassen, sammen med noen tips for å integrere OAuth 2 eller skrive din egen "Tilpasset kontotype".
Med iOS 6 har Apple introdusert en ny sosial ramme for å integrere store tjenester som Twitter, Facebook og Sina Weibo på et OS-nivå. Selv om du ikke trenger å integrere disse tjenestene i søknaden din, kan du finne en passende måte å dra nytte av de innebygde autentiseringsmetodene via tilpasning.
Når du utvikler for mobile applikasjoner, er det viktig å holde data nyttelastene så lave som mulig. Denne delen vil diskutere flere strategier for å gjøre det.
ZIP-komprimering kan redusere tekst og binær datavægt betydelig, og støttes godt på de fleste plattformer, så bruk det godt hvis du trenger å overføre store data via mobilnett. Nyttige biblioteker til å administrere ZIP-filer er tilgjengelige for Android (dvs. dekomprimere) og iOS (dvs. Ziparchive).
Hvis du trenger å streame lyd / videoinnhold til mobilappene dine, velger du avanserte streamingplattformer som tillater dem å skalere strømmer avhengig av nettverk / enhetens ytelse, som Apples HTTP Live Streaming (HLS) -protokoll. Ellers er favoriserende respons over mediekvalitet vanligvis et godt valg. Spill med forskjellige video- og lydkompressorer og innstillinger, og optimaliser så mye du kan. Du kan også gruppere enheter av type (småskjerm håndholdte, bredskjerm håndholdte og tabletter) og levere forskjellig innhold for hver type.
Mange mobile enheter har HD-skjermer, men er HD-innhold på små skjermer virkelig verdt ekstra båndbredde overhead? Vær ærlig om relevansen av mediekvaliteten i appene dine, og prøv å finne den beste balansen mellom kvalitet og vekt.
La oss anta at du skal kode en leserapp for en elektronisk avis. Først og fremst bør du alltid la brukerne operere frakoblet når det er mulig. Selv om enkelte apper alltid krever et aktivt nettverk (dvs. meldingstjenester), bør mange andre bare bruke nettverket til laste ned datapakker og lagre dem på enheten.
Dette vil forbedre programytelsen, lagre brukerens penger på ikke-flate mobildataplaner, og gjør appen nyttig når nettverket ikke er tilgjengelig (for eksempel under flyging).
Når du laster ned innhold på enheter som lagrer ekstern lagring (f.eks. Minnekort), bør du la brukerne velge hvor du skal lagre nedlastet innhold (dvs. internt eller eksternt lagringsplass) eller bare foretrekke ekstern lagring uansett. Entry level enheter har vanligvis ganske liten intern lagring og kan bli ustabile eller sakte når intern lagring er full. Hvis appene dine tar opp mye lagringsplass, vil de trolig bli avinstallert for å spare plass.
La oss gå tilbake til leserapps-eksemplet. Hver artikkel er et enkelt stykke, og selv om artikler kan kobles sammen, er det ingen grunn til at du ikke bør la brukerne begynne å lese artikler selv om ytterligere innhold fortsatt lastes ned. Så pakk hver artikels filer (tekst, bilder, vedlegg og media) i separate ZIP-arkiver og gi en webtjeneste metode for appen å hente liste over tilgjengelige artikler. Få appen din til å laste ned ZIP-pakker en etter en og gjør dem tilgjengelige i appen så snart hver enkelt er lastet ned og mens andre blir lastet ned i bakgrunnen. Dette er en god ytelse og forbedring av brukeropplevelsen i forhold til å vente til hele nyttelastet har lastet ned! Du kan også la brukerne velge hvilke pakker de vil laste ned eller ikke (slik at de kan spare plass, tid og trafikk) og tillate dem å fjerne enkeltpakker for å lagre lagringsplass uten å fjerne hele appen.
Følgende er et svar fra demo server-appen som følger med denne artikkelen:
apiversion: 1, status: 0, pakker: [file: "pack01_01_01.zip", pakke: "pack01", appversion: 1, revisjon: 1, file: "pack01_02_01.zip", pakke: "pack01" , appversion: 2, revisjon: 1, fil: "pack02_01_01.zip", pakke: "pack02", appversion: 1, revisjon: 1]
Husk at appen din og tidligere utgitt innhold kan utvikle seg over tid.
Gi et "revisjon" -flagg for hver pakke i listemetoden, dette vil være nyttig for å utgjøre oppdateringer, fikse feil i innholdet og implementere autoupdate-funksjonalitet i appene dine. Selv om du ikke planlegger å implementere automatisk oppdatering, tenk fremover og sett revisjonsflagget i listen uansett for fremtidig utvikling.
Du bør også inkludere et «app-versjon» -flagg i pakkelisten din. Skulle du utstede en ny stor utgivelse av appen din som gir deg bryte endringer i innholdsformat, vil dette gi deg innhold for både nyere og eldre apper via samme webtjeneste.
Mens du utvikler servicebaserte programmer, nettverk og enhet feiltoleranse bør også tas i betraktning. Mobildatatilkoblinger er vanligvis mindre stabile enn kablede, apper kan avinstalleres og installeres på nytt, og enheter kan gå tapt, erstattet med nyere eller fabrikkgjenopprettede. Brukere bør gis muligheten til å gjenopprette applikasjoner og innhold på en enkel måte, og plattformutviklere tilbyr flere nyttige, ferdige løsninger på disse problemene.
Husk å Kontroller alltid nettverksstatus før du ringer fjerntjenester eller omhyggelig håndterer I / O-feil i nettverket og informer brukerne riktig når den ønskede oppgaven ikke kan oppnås på grunn av manglende aktiv dataforbindelse. Hvis appene dine alltid trenger å "jobbe online", vil du kanskje sette en vakthund i appene dine som kontinuerlig overvåker nettverksstatus og brann en hendelse når det skjer en endring. Du vil kanskje også informere brukere om mulige ekstra kostnader når du overfører store mengder data via 3G eller roamingnettverk i stedet for Wi-Fi.
På Android-enheter kan denne oppgaven oppnås via ConnectivityManager, og gjennom SCNetworkReachability på iOS (se også den angitte prøveappen).
Både Android og iOS gir nyttige APIer for å håndtere ekstern sky backup av brukerappdata som du bør huske på. Sjekk iCloud API-dokumentasjonen for iOS og dokumentasjonen for Android Backup Service for Android. Sammen med innebygde sikkerhetskopieringstjenester får du også gode datasikkerhetsfunksjoner. Du må imidlertid være forsiktig så du ikke overbelaster sikkerhetskopieringstjenester med overflødige eller unødvendige sikkerhetskopier.
Du kan også implementere tilpasset ekstern data backup i webtjenestene dine, men jeg anbefaler på det sterkeste at du holder deg til standarder og innebygde plattform-APIer. De vil vanligvis spare deg tid og de vedlikeholdes aktivt av plattformsoftwareingeniører. OS-patcher er også mer sannsynlig å bli installert umiddelbart når de slippes ut.
Hvis du leverer betalt innhold ved hjelp av fakturering i appen i appen din, lar brukerne gjenopprette sine kjøp etter app gjeninstallerer og enhet gjenoppretting er påbudt, bindende. Heldigvis har iOS og Android innebygde APIer for å håndtere disse scenariene også.
Når appene dine som kjører i appen kjører for første gang (eller første gang etter en ominstallering), bør du kjøre en kjøpsgjenopprettingskontrollprosedyre. Både iOS og Android gir god offisiell dokumentasjon angående denne saken.
Når du utvikler for Android, må du huske at kun "administrerte" gjenstander kan gjenopprettes senere, og de er bare tilgjengelige på en engangs-til-bruk-kjøp. Dette innebærer noen hensyn som gjelder også iOS-utviklingen.
La oss anta at du skal utvikle et rollespill og vil tillate spillere å kjøpe varer som helse-drikker gjennom fakturering i appen. Først og fremst, siden brukerne kan kjøpe så mange potioner som de vil, kan de ikke "administreres" elementer, slik at deres kjøpstransaksjoner ikke lagres permanent. Også, hvis en bruker kjøper 20 potions og bruker 10, avinstallerer og gjenoppretter spillet senere. Ved å gjenopprette kjøp gjennom en enkel standardprosedyre, plasserer 20 potions tilbake i brukerens beholdning, hvorav 10 er en utilsiktet gratis gave fra utviklerne.
Så, det kan hende du må implementere dine egne tilpassede webtjenester og app-metoder for å håndtere transaksjonslagring og gjenoppretting i komplekse scenarier eller kantsaker.
Frister og budsjetter vil ofte kutte deg av og ikke la deg følge alle de beste metodene som er forklart i denne artikkelen. Men selv om du er tvunget til å holde fast i en mindre delmengde av funksjoner, tenk fremover, tilbringe litt tid i god design, og pakk dine metoder og klasser inn i biblioteker at du kan bruke og utvide senere. Legg igjen stubber når du føler at det er plass til videreutvikling. Prøv også å håndheve bakoverkompatibilitet når du utvider og forbedrer bibliotekene dine, slik at eldre programmer også kan patches.
Dette er et eksempel på en stub:
Offentlig tomt sendData (Objektdata) Hvis (validere (data)) client.send (data); // Stub public boolean validate (Objektdata) // TODO - Implementere data validering return true;
Hvis du er en nybegynnerutvikler eller aldri har utviklet tjenestebaserte applikasjoner, bør du starte fra det angitte prøveapplikasjonen som en god øvelse for å forbedre kunnskapen din og gjøre den til en virkelig applikasjon som bruker alle konseptene som er forklart i denne artikkelen, en til en tid. Alternativt kan du starte en ny applikasjon fra bunnen av og integrere den med noen eksisterende tjenesteleverandør (Facebook, Twitter, Last.fm eller Dropbox ville være et godt utgangspunkt) etter samme tidsplan.
Hvis du allerede har utviklet noen tjenester og nettverksbaserte applikasjoner, kan du se gjennom eksisterende kode og forbedre dem i henhold til prinsippene som er forklart ovenfor, holde oversikt over hver forbedring og innvirkning på ytelse og respons.
Ikke glem å sjekke ut de koblede ressursene også, da de vil ta deg dypere inn i kjernen av hvert problem, og laste ned prøveserveren og klientprogrammene som følger med artikkelen.
Accentsconagua