Share
Hva du skal skapeGrensesnitt med en API er en stor del av webutvikling og design i disse dager. APIer bidrar til å gi en rik og dynamisk opplevelse i nettleseren. I stedet for statisk markering og bilder, kan du dynamisk trykke og trekke data fra en server og gjøre det i nettleseren basert på opplevelsen du vil gi brukeren.
I denne opplæringen bygger vi et grunnleggende eksempel på en API-basert app. Ved hjelp av iTunes API, tar vi nettadressen til en hvilken som helst iOS- eller Mac-app, og gjengir full oppløsningsikon rett i nettleseren. Denne spesifikke appen er kanskje ikke umiddelbart nyttig for deg, men det du lærer underveis, kan brukes på alle slags scenarier.
De fleste skikkelig utformede iOS- og OSX-appene gir høyoppløselige ressurser for deres ikoneksempler. Sikker på at disse ikonene bare ser ut til å være 150 × 150 piksler i størrelse på iPhone vårbrett eller din OSX dock, men for å ta hensyn til retina skjermbilder og forskjellige størrelseskrav på tvers av operativsystemet, ber Apple at app-produsenter gir høyoppløselig ikon eiendeler, så store som 1024 × 1024 piksler! For eksempel, til venstre vil du se Tweetbot for Mac-ikonet som det omtrent vil vises i OSX-dokken din. Mens til høyre er bildet i full oppløsning:
Apple gjør disse ressursene tilgjengelige via iTunes API. Så hvis du ønsker å få høyoppløsningen, full størrelse kunstverk, kan du! Alt du trenger er appens identifikator, og ved å sende en forespørsel til API-en får du en mengde informasjon om appen, inkludert en kobling til høyeste oppløsningskunstverket butikken har tilgjengelig.
Denne opplæringen handler ikke så mye om å lære iTunes API som det handler om å lære noen av de grunnleggende konseptene bak å bygge en dynamisk webapp som gjør at innholdet returneres fra en API. Når du lærer grunnleggende om grensesnitt med en API, kan du fortsette å bygge dine egne personlige nettsider ved hjelp av tredjeparts APIer, som Dribbble eller Twitter.
Som en rask oversikt, er de konseptene vi vil dekke i denne opplæringen for å oppnå sluttproduktet:
For å forstå hva vi skal bygge, la oss begynne med å detaljere den grunnleggende opplevelsen av vår lille app. Når det er fullført, kan vi få litt mer spesifikt ved å notere komponentene.
For å starte wireframing av appens komponentdeler trenger vi en liste over appens grunnleggende funksjonalitet og erfaring:
Nå som vi har en grunnleggende forståelse av hva vi vil at appen skal oppnå, kan vi starte wireframing sine forskjellige deler. Husk at vi vil at dette skal være en responsiv webapp, så vi vil sørge for å designe våre deler på en måte som gjør at de kan formatere opp og ned responsivt.
Overskrift: Øverst på siden har vi noen stilisert tekst som representerer navnet på appen, sammen med en kort beskrivelse av hva den gjør. "Gimmie Dat iCon" er det dumme navnet jeg har møtt med vår app.
Input: Vi må gi en måte for brukeren å skrive inn en lenke til appen, hvis ikonet kunstverk de vil ha. For dette legger vi til et enkelt inntastingsfelt og sender inn knappen rett under overskriften.
Produksjon: Når en gyldig lenke er hentet fra brukeren, trenger vi et mellomrom for å vise ikonet kunstverket hentet fra iTunes. Så vi lager et sted for det rett under inntastingsfeltet.
Det handler om det. Vi har nå alle de grunnleggende komponentene vi trenger for å hente en kobling fra brukeren og vise informasjon som kommer tilbake fra iTunes API.
Det er en annen viktig faktor vi må vurdere i vårt wireframe-stadium: de forskjellige tilstandene til våre komponenter. Vår lille app kommer til å være i forskjellige stater på forskjellige tidspunkter. For eksempel, vi vet at vi trenger å vise ikonet kunstverket returnert av iTunes API, vi har allerede regnet med det. Men hva hvis API gir tilbake en feil, hva gjør vi da? Eller hva om brukeren kommer inn i en dårlig link? Vi må gjøre rede for de forskjellige tilstandene vår app kan være inne, avhengig av utførelsen. Siden vår app er ganske enkel, har vi bare disse få bruksomgangene vi trenger å dekke:
Null tilstand: Hva skjer når brukeren først kommer til vår nettside? Det er ingen ikonartikk som skal vises fordi de ikke har angitt en nettadresse ennå. Så vi trenger en type vennlig "null tilstand" som sier "hei, du har ikke skrevet inn en lenke enda. Gå videre og skriv inn en så viser vi ikonet her. "
feil: Det er veldig mulig at noen feil kan oppstå under utførelsen av appen vår. For eksempel kan brukeren skrive inn en ugyldig nettadresse. Eller iTunes-API-en kan returnere dårlige data, eller ingen data i det hele tatt. Vi bør ta hensyn til disse sakene i appens design, slik at brukeren ikke er igjen, lurer på hva som gikk galt. Så vi skal designe en måte å vise en feilmelding på (hvis teksten vil endre seg, avhengig av feilen).
Laster: Fordi vi jobber med en API, vil ikke alt skje øyeblikkelig. Brukerens datamaskin må gjøre en forespørsel til en tredjepartsserver, som må beregne forespørselen og sende informasjonen tilbake. Det kan ta opptil noen sekunder å skje. Så vi vil sørge for at vår apps design gir en måte å kommunisere med at innholdet lastes inn. På den måten blir brukeren ikke frustrert og forvirret av en statisk skjerm hvor ingenting skjer (selv om innholdet lastes inn i bakgrunnen).
Det er det! Vi har dekket alle våre forskjellige komponenter og deres forskjellige tilstander. I neste veiledning vil vi fortsette å visuelt utforme appen med mer detaljerte wireframes.
Accentsconagua