Å holde applikasjonsdata synkronisert på tvers av enheter er en komplisert og skremmende oppgave. Heldigvis er det akkurat hvorfor Apple bygget iCloud. I denne Tuts + Premium-serien lærer du hvordan iCloud fungerer, og hvordan programmene dine kan sømløst dele data på flere enheter.
Også tilgjengelig i denne serien:
Arbeider med iCloud: Introduksjon
Arbeide med iCloud: Nøkkelverdi Lagring
Arbeider med iCloud: Dokumentoppbevaring
Arbeider med iCloud: Core Data Integration
I den første delen av denne serien ga jeg en introduksjon til iCloud og fokuserte spesielt på iCloud Storage. To typer iCloud Storage er avaialable til utviklere, Nøkkelverdi lagring og Dokumentoppbevaring. Key-Value Storage vil være fokus for denne opplæringen.
Vi starter denne opplæringen ved å ta en nærmere titt på prosessen med å sette opp et program for bruk med iCloud. Med vår applikasjon riktig konfigurert, vil vi gjøre bruk av iClouds nøkkelverdilagring for å holde programmets data synkronisert på flere enheter.
Før vi begynner
Vi kan ikke teste datasynkronisering med bare en enhet. For å fullføre denne opplæringen må du ha minst to iOS-enheter som kjører iOS 5 eller høyere. Dessverre kan iOS-simulatoren ikke brukes til å teste iCloud Storage.
Programmet vi skal bygge vil være et enkelt iOS-program, noe som betyr at du vil kunne kjøre den på hvilken som helst iPhone, iPod Touch eller iPad som kjører iOS 5 eller høyere. Å lese denne opplæringen vil fortsatt være verdt, selv om du ikke har to separate iOS-enheter som kan brukes til testing. Det vil lære deg hvordan iCloud er opprettet og hvordan du kan bruke iClouds nøkkelverdi lagring for å forbedre dine egne applikasjoner.
Trinn 1: Prosjektoppsett
Jeg vil begynne med å gå gjennom prosessen med å konfigurere applikasjonen vår for å bruke iCloud Storage. Imidlertid må vi først opprette vårt Xcode-prosjekt.
Opprett et nytt prosjekt i Xcode ved å velge Enkeltvisningsprogram mal. Navn søknaden din Skyet, skriv inn en Bedriftsidentifikator, sett iPhone for enhetens familie, og sjekk Bruk automatisk referansetelling. De resterende avmerkingsboksene må ikke være merket. Fortell Xcode hvor du vil lagre prosjektet ditt og trykke Skape.
Det er nøkkelen som du nøye velger Produktnavn og Bedriftsidentifikator for dette prosjektet. Kombinasjonen av disse to elementene danner buntidentifikator (sammen med bundlefrøidentifikatoren) av søknaden din, som iCloud vil bruke til å identifisere din søknad unikt. Kontroller stavemåten nøye, fordi pakkeidentifikatoren er saksfølsom.
Trinn 2: Konfigurere iCloud
Som jeg nevnte i den første artikkelen i denne Tuts + Premium-serien, er det enkelt å sette opp et program for å bruke iCloud, og involverer bare to trinn. La meg gå deg gjennom prosessen trinnvis.
Trinn 2A: Leverandørportal
Åpne favorittleseren din og gå over til Apples iOS Dev Center. Logg inn på iOS-utviklerkontoen din og klikk på IOS Provisioning Portal lenke til høyre.
Først må vi opprette en App ID for vår søknad. Åpne App ID-er fanen til venstre og klikk på Ny app-ID knappen øverst til høyre. Gi app-ID et beskrivende navn for å identifisere det senere. Deretter skriver du inn pakkeidentifikatoren jeg snakket om for noen få øyeblikk siden. Buntidentifikatoren er kombinasjonen av firmaidentifikatoren din, com.mobiletuts i vårt eksempel og produktnavnet, Skyet i vårt eksempel. Du kan la bundlefrøidentifikatoren settes til Bruk Lag ID, som er bra for vår søknad.
Kontroller at buntidentifikatoren din er stavet riktig. Som nevnt tidligere er bunderidentifikatoren saksfølsom. Klikk på send-knappen for å opprette app-IDen din.
Din nyopprettede App ID skal nå være til stede i listen over App ID-er. Du vil legge merke til at iCloud er deaktivert som standard for hver nyopprettede App ID. La oss endre det. På høyre side av app-ID-en klikker du på Konfigurer knapp. Nederst på siden, bør du se en avkrysningsboks som sier Aktiver for iCloud. Merk av i avmerkingsboksen og klikk Ferdig. Vår app-ID er nå konfigurert til å fungere med iCloud. Det er en ting vi må ta vare på mens vi er i Provisioning Portal.
For å sikre at applikasjonen vår kan kjøre på enhetene våre, må vi opprette en provisjonsprofil. Fortsatt i IOS Provisioning Portal, åpne Provisioning fanen til venstre og velg Utvikling fanen øverst. Klikk på Ny profil knappen øverst til høyre og skriv inn et beskrivende navn for den nye profilen din. Velg deretter utviklingssertifikatet du vil at profilen skal knyttes til, og velg riktig App ID fra rullegardinlisten. Til slutt velger du enhetene du vil bruke til testing fra listen nederst på siden.
Etter å ha klikket på send-knappen nederst til høyre, vil du legge merke til at provisjonsprofilen din har status for I påvente av. Etter at siden ble lastet opp, var profilens status oppdatert til Aktiv. Klikk på nedlastningsknappen ved siden av provisjonsprofilen din, og dobbeltklikk på profilen. Xcode installerer automatisk profilen for deg.
Trinn 2B: Rettigheter
Mange utviklere kryper når de hører ordet rettigheter. Rettigheter er ingenting å være redd for når du forstår hva de er for. Rettigheter gir spesifikke evner eller sikkerhetsrettigheter til et program. Det er alt der er til det. Det er en enkel liste over nøkkelverdige par som forteller operativsystemet hva søknaden din kan og ikke kan gjøre, og hvilke applikasjoner som har tilgang til programmets data. Sistnevnte er spesielt viktig når du arbeider med iCloud.
I vårt eksempel gir iCloud rettigheter oss mulighet til å aktivere iCloud Storage for vår søknad. For å konfigurere rettighetene til søknaden vår, går vi over til Xcodes målredigerer.
Klikk på vårt prosjekt i Prosjektnavigator og velg vårt mål fra mållisten. Med Sammendrag fanen valgt, bør du se en seksjon som heter rettigheter på bunnen. Sjekk det første avkrysningsruten for å aktivere rettigheter for vår søknad. Dette alternativet vil opprette en rettighetsfil for vår søknad. Tekstfeltet under boksen bør fylles ut for deg. Vi har nå muligheten til å aktivere iCloud Key-Value Storage og iCloud Document Storage.
I denne opplæringen snakker jeg bare om iCloud Key-Value Storage, merk av i boksen ved siden av iCloud Key-Value Store. Igjen, Xcode forfyller tekstfeltet ved siden av avkrysningsboksen med din applikasjonspakkeidentifikator (uten pakkefrøidentifikatoren). Bekreft at denne pakkeidentifikatoren tilsvarer den du skrev inn i provisjonsportalen når du opprettet app-IDen din. Jeg vil snakke om iCloud Containers i neste opplæring som de forholder seg til iCloud Document Storage.
På bunnen av delen Rettigheter ser du Nøkkelringstilgang Grupper. Denne listen angir hvilke applikasjoner som har tilgang til søknadene dine, nøkkelringelementer. Du kan forlate den delen uberørt for nå.
Før vi får våre hender skitne med iCloud API, må vi konfigurere våre bygginnstillinger. Fortsatt i Xcodes målredigeringsprogram, velg Bygg innstillinger og bla ned til Kodesignering seksjon. Angi kodesigneringsidentiteten for Debug og Utgivelse konfigurasjoner for å matche profilen vi nettopp har opprettet i IOS Provisioning Portal.
Trinn 3: Brukergrensesnitt
Denne opplæringen er noe avansert, og jeg antar derfor at du er kjent med de grunnleggende konseptene i IOS-utvikling. Dette betyr at jeg vil flytte litt raskere enn jeg vanligvis gjør siden vi har mye grunn til å dekke.
Programmet som vi skal bygge vil være en enkel bokmerkeradministrator. Vi kan legge til og slette bokmerker, og våre bokmerker blir synkronisert på tvers av enhetene våre. Hvor kult er det? La oss komme i gang.
Åpne tittelkontrollens headerfil og opprett en instansvariabel (ivar) av typen NSMutableArray med et navn på bokmerker. Ivar vil lagre våre bokmerker. Bokmerkene vises i en tabellvisning. Opprett et uttak for tabellvisningen i vår visningskontrollers headerfil og sørg for å tilpasse visningsstyreren til tabellvisningskilden og delegere protokoller. Ikke glem å syntetisere accessors for begge egenskapene i vår visningskontrollers implementeringsfil. Deretter legger du til to handlinger til ViewController.h, editBookmarks: og Legg til bokmerke:. Klar? Gå over til ViewController.xib fil for å koble alt opp.
Begynn med å dra en navigeringslinje til visningskontrollens visning og plasser den øverst. Dra en forekomst av UIBarButtonItem til venstre for navigasjonslinjen og angi sin identifikator i Attributtsinspektør til Redigere. Kontroller dra fra redigeringsknappen til vår Filens eier og velg editBookmarks: metode. Dra et andre strekkknappelement til høyre for navigasjonslinjen og gi det en identifikator for Legg til. Kontroller dra fra add-knappen til vår Filens eier og velg Legg til bokmerke: metode. Til slutt, dra en forekomst av UITableView til visning av kontrollenhetens utsikt og koble dens datakilde og delegere utsalgssteder til Filens eier gjenstand. Ferdig.
Gjennomføringen av tabellvisningen vår datakilde og delegere protokoller er enkel og grei. I numberOfSectionsInTableView: Metode, vi verifiserer om vår datakilde, det vil si våre bokmerker, ikke er null. Hvis det er null, returnerer vi 1. Hvis ikke, returnerer vi 0. Den Tableview: numberOfRowsInSection: Metoden er nesten identisk. I stedet, hvis vår datakilde ikke er null, returnerer vi antall elementer den inneholder. Hvis vår datakilde er null, returnerer vi 0.
- (NSInteger) numberOfSectionsInTableView: (UITableView *) tableView if (self.bookmarks) return 1; ellers return 0; - (NSInteger) tableView: (UITableView *) tableView numberOfRowsInSection: (NSInteger) seksjon if (! Self.bookmarks) return 0; annet return self.bookmarks.count;
I Tableview: cellForRowAtIndexPath: metode, begynner vi ved å erklære en statisk celleidentifikator med det formål å gjenbruke celle og deretter spørre tabellvisningen for en gjenbrukbar celle med celleidentifikatoren vi nettopp erklærte. Hvis en gjenbrukbar celle ikke ble returnert, initierer vi en ny celle med en stil på UITableViewCellStyleSubtitle og vi sender vår celleidentifikator for gjenbruk av cellen. Deretter henter vi riktig bokmerke fra datakilden. Hvert bokmerke vil være en ordbok med to nøkkelverdier, a Navn og a URL. Vi konfigurerer cellen ved å angi sin etikett og detaljetikett med henholdsvis bokmerkens navn og URL.
Brukeren har også muligheten til å redigere bokmerkene sine. I Tableview: canEditRowAtIndexPath: Metode vi kommer tilbake JA. De Tableview: commitEditingStyle: forRowAtIndexPath: er litt mer komplisert. Vi starter med å verifisere at cellens redigeringsstil er lik UITableViewCellEditingStyleDelete, det vil si et bokmerke ble slettet. Først oppdaterer vi vår datakilde ved å slette bokmerket fra bokmerkene. Vi lagrer så datakilden ved å sende visningskontrolleren a saveBookmarks melding og vi oppdaterer endelig tabellvisningen for å gjenspeile endringene vi har gjort i datakilden.
La oss ta en titt på våre handlinger nå. De editBookmarks: Metoden kunne ikke vært enklere. Vi bytter redigeringsstatusen til tabellvisningen på en animert måte.
De Legg til bokmerke: Metoden krever litt mer arbeid. Vi initialiserer en ny forekomst av AddBookmarkViewController, en visningskontrollør som vi vil lage kort, og vi setter den til å vise kontrolleregenskapen til selv-. Vi presenterer deretter den nyopprettede visningskontrollen modelt. Som navnet tilsier, AddBookmarkViewController har ansvaret for å opprette nye bokmerker. La oss ta en nærmere titt på AddBookmarkViewController.
Gjennomføringen av AddBookmarkViewController er veldig grei, så jeg vil ikke gå inn i for mye detalj. Visningsregulatoren har en svak referanse til hovedvisningskontrollen. Dette gjør det mulig å varsle vår hovedvisningskontroller når et nytt bokmerke er opprettet. Det har også to uttak av typen UITextField, som lar brukeren skrive inn et navn og en URL for hvert bokmerke.
XIB-filen inneholder en navigasjonslinje øverst med en Avbryt og a lagre knapp. Visningen i seg selv inneholder navn og URL-feltene jeg nettopp nevnte. Avbryt og lagre knappene er koblet til a Avbryt: og a lagre: handling, henholdsvis. De Avbryt: handling avviser bare vår modal view controller. De lagre: handlingen er like enkelt. Vi lager et nytt bokmerke (dvs. en forekomst av NSDictionary) med dataene brukeren har angitt i tekstfeltene, og fortell hovedvisningen kontrolleren om det nye bokmerket. Det er viktig å merke seg at dette ikke er den beste løsningen for å la hovedvisningen kontrolleren vite når et nytt bokmerke er opprettet av vår AddBookmarkViewController. Denne tilnærmingen introduserer tett kobling, som bør unngås så mye som mulig. En bedre tilnærming ville være å vedta delegasjonsmønsteret.
Vi er nesten klare, men vi må fortsatt implementere det saveBookmark: metode i hovedvisningen kontrolleren. Begynn med å erklære denne metoden i vår visningskontrollers headerfil og deretter gå over til implementasjonsfilen. Gjennomføringen er minimal. Vi legger til det nyopprettede bokmerket til vår datakilde, vi lagrer datakilden, og deretter oppdaterer vi tabellvisningen for å vise bokmerket vi nettopp har lagt til.
Vår søknad er ikke særlig nyttig hvis brukerens bokmerker ikke blir lagret på disk. Brukeren vil miste sine bokmerker hver gang programmet avsluttes. Dårlig brukeropplevelse. La oss fikse dette.
I vår viewDidLoad: metode, vi sender vår kontroller a loadBookmarks budskap. La oss ta en titt på loadBookmarks metode. Vi lagrer brukerens bokmerker i Brukerstandarddatabase. Vi kontrollerer først om det allerede er en oppføring i brukerens standarddatabase med nøkkelen bokmerker. Hvis dette er tilfelle, initierer vi bokmerkene våre med innholdet i det lagrede objektet. Dette er ikke tilfelle, vi initialiserer våre bokmerker med et tomt, gjengivelsesbart array og lagrer det arrayet i brukerens standarddatabase. Enkel. Ikke sant?
- (ugyldig) loadBookmarks NSUserDefaults * ud = [NSUserDefaults standardUserDefaults]; hvis ([ut objectForKey: @ "bookmarks"]! = null) // Last Local Copy self.bookmarks = [NSMutableArray arrayWithArray: [ut objectForKey: @ "bokmerker"]]; ellers // Initialiser bokmerker self.bookmarks = [[NSMutableArray alloc] init]; // Lagre lokal kopi [ut setObject: self.bookmarks forKey: @ "bookmarks"];
Lagre bokmerkene er enda enklere. Vi lagrer vårt bokmerkeobjekt i brukerens standarddatabase ved å bruke nøkkelen bokmerker. Det er alt der er til det.
Det var ganske mye arbeid. Du kan nå bygge og kjøre din søknad. Du bør kunne legge til bokmerker og slette bokmerker. Bokmerkene lagres på disk, slik at du ikke mister data når du avslutter programmet.
Trinn 6: Synkroniser bokmerker
For å få vår applikasjon til å skinne, bruker vi iCloud til å holde våre bokmerker synkronisert på tvers av enhetene våre. Det vil overraske deg hvor lett dette er. Som jeg nevnte i den forrige veiledningen i denne serien, fungerer iClouds nøkkelverdi lagring mye NSUserDefaults, det vil si, det lagrer nøkkelverdige par. I ICloud-terminologi er butikken navngitt NSUbiquitousKeyValueStore. La oss starte med å lagre bokmerkene våre ikke bare lokalt, men også til iCloud.
Gå over til vår saveBookmarks: metode og endre vår metode for å se ut som den nedenfor. Vi starter med å hente en referanse til standardbutikken ved å ringe defaultStore på NSUbiquitousKeyValueStore klasse. Igjen, dette ligner veldig NSUserDefaults. Hvis vår referanse til butikken ikke er null, lagrer vi vårt bokmerkeobjekt i butikken med samme nøkkel som vi brukte til å lagre våre bokmerker i brukerens standarddatabase. Endelig synkroniserer vi butikken.
- (void) saveBookmarks // Lagre lokal kopi NSUserDefaults * ud = [NSUserDefaults standardUserDefaults]; [ut setObject: self.bookmarks forKey: @ "bookmarks"]; // Lagre til iCloud NSUbiquitousKeyValueStore * store = [NSUbiquitousKeyValueStore defaultStore]; hvis (store! = null) [lagre setObject: self.bookmarks forKey: @ "bokmerker"]; [lagre synkronisere];
ringe synkron I butikkinstansen synkroniserer du in-memory-tastene og verdiene med de som er lagret på disken. Du tror kanskje at denne metoden tvinger nye nøkkelverdier til å bli sendt til iCloud, men dette er ikke tilfelle. Ved å lagre minnetastene til disk, blir iCloud varslet om at det er nye nøkkelverdierpar tilgjengelig for synkronisering. Det er imidlertid operativsystemet som til slutt bestemmer når det er hensiktsmessig å synkronisere de nylig tilførte nøkkelverdiene med iCloud. Dette er viktig å huske på, og dette er også grunnen til at endringer som er gjort på en enhet, ikke vil være synlige på en annen enhet umiddelbart.
Også, selv om vi ringte synkronisert metode i butikken, dette er ikke nødvendig i de fleste situasjoner. Operativsystemet gjør dette for deg ved passende tider. Visste du at NSUserDefaults har en synkron metode som også fungerer nesten identisk?
Du lurer kanskje på hvordan søknaden vår vet når en annen enhet har oppdatert nøkkelverdi-butikken i iCloud, og hvordan den kan trekke i disse endringene. Dette er et veldig godt spørsmål, og dette er det siste stykket av puslespillet.
Hver gang nøkkelverdi-butikken er endret, sendes et varsel, og søknaden vår kan registrere som en obeserver for disse varslene. Det er viktig at du registrerer deg for slike meldinger så tidlig som mulig i programmets livssyklus.
La oss se hvordan dette virker. I vår viewDidLoad Metode vi gjør fire ting. Først får vi en referanse til nøkkelverdi-butikken. For det andre legger vi til visningskontrollen som observatør for eventuelle meldinger med et navn på NSUbiquitousKeyValueStoreDidChangeExternallyNotification sendt av nøkkelverdi-butikken. Når vi mottar et slikt varsel, håndterer vi dette varselet i vår updateKeyValuePairs: metode (som vi vil skrive om et øyeblikk). Deretter sender vi butikken en melding om synkron. Til slutt laster vi våre bokmerker som vi gjorde før.
Alt som er igjen for oss å gjøre er å implementere updateKeyValuePairs: metode. La oss gjøre det akkurat nå. Meldingen er brukerinformasjon ordbok inneholder to viktige nøkkelverdier par, (1) grunnen til hvorfor varselet ble sendt og (2) nøkler i nøkkelverdi-butikken hvis verdier ble endret. Vi starter med å se nærmere på årsaken til varselet. Vi sørger først for at en grunn ble spesifisert og returnert dersom ingen var spesifisert. Hvis en grunn var spesifisert, fortsatte vi bare hvis årsaken var enten en endring på serveren (NSUbiquitousKeyValueStoreServerChange) eller lokale endringer ble kassert på grunn av en innledende synkronisering med serveren (NSUbiquitousKeyValueStoreInitialSyncChange). Hvis en av disse kriteriene er oppfylt, trekker vi ut de forskjellige tastene som endret seg, og vi gjenspeiler nøklene for å se om bokmerkene våre er blant dem. Hvis dette er tilfelle, tar vi verdien som er knyttet til nøkkelen, og oppdaterer vår datakilde samt brukerens standarddatabase med denne verdien. Til slutt laster vi opp tabellvisningen for å gjenspeile endringene.
- (void) updateKeyValuePairs: (NSNotification *) varsel NSDictionary * userInfo = [notification userInfo]; NSNumber * changeReason = [userInfo objectForKey: NSUbiquitousKeyValueStoreChangeReasonKey]; NSInteger grunn = -1; // Er en grunn spesifisert? hvis (! changeReason) return; else reason = [changeReason integerValue]; // Fortsett hvis grunnen var (1) Endringer på server eller (2) Innledende synkronisering hvis ((grunn = = NSUbiquitousKeyValueStoreServerChange) || (grunn = = NSUbiquitousKeyValueStoreInitialSyncChange)) NSArray * changedKeys = [userInfo objectForKey: NSUbiquitousKeyValueStoreChangedKeysKey]; NSUbiquitousKeyValueStore * store = [NSUbiquitousKeyValueStore standardStore]; // Søke nøkler for "bokmerker" Nøkkel for (NSString * nøkkel i endret Kaster) if ([key isEqualToString: @ "bokmerker"]) // Oppdater datakilde self.bookmarks = [NSMutableArray arrayWithArray: [lagre objektForKey: tast] ]; // Lagre lokal kopi NSUserDefaults * ud = [NSUserDefaults standardUserDefaults]; [ut setObject: self.bookmarks forKey: @ "bookmarks"]; // Oppdater tabelloversikt [self.tableView reloadData];
Det er to punkter som krever spesiell oppmerksomhet. For det første, som vi så i implementeringen av updateKeyValuePairs:, Vi mottar en matrise som inneholder alle nøklene i nøkkelverdi-butikken med verdier som ble endret. Dette er en oppimisering for å hindre at iCloud må sende et varsel for hvert nøkkelverdi-par som endret seg. For det andre anbefales det sterkt at du lagrer data fra nøkkelverdi-butikken lokalt. Brukerens standarddatabase er velegnet til dette formålet, men du kan velge hvilken løsning som passer dine behov. Årsaken til lagring av en lokal kopi er å ikke stole på iCloud for datalagring. Ikke alle brukere har en iCloud-konto eller har iCloud aktivert på enheten.
Med dette siste stykket kode på plass, er søknaden vår nå iCloud aktivert. Bygg og kjør programmet på to enheter og test det selv. Vær oppmerksom på at endringer ikke er øyeblikkelige. Endringer må synkroniseres med iCloud-serverne og sendes deretter til de aktuelle enhetene som krever oppdatering.
Selv om denne tuturialen er lang, krever implementeringen av iCloud Key-Value Storage ikke så mye ekstra kode. Som jeg skrev i den forrige opplæringen, er det enkelt, grei å vedta nøkkelverdig lagring og krever svært lite overhead fra din side.
Konklusjon
Før du pakker opp denne opplæringen, vil jeg gjenta fordelene og ulempene med iCloud Key-Value Storage som de er viktige å huske på. Fordelene er åpenbare nå, det er lett å adoptere, raskt å implementere, og det ligner veldig mye hvordan NSUserDefaults virker. Det er imidlertid også viktig å holde ulemper i tankene. Nøkkelverdipar er hva de er. Det er enkle par uten noen form for konflikthåndtering, med mindre du implementerer din egen konflikthåndteringslogikk. Sistnevnte anbefales ikke siden Key-Value Storage ikke ble bygget med dette i tankene. Dokumentlagring gir innebygd konfliktstøtte, og er derfor et mye bedre alternativ hvis du trenger konflikthåndtering. Til slutt, ikke glem at Key-Value Storage kun kan lagre 1MB verdt data med maksimalt 1024 nøkkelverdier. Selv om vi vedtatte nøkkelverdi lagring i denne applikasjonen for illustrasjonsformål, kan vi ikke garantere at det aldri vil være en bruker med en liste over bokmerker som overgår 1MB grensen.
Jeg vil også understreke at formålet med vår søknad er å vise deg hvordan du vedtar nøkkelverdi lagring og hvordan det fungerer bak kulissene. Dette er på ingen måte et program som er klar for utgivelse, da det ikke er kollisikkert på flere måter.
Neste gang
I denne veiledningen lærte vi å sette opp et program for bruk med Apples iCloud. Vi tok også en nærmere titt på iCloud Key-Value Storage. I neste veiledning vil vi fokusere på den andre typen iCloud Storage: Document Storage. Denne typen iCloud Storage er rettet mot datatunge applikasjoner, og det er akkurat det vi skal bygge i neste opplæring.
Share
Accentsconagua
