Lag din egen webtjeneste for en iOS-app, del en

I min forrige TechRepublic-serie brukte vi en eksisterende webtjeneste til å lage en iOS-app ("Opprette en webtjeneste, deler en og to"). I denne serien lager vi webtjenestens backend for en annen app kalt iGlobe, som er et spill jeg opprettet for en stund siden.

I utgangspunktet ønsker vi at brukeren skal kunne tagge et sted eller en person og få poeng for den handlingen. (Konkurrenten med flest poeng på slutten av spillet vinner en pengepott.) For å gjøre dette, må appen samhandle med en webtjeneste, som vi lager. Nettjenesten vår må kunne:

  • Lagre spillerens brukernavninformasjon
  • Motta brukernes poeng
  • Presentere brukerens poeng

I denne iOS 6/7 opplæringen bruker vi en hjelpeklasse kalt SantiappsHelper, som inneholder koden for å kjøre disse tilkoblingene til nettet. En frittstående klasse i slike tilfeller kalles vanligvis et bibliotek, som tar seg av disse prosessene. Hvis du bare trenger en forekomst av en slik klasse (som i vårt tilfelle), oppretter du et Singleton-mønster. Du vil bare ha en forekomst av tilkoblingen, fordi du ikke vil at mange forekomster av tilkoblingsklassen oppretter, mottar og kobler fra - som kan havne i flere tilkoblinger til samme ressurs til forskjellige tider, noe som kan forvirre deg eller server.

Her er hva vi vil dekke i denne serien:

1. Opprett webdatabasen

2. Lag webtjenestens backend

3. Lag iOS frontend (Storyboard)

4. Hent data

  • en. NSURLConnection
  • b. GCD og kompletteringsblokker

5. Utveksle data mellom enheter som bruker iOS 7s Multipeer Connectivity Framework

Trinn 1: Opprett webdatabasen

Webtjenester er vanligvis store databaser med informasjon; vår database trenger en tabell for å lagre all informasjonen vi nevnte ovenfor. Vi samhandler med databaser på fire hovedmåter: Opprette, lese, oppdatere og slette (CRUD) data. Så la oss ta en kort omvei og snakke om databaser - nærmere bestemt strukturen deres og hvordan vi samhandler med dem.

databaser

Databaser er informasjonslagre, som kan skrives som filer (for eksempel Word eller PowerPoint). Informasjonen i slike filer har en forhåndsbestemt struktur som Word og PowerPoint vet hvordan de skal lese og få tilgang til for å presentere det du vil og la deg redigere den og lagre den igjen; problemet er bare Word vil lese en docx-fil, og bare PowerPoint vil lese en pptx-fil. De store fordelene med databaser er at de lagrer informasjon på en veldig kompakt måte og kan leses av mange forskjellige grensesnitt. Jo enklere database, jo flere grensesnitt kan lese den.

Vi bruker en database som vanligvis er tilgjengelig gratis i de fleste webhotelltjenester. Webhotellstjenesten min har phpMySQL, som følger med en gratis pakke. Hvis du vil ha andre databaser som MSSQL, trenger du en betalt tjeneste. Figur A er hvordan databaseadministrasjonsgrensesnittet mitt ser ut.

Figur A

Se et forstørret bilde av figur A.

Vi har en database kalt iglobe på localhost med to tabeller: brukere og koder. Brukertabellen ( figur B ) inneholder en primærnøkkel med et brukernavn, et passord, et passordhint, et fornavn og etternavn, samt en e-post, et telefonnummer, en adresse og slike vanlige ting.

Figur B

Se et forstørret bilde av figur B.

Merketabellen ( figur C ) har også sin egen primære nøkkel (tagID), det tilsvarende brukernavnet, en identifikator, taggens breddegrad og lengdegrad, datoen den ble opprettet, og hvor mange poeng det er verdt for den brukeren. Det er også et landsfelt som ble implementert senere etter hvert som prosjektet gikk videre (det har vært i verk siden 2011).

Figur C

Se et forstørret bilde av figur C.

Trinn 2: Lag webtjenestens backend

Tanken med nettjenesten vår vil være å lese fra disse tabellene og skrive til dem hva data brukerne ber om eller legge ut til dem. Denne delen krever at du kjenner til noen PHP. La oss begynne med å se på hvordan koden du skal lese en tabell ser ut.

 kode ($ arr); ?> 

Først inkluderer vi JSON.php-filen for å få tilgang til JSON-filer på serveren din (sørg for at webserveren eller verten din gir deg minst PHP 5.2). Deretter oppretter vi en forbindelse til databasen ved å bruke databasebrukeren og passordet samt databasen vert. Nå lager vi et array-objekt, så når vi kjører mysql_query der alle oppføringer fra brukertabellen er samlet inn i $ rs, kan vi legge dette objektet inn i $ arr -objektet. Til slutt koder vi $ arr til $ json og ekko den på skjermen.

Når denne koden er oppe og klar sammen med databasen din (inkludert noen poster), kan du lede nettleseren din til denne filen (som jeg kalte myserver.com/getusers.php). Jeg får følgende resultat:

 {"id": "35", "brukernavn": "zlitsami", "passord": "932d1c42a4e4880e57037994fd3584b1", "password_hint": "", "etternavn": "", "fornavn": "", "e-post" : " postbeskyttet ", "phone": "", "address1": "", "address2": "", "city": "", "state": "", "zip": "", "land": "", "url": "", "tillatelser": "1", "udid": "9", "userCreated": "2013-01-01 14:27:22", "time_queued" : null, "time_sent": null}, {another}, {another} 

Dette er en matrise som har mange elementer i seg. Hvert element er en brukers tabelloppføring. Hver oppføring er en ordbok med nøkkelverdipar. Ser kjent ut?

Nå som vi vet hvordan vi kan lese informasjon fra databasen vår, la oss lage koden for skriving til databasen.

Vi kobler oss til databasen vår igjen, og vi oppretter en sql-setning med verdier å sette inn (disse verdiene kommer fra en form som enten var online eller på en mobil enhet). Vi utfører den sql-uttalelsen med vår tilkobling og gjentar resultatene for verifisering til brukeren. Jeg kalte denne filen writephp.php.

La oss teste tjenesten vår på nettet før vi går over til iOS. Lag en HTML-fil som heter Writeform.html og lagre denne koden i den:

Navn:
UDID (unødvendige):
Breddegrad:
lengdegrad:
Land
mottaker

Last nå skjemaet i nettleseren din og send inn data til databasen din.

Jeg vil ikke gjøre denne webtjenesten for komplisert fordi jeg vil holde oppmerksomheten din på iOS-siden, så la oss lage et skjema for til slutt å lese punkter fra webtjenesten vår for en bestemt bruker. Lag en annen HTML-fil som heter Testform.html og lagre denne koden i den:

 Bruker: 

Og opprette sin php-motstykke:

 kode ($ resultado); ?> 

Vi bruker denne siste koden litt senere når vi har fått inn mer data i databasen.

Så langt har vi en ressurs som returnerer poengene for en bestemt bruker, readpoints.php; dette er det som kalles endepunkt for webtjeneste. Webtjenester kan ha mange sluttpunkter. I et spill eller en app kan det være lurt å få mange brukers poeng samtidig for å fylle opp et ledertavle, for eksempel. Det kan være lurt å hente mange transaksjoner fra en fakturadatabase i stedet for én etter én. Så la oss komme foran oss selv og skape et sluttpunkt for å administrere et sett med inndatadata. I vårt tilfelle må vi kunne passere nettjenesten et sett med brukere. Filen vår vil se slik ut:

 "ok", "code" => 0, "original request" => $ post_data); ellers $ response = array ("status" => "feil", "code" => - 1, "original_request" => $ post_data); // 2. RING DB QUERY $ link = mysql_pconnect ("localhost", "brukernavn", "passord") eller dø ("Kunne ikke koble til"); mysql_select_db ("iglobe") eller dø ("Kunne ikke velge database"); // 3. OPPRET FINAL Array for å returnere $ arrayToReturn = array (); // 4. Syklus gjennom brukere foreach ($ post_data som $ verdi) {// CREATE QUERY $ result = mysql_query ("VELG brukernavn, SUM (poeng) SOM PUNTOS FRA koder HVOR brukernavn = '$ verdi' GRUPPE AV brukernavn)); // UTFØR SPØRSMÅL OG LEGG TIL HVER BRUKER / PUNKTER BILDIG TIL $ resultado ARRAY $ resultado = matrise (); mens ($ obj = mysql_fetch_object ($ resultat)) {$ arrayToReturn  = $ obj; }} Echo $ json-> koding ($ arrayToReturn); ?> 

Denne grunnleggende php-koden tar bestått i matrisen som vi nevnte og går gjennom databasen for å få poeng for hver bruker. Dette er viktig fordi vi sparer appen mange turer til webserverdatabasen.

Trinn 3: Lag iOS frontend (Storyboard)

Vi vil nå jobbe på iOS Storyboard eller frontend. Så får vi hardkodedata og henter nett fra selve backend; På denne måten kan vi se hva vår frontend vil kreve med tanke på datamodeller, og så kan vi hente webdata og erstatte dataene våre i disse datamodellene. Vi lærer også to måter å hente data på: inline, rotete kode og ryddig og ryddig koding.

Følg disse instruksjonene:

  1. Lag et nytt tomt prosjekt ved hjelp av Storyboards, ARC, iPhone og NO Core Data.
  2. Gå til storyboard og dra en UITableViewController over rutenettet.
  3. Lag en klasse som heter UsersListViewController. I Storyboard velger du scenen, og i Identity Inspector lager scenen vår UsersListViewController fra rullegardinlisten.
  4. Kjør en rask test for å sikre at tv-en vår fungerer.
  5. Bygg & løp. Du bør få en tom tabellvisning.

La oss gå gjennom hva vi vil gjøre i denne delen:

  • Legg til en array-eiendom til .m-filen din
  • Fyll ut den arrayen i viewDidLoad
  • Fjern de irriterende advarsellinjene
  • Få tabellvisning til å returnere en seksjon
  • Gjør tabellvisning returmatrise
  • Lag gjenstander for tabellvisning av returrett

Dette skal være en annen natur for deg nå, så jeg vil bla gjennom detaljene.

Her er eiendomskoden:
 @ eiendom (ikke-atomisk, sterk) NSArray * testArray; Her er viewDidLoad-koden: - (void) viewDidLoad {super viewDidLoad; self.testArray = NSArray alloc initWithObjects: @ "meg", @ "du", @ "dem", null; NSLog (@ "matrise% d", self.testArray count); } 

Her er koden for returmatrise:

 return self.testArray count; 

Her er cFRAIP-koden:

 - (UITableViewCell *) tableView: (UITableView *) tableView cellForRowAtIndexPath: (NSIndexPath *) indexPath {statisk NSString * CellIdentifier = @ "Cell"; UITableViewCell * cell = tableView dequeueReusableCellWithIdentifier: CellIdentifier forIndexPath: indexPath; // Konfigurer cellen ... cell.textLabel.text = self.testArray objectAtIndex: indexPath.row; returcelle; } 

Før du bygger og kjører, velger du UITableViewCell i Storyboard og sørger for at du bruker Cell som gjenbruksidentifikator i Attributtsinspektøren. Appen din skal fungere fint.

Hvis du bygger og kjører nå, skal brukere vises i tabellvisningen. Kul! Det er det vi kommer til å ønske å gjøre - det vil si vise en liste over brukere i en tabellvisning og deretter legge til poengene, som et poengsum.

Figur D er en mockup av hvordan appen vår vil se ut. I hovedsak vil vi ha en tabulatorlinjekontroller som administrerer tre visninger: Brukere, kart og instruksjoner. Vi vil også kaste inn en påloggingsvisning når appen lanseres. Dette bør gi deg en ide om hva slags oppgaver vi trenger å utføre for å oppnå dette.

a) Presentere en innloggingsvisningskontroller

b) Lagre bruker- og passinformasjon

c) Hent brukerdata fra webtjenesten

d) Plott poeng på et kart

e) Vis instruksjoner i en visning

Figur D

Se et forstørret bilde av figur D.

Du bør kunne lage dette på nytt på Storyboard. Her er de grunnleggende trinnene:

1. Velg din eksisterende UsersViewController-scene, og velg Embed In | fra Editor-menyen Tabbelinjekontroller. Du bør ha en scene og en klasse for UsersViewController, og scenen skal settes til sin klassetype i Identity Inspector.

2. Fjern den andre scenen som ble lagt til da du innebygde tabellvisningen i en fanefelt (ved å fjerne det, mener jeg at den ikke har noen etiketter eller andre kontroller i seg). Dra nå en UIMapView inn i den. Legg til en UINavigationBar på toppen og to knapper (Plot og Bump) på hver side. Lag en MapViewController-klasse for den, og angi type. Legg til en MKMapView IBOutlet-egenskap og to UIBarButtonItem IBOutlet-egenskaper, og koble dem til. Legg til MKMapViewDelegate.

3. Legg til en annen UIViewController for den siste visningen og dra en UIWebView og en UINavigationBar inn i den. Lag klassefilen og navng den InstructionsVC. Legg til en UIWebView IBOutlet-egenskap og koble den til. Legg til UIWebViewDelegate og ikke glem å angi scenetype.

4. Legg til en UIViewController, kall den ModalViewController ( figur E er slik min ser ut), og lag alle IBOutlet-egenskapene for det - det er fire etiketter med statisk tekst (Bruker, Pass, E-post og Pass krever ...). Det er tre UITextFields med plasseringstekst for å veilede brukeren. Det er tre UIB-knapper for forskjellige handlinger. Personikonet er en knapp med et bakgrunnsbilde satt til bildet; det vil være knappen brukerne vil bruke for å laste opp bildet til webserveren.

Andre klassefiler vi kunne lage nå er TagListController, Tag / Users Model og Annotation / PlacemarkVC.

Figur E

Se et forstørret bilde av figur E.

Ta et par minutter å visualisere hvordan applayoutet vil se ut nå som vi har en bedre ide om hvor vi skal, og sammenlign deretter visualiseringen din med den første skissen du laget av appen din.

I del to kobler vi til nettjenesten og henter faktiske data.

© Copyright 2021 | pepebotifarra.com