Share
Wat je gaat creërenDe interactie met een API is tegenwoordig een belangrijk onderdeel van webontwikkeling en -ontwerp. API's bieden een rijke, dynamische ervaring in de browser. In plaats van statische markeringen en afbeeldingen, kunt u dynamisch gegevens pushen en ophalen van een server en deze in de browser weergeven op basis van de ervaring die u voor de gebruiker wilt bieden.
In deze zelfstudie bouwen we een eenvoudig voorbeeld van een API-gebaseerde app. Met behulp van de iTunes API nemen we de URL van elke iOS- of Mac-app en geven we het pictogram met de volledige resolutie recht in de browser. Deze specifieke app is misschien niet meteen nuttig voor u, maar wat u onderweg leert, kan op allerlei scenario's worden toegepast.
De meeste goed ontworpen iOS- en OSX-apps bieden activa met een hoge resolutie voor hun pictogramillustraties. Natuurlijk lijken die pictogrammen slechts 150 × 150 pixels groot te zijn op je iPhone-springplank of je OSX-dock, maar om rekening te houden met netvliesschermen en verschillende dimensioneringsvereisten voor het besturingssysteem, vraagt Apple dat app-makers een pictogram met een hoge resolutie leveren items, zo groot als 1024 × 1024 pixels! Aan de linkerkant ziet u bijvoorbeeld het Tweetbot voor Mac-pictogram zoals het ongeveer in uw OSX-dock zou verschijnen. Rechts is de afbeelding met de volledige resolutie:
Apple maakt deze middelen toegankelijk via de iTunes API. Dus als je ooit de hoge resolutie, full-sized kunstwerken wilt, kun je dat! Het enige wat u nodig heeft, is de ID van de app. Vervolgens krijgt u een verzoek om de API en krijgt u een heleboel informatie over de app, inclusief een link naar de illustraties met de hoogste resolutie die de winkel beschikbaar heeft.
In deze zelfstudie gaat het niet zozeer om het leren van de iTunes API, maar om het leren van enkele basisbegrippen achter het bouwen van een dynamische webapp die inhoud retourneert uit een API. Zodra u de basis heeft geleerd voor het interfacen met een API, kunt u doorgaan met het bouwen van uw eigen gepersonaliseerde websites met behulp van API's van derden, zoals Dribbble of Twitter.
Hieronder volgt een kort overzicht van de concepten die we in deze tutorial behandelen om het eindproduct te bereiken:
Om te begrijpen wat we gaan bouwen, beginnen we met het beschrijven van de basiservaring van onze kleine app. Als dat is voltooid, kunnen we wat specifieker worden door de bijbehorende onderdelen op te sommen.
Om de componenten van de app met draad te verbinden, hebben we een lijst nodig met de basisfunctionaliteit en -ervaring van de app:
Nu we een basiskennis hebben van wat we willen dat de app doet, kunnen we de verschillende onderdelen ervan bedraden. Houd er rekening mee dat we willen dat dit een responsieve web-app is, dus we zullen ervoor zorgen dat onze onderdelen zodanig worden ontworpen dat ze responsief op en neer kunnen gaan.
hoofd: Bovenaan de pagina staat een gestileerde tekst die de naam van de app weergeeft, samen met een korte beschrijving van wat deze doet. "Gimmie Dat iCon" is de dwaze naam die ik heb bedacht voor onze app.
Invoer: We moeten de gebruiker een manier bieden om een link naar de app in te voeren waarvan hij de illustraties van het pictogram wil. Hiervoor zullen we een eenvoudig invoerveld en een verzendknop direct onder de kop toevoegen.
uitgang: Zodra een geldige link is opgehaald van de gebruiker, hebben we een spatie nodig om de illustraties van het pictogram weer te geven die zijn opgehaald via iTunes. Dus we zullen een plek creëren voor dat recht onder het invoerveld.
Dat is het zo'n beetje. We hebben nu alle basiscomponenten die we nodig hebben om een link van de gebruiker op te halen en informatie weer te geven die terugkomt van de iTunes API.
Er is nog een andere belangrijke factor die we moeten overwegen in onze wireframe-fase: de verschillende toestanden van onze samenstellende delen. Onze kleine app zal op verschillende tijdstippen in verschillende staten zijn. We weten bijvoorbeeld dat we de illustratie van het pictogram moeten weergeven die door de iTunes API wordt geretourneerd, daar hebben we al rekening mee gehouden. Maar wat als de API een fout retourneert, wat doen we dan? Of wat als de gebruiker een slechte link invoert? We moeten rekening houden met de verschillende staten waarin onze app zich bevindt, afhankelijk van de staat van uitvoering. Aangezien onze app vrij eenvoudig is, hebben we slechts de weinige use cases die we moeten behandelen:
Geen status: Wat gebeurt er wanneer de gebruiker voor het eerst op onze webpagina komt? Er is geen pictogramafbeelding om weer te geven omdat ze nog geen URL hebben ingevoerd. Dus we hebben een soort van vriendelijke "nultoestand" nodig die zegt "hey, je hebt nog geen link ingevoerd. Ga je gang en voer een in, dan zullen we het pictogram hier weergeven. "
fouten: Het is heel goed mogelijk dat er een paar fouten optreden tijdens de uitvoering van onze app. De gebruiker kan bijvoorbeeld een ongeldige URL invoeren. Of de iTunes API kan slechte gegevens of helemaal geen gegevens retourneren. We moeten rekening houden met deze gevallen in het ontwerp van onze app, dus de gebruiker vraagt zich niet af wat er mis ging. Dus we zullen een manier ontwerpen om een foutmelding weer te geven (waarvan de tekst zal veranderen, afhankelijk van de fout).
Bezig met laden: Omdat we met een API werken, gebeurt niet alles ogenblikkelijk. De computer van de gebruiker moet een aanvraag indienen bij een server van een derde partij, die het verzoek moet berekenen en de informatie moet terugsturen. Dit kan tot enkele seconden duren. We zorgen er dus voor dat het ontwerp van onze app een manier biedt om te communiceren dat de inhoud wordt geladen. Op die manier raakt de gebruiker niet gefrustreerd en verward door een statisch scherm waar niets aan de hand is (hoewel de inhoud op de achtergrond wordt geladen).
Dat is het! We hebben al onze verschillende onderdelen en hun verschillende toestanden behandeld. In de volgende zelfstudie gaan we verder met het visueel ontwerpen van de app met meer gedetailleerde wireframes.
Accentsconagua