Share
Vad du ska skapaGränssnitt med ett API är en stor del av webbutveckling och design dessa dagar. API: er hjälper till att ge en rik och dynamisk upplevelse i webbläsaren. I stället för statisk markering och bilder kan du dynamiskt trycka och dra data från en server och göra den i webbläsaren baserat på den erfarenhet du vill ge användaren.
I den här handledningen bygger vi ett grundläggande exempel på en API-baserad app. Med hjälp av iTunes API tar vi URL-adressen till en iOS- eller Mac-app och gör den fullständiga upplösningsikonen direkt i webbläsaren. Denna specifika app kanske inte är direkt användbar för dig, men det du lär dig under vägen kan tillämpas på alla slags scenarier.
De flesta ordentligt utformade iOS- och OSX-apparaten ger högupplösta tillgångar för deras ikonartik. Visst kan dessa ikoner bara vara 150 × 150 pixlar i storlek på ditt iPhone-springbräda eller din OSX docka, men för att ta reda på retina-skärmar och olika storlekskrav över operativsystemet begär Apple att apptillverkare ger högupplöst ikon tillgångar, så stora som 1024 × 1024 pixlar! Till exempel, till vänster kommer du att se Tweetbot for Mac-ikonen som det ungefär skulle visas i din OSX docka. Till höger är bilden med full upplösning:
Apple gör dessa tillgångar tillgängliga via iTunes API. Så om du någonsin vill få högupplösta, fullstora bilder kan du! Allt du behöver är appens identifierare, och genom att göra en förfrågan till API-skivan får du en massa information om appen, inklusive en länk till det högsta upplösningstexten som butiken har tillgänglig.
Denna handledning handlar inte så mycket om att lära sig iTunes API när det handlar om att lära sig några av de grundläggande begreppen bakom att bygga en dynamisk webbapp som gör att innehållet returneras från ett API. När du väl har läst grunderna för gränssnitt med ett API kan du fortsätta att bygga dina egna personliga webbplatser med hjälp av tredjeparts API, som Dribbble eller Twitter.
Som en snabb överblick är här de begrepp vi kommer att täcka i denna handledning för att uppnå slutprodukten:
För att förstå vad vi ska bygga, låt oss börja med att beskriva den grundläggande erfarenheten av vår lilla app. När det är klart kan vi få lite mer specifikt genom att notera dess komponenter.
För att starta trådframställning av appens komponentdelar behöver vi en lista över appens grundläggande funktionalitet och erfarenhet:
Nu när vi har en grundläggande förståelse för vad vi vill att appen ska kunna åstadkomma, kan vi starta wireframing sina olika delar. Tänk på att vi vill att detta ska vara en lyhörd webapp, så vi kommer att se till att designa våra delar på ett sätt som gör det möjligt för dem att ställa upp och ner på ett korrekt sätt.
Rubrik: Överst på sidan har vi en stiliserad text som representerar namnet på appen, tillsammans med en kort beskrivning av vad den gör. "Gimmie Dat iCon" är det dumma namnet jag har kommit med för vår app.
Inmatning: Vi måste tillhandahålla ett sätt för användaren att ange en länk till appen, vars ikonuppsättning de vill ha. För detta lägger vi till ett enkelt inmatningsfält och skickar knappen direkt under rubriken.
Produktion: När en giltig länk har hämtats från användaren behöver vi ett mellanslag för att visa ikonerna som hämtats från iTunes. Så vi skapar en plats för det rätt under inmatningsfältet.
Det handlar om det. Vi har nu alla grundläggande komponenter som vi behöver för att hämta en länk från användaren och visa information som kommer tillbaka från iTunes API.
Det finns en annan viktig faktor som vi måste överväga i vårt wireframe-stadium: de olika delarna i våra komponenter. Vår lilla app kommer att vara i olika stater vid olika tidpunkter. Vi vet till exempel att vi måste visa ikonerna som returneras av iTunes API, vi har redan redogjort för det. Men vad händer om API: n returnerar ett fel, vad gör vi då? Eller vad händer om användaren går in i en dålig länk? Vi måste redogöra för de olika stater som vår app kan vara i, beroende på dess genomförandestatus. Eftersom vår app är ganska enkel har vi bara dessa få användarfall som vi behöver täcka:
Nolltillstånd: Vad händer när användaren först kommer till vår webbsida? Det finns inget ikonartillverkning att visa eftersom de inte har angett en webbadress ännu. Så vi behöver någon typ av vänliga "nolltillstånd" som säger "hej, du har inte skrivit in en länk än. Gå vidare och skriv in en då visas ikonen här. "
fel: Det är mycket möjligt att några fel kan uppstå under genomförandet av vår app. Till exempel kan användaren ange en ogiltig webbadress. Eller iTunes-API: n kan returnera dåliga data eller ingen data alls. Vi bör redogöra för dessa fall i vår apps design så att användaren inte lämnas undrar vad som gick fel. Så vi ska utforma ett sätt att visa ett felmeddelande (vars text kommer att ändras beroende på felet).
Läser in: Eftersom vi arbetar med ett API, kommer inte allt att hända omedelbart. Användarens dator måste göra en förfrågan till en tredje part, som måste beräkna förfrågan och skicka tillbaka informationen. Det kan ta upp till några sekunder att hända. Så vi ska se till att vår apps design ger ett sätt att kommunicera att innehållet laddas. På det sättet blir användaren inte frustrerad och förvirrad av en statisk skärm där inget händer (även om innehåll laddas i bakgrunden).
Det är allt! Vi har täckt alla våra olika komponenter och deras olika tillstånd. I nästa handledning fortsätter vi att visuellt utforma appen med mer detaljerade trådramar.
Accentsconagua