Connected Android Apps
Whitepaper
Inleiding
Nspyre Postbus 85066 3508 AB Utrecht T 088 - 827 50 00 F 088 - 827 50 99 www.nspyre.nl
Dit jaar zou wel eens het jaar van de tablet kunnen worden. De mobiele markt heeft met de komst van de tablet al laten zien dat mobiliteit niet stopt bij het uitbreiden van functionaliteit op smartphones. Tablets en andere draagbare apparaten zouden zomaar de klassieke desktop of laptop kunnen gaan vervangen. Ook het Android platform heeft zich de laatste jaren hierin bewezen. Voorheen werd getwijfeld aan de volwassenheid van Android, echter is er met de komst van versie 4.0 een completer, sneller en stabieler platform voor mobiele apparaten ontwikkeld. Android is inmiddels zo nadrukkelijk aanwezig dat elk bedrijf of persoon die zijn applicatie (App) serieus neemt deze minimaal uitbrengt voor Android apparaten. Mede omdat is gebleken dat Android gebruikers meer gebruik maken van hun Apps dan van de Android internet browser. (1) In dit artikel staan enkele afwegingen die men dan moet maken met de bijhorende argumenten en tips.
Client-server Op het Nspyre Android seminar in 2011 is gebleken hoe veel interesse er vanuit de markt is voor ‘connected’ Apps. Meer dan 60% van de bezoekers heeft aangegeven dat zijn toekomstige App een client-server verbinding tot stand zal brengen. Echter, in werkelijkheid blijkt dit getal voor de Android Market vele malen lager te liggen. Volgens onderzoek schijnt dit zelfs onder de 20% te zijn.(2) Dit is niet vreemd wanneer men kijkt naar de Android Software Development Kit (SDK) en de Android Developers website. Hier is duidelijk te zien dat de grootste tekortkoming tegenwoordig niet meer het native development of de ontwikkelomgeving is, maar meer het gebrek aan informatie over het gebruik van een internet verbinding in de App. Uit bovenstaande cijfers zou opgemaakt kunnen worden dat het maken van een 'connected' App vaak gewenst is maar in de praktijk lastig blijkt. Gelukkig zijn ze daar bij het Android team inmiddels achter want er is de laatste maanden een aantal nieuwe, netwerk gerelateerde artikelen op de ‘Android Developers’ website geplaats. Zo is er een nieuwe basic training: ‘Performing network operations’ en nieuwe advanced trainingen zoals: ‘Transferring data without draining the battery’ en ‘Syncing to the Cloud’.
1
Communicatie ontwerp De term communicatie is erg breed. Ook als het gaat om data uitwisseling tussen een Android apparaat en een server die via het internet verbonden zijn. Voordat er een goed ontwerp gemaakt kan worden is het van belang goed te kijken naar de volgende punten: de hoeveelheid data, de richting waarin deze data verloopt en de frequentie waarmee de data gesynchroniseerd wordt. Bijvoorbeeld, eens in het uur dienen enkele bytes opgehaald te worden om de klok te synchroniseren. Of, men wil elke 5 minuten de laatste Facebook berichten inclusief foto's ophalen en deze vervolgens op het apparaat bewaren. Tevens zijn de schaalbaarheid en de uitbreidbaarheid ook erg van belang bij het ontwerp van de App. Het is belangrijk om vooraf na te denken over het eventueel toenemen van gebruikers of het veranderen van de data structuur zodat hier rekening mee gehouden kan worden.
Architectuur Allereerst is het maken van een goede architectuur belangrijk. Zo moeten bijvoorbeeld de Activities (Android User Interface component voor een scherm) zo veel mogelijk losgekoppeld zijn van de gegevens en van de logica. Voor de meeste programmeurs is dat beter bekend als het design-pattern Model-View-Controller ofwel MVC. Bij Android is de layout en zijn user controls de 'view' en de 'controller' is de Activity die met zijn logica weet hoe hij de 'view' kan updaten. Vandaar de classname View waar de meeste user controls van afleiden. De 'controller' maakt vervolgens gebruik van de interfaces op een Service of een ContentProvider. Delen van deze interfaces staan al vast maar de programmeur kan hier gemakkelijk nieuwe interfaces aan toevoegen. Als er voor een Service gekozen is kan er eventueel ook gebruik gemaakt worden van Intents of van Android Interface Definition Language (AIDL) zodat de Service ook in een eigen proces kan draaien. Een los proces betekent ook dat meerdere Activities gebruik kunnen maken van die interfaces en maakt caching en lifecycle makkelijker beheersbaar. Het gebruik van een Service of ContentProvider zijn twee verschillende methoden om de data ofwel het 'model' te abstraheren van het gebruik ervan. Deze componenten hebben zelf dan ook geen user interface (UI). De Service is meer bedoeld voor het aanbieden van één of meerdere functionele interfaces en eventueel het afhandelen van taken op de achtergrond. De ContentProvider is bedoeld voor het aanbieden van grote hoeveelheden data op een generieke manier. Zodra de Activity op het scherm zichtbaar is kan de ‘view’ de juiste informatie op het scherm zetten door data uit het 'model' te halen. Zodra het 'model' veranderd, omdat er bijvoorbeeld een update is opgehaald over het internet, zal deze de ‘view’ op de hoogte brengen van de veranderingen. Zorg er dus voor dat in de user interface, en op het data interface niveau, geen referenties zitten naar het gebruikte protocol of uitwisselingsproces.
2
Omdat het updaten van het 'model' en het updaten van de 'view' op aparte threads moet gebeuren is het handig om hiervoor de AsyncTask te gebruiken. Dit maakt het de ontwikkelaar op het gebied van threading een stuk makkelijker. Het is zelfs mogelijk om de gebruiker van de voortgang op de hoogte te stellen door de extra aanwezige callback methoden.
SOAP vs. REST Een 'model' moet zichzelf kunnen updaten of laten updaten door het raadplegen van een server via het internet. Voor dit proces zijn er diverse mogelijkheden die onder te verdelen zijn in SOAP en REST. SOAP staat voor Simple Object Access Protocol en is een techniek die al wat langer bestaat en vaak gebruik maakt van een framework die hele classes kan genereren op basis van de interface contracten die opgesteld zijn. SOAP zorgt er voor dat een object aan beide kanten van de verbinding kan bestaan. REST staat voor Representational State Transfer. Deze techniek is niet meer dan de conclusie dat bestaande internet technieken zoals URI's met GET en POST prima voldoen voor toekomstige Apps. Het maken van de keuze tussen deze twee is afhankelijk van de toepassing en eventueel bestaande servers. Vanwege performance, standaardisatie of ontwikkeltijd kan voor andere vergelijkbare aanpakken gekozen worden. Voor het maken van deze keuze zouden de volgende voor- en nadelen kunnen helpen. Voordelen REST Op de eerste plaats is REST lichtgewicht. Dit betekent dat er nagenoeg geen overhead in de data zit, omdat de intelligentie om het te kunnen parsen bij de client en server aanwezig (moeten) zijn. Ook is de verbinding hierdoor makkelijker te debuggen, omdat de data redelijk leesbaar is. Voor het ontwikkelen met een REST ontwerp zijn geen extra tools of frameworks nodig wat de leercurve korter maakt dan bij SOAP. Doordat er bij REST gebruik wordt gemaakt van URI's en mime-types kan men de data ook in meerdere formats aanbieden. Zo kan er bijvoorbeeld HTML, XML of JSON worden teruggegeven aan de hand van het mime-type zodat dezelfde server te benaderen is door verschillende toepassingen. Ook staat deze methode aan de hand van de URI of mime-type bestaande caching mechanismen van webservers toe. Zo kan men bijvoorbeeld met enkele regels configuratie alle plaatjes van een bepaalde extensie aan de kant van de gebruiker laten bewaren. De afweging tussen XML, CSV en JSON is grotendeels te maken op basis van leesbaarheid en data overhead. Wanneer men al gebruik maakt van een Linux server met Apache, PHP en MySQL (LAMP) dan is REST een voor de hand liggende keuze. Het gebruik van REST is mogelijk op vrijwel alle client oplossingen. Vrijwel elke taal, SDK of library heeft wel de mogelijkheid om een REST server te benaderen.
3
Voordelen SOAP Een voordeel van SOAP is dat men automatisch beter object georiënteerd gaat werken waardoor de interfacing vervolgens makkelijker aan te passen en uit te breiden is. De tools en frameworks die er voor SOAP zijn zorgen er voor dat de interfaces de contracten nakomen. Hiermee zorgt men er voor dat het eenduidig is hoe er mee gecommuniceerd moet worden en is de interfacing ook strikter waardoor fouten eerder worden ontdekt. De tools bij SOAP zorgen voor code generatie en vergemakkelijken toekomstige uitbreidbaarheid. Voor Android is er de 'ksoap2-android' library maar vergelijk dit niet met grote SOAP frameworks zoals die uit Microsoft Visual Studio. Voor een kleiner bedrag aan licentiekosten heeft men ook 'WSClient++'. Als men al gebruik maakt van bijvoorbeeld een Windows Server kan men er voor kiezen om deze met SOAP te benaderen. Wanneer men echter nog geen bestaande server heeft is het de moeite waard om eens te kijken naar de App Engine en Cloud to Device Messaging. Met behulp van een extra Google Eclipse plugin bouwt men in zeer korte tijd een eigen SOAP API. Deze plugin integreert weer volledig met de rest van de Android SDK. Met behulp van de plugin genereert men dus de backend/server software en de interfaces (RPC API’s) voor Android en andere clients zoals bijvoorbeeld een Ajax gebaseerde website. De SOAP server kan vervolgens als Google cloud service gehost worden waardoor je een schalende oplossing hebt die bij weinig gebruik ook nog eens gratis is.
Beveiliging Wanneer de App gevoelige informatie communiceert is het van belang dat er goed wordt gekeken naar de beveiliging. Naast code-obfuscation en beveiligde data opslag is de beveiliging van de verbinding ook belangrijk. Over deze verbinding worden namelijk de login gegevens van een gebruiker verstuurd. De login gegevens zijn het makkelijkste in te voeren en op te slaan door gebruik te maken van de AccountManager van Android. Met dit mechanisme kan men alle of specifieke type accounts opvragen die onder de Android instellingen pagina genaamd 'Accounts & Synchroniseren' staan. Wanneer de App niet het juiste type account heeft gevonden kan deze automatisch een Activity oproepen die het invullen van login gegevens afhandelt zoals gebruikersnaam en wachtwoord. Vervolgens kan de App telkens dit account opvragen zonder weer de gebruiker te moeten vragen om het wachtwoord. Hiermee is het eventueel zelf onbeveiligd opslaan van wachtwoorden omzeild. Om de verbinding te beveiligen tegen verschillende Hack methoden zoals bijvoorbeeld man-in-the-middle is encryptie van de verbinding het belangrijkste. Dit maakt namelijk afluisteren haast onmogelijk, sniffers zinloos en vele andere hacking methoden onbruikbaar. Encryptie is tegenwoordig standaard aan het worden voor communicatie in de vorm van HTTPS. HTTPS is gelijk aan HTTP maar dan over een veilige transport laag genaamd Transport Layer Security (TLS). TLS is de opvolger van Secure Sockets Layer
4
(SSL) maar wordt vaak nog steeds SSL genoemd. Al deze afkortingen willen niets anders zeggen dat de data voor de App versleuteld wordt verzonden waardoor zonder het kraken van deze versleuteling niet te zien valt wat de data nou daadwerkelijk is. Android bied alle benodigde functionaliteit voor het gebruik van SSL en TLS aan in de SDK.
Synchronisatie Omdat elke App een iets andere aanpak vergt kan men niet de ultieme ‘Connected App’ aanpak voorschrijven. Voor data die vaak wijzigt kan er beter niet gekozen worden voor het persistent maken van de data. Simpele runtime caching kan eventueel wel worden gedaan in de Service. Wanneer er dan tussen Activities wordt gewisseld is de data nog direct beschikbaar tot het afsluiten van de Service. Data wordt alleen opgehaald wanneer die nodig is (Lazy loading). De ´controller´ zal bijvoor beeld gebruik maken van de functionele interfaces die men in AIDL heeft vast gelegd. Eventueel kan men hier een eigen ServiceClient maken die de verbinding met de Service afhandelt. Voor het asynchrone gedrag van dit ontwerp is het goed om op elke functionele interface een ´registerListener´ of ´registerHandler´ te maken. De Service zal na het ontvangen van de data de juiste Callback functie aanroepen op deze Listener of Handler. De Handler zal op zijn beurt de juiste View updaten. Bij blocking/synchrone functies is het verstandig om de AsyncTask te gebruiken.
5
Wanneer de hoeveelheid data langzaam in de tijd groeit of weinig zal wijzigen is het beter om het te synchroniseren in de App. Hiervoor gebruik men een SyncAdapter die door het Operating System (OS) zal worden aangeroepen om de data in de ContentProvider te synchroniseren met de server(Preloading). Wanneer de App de data wil weergeven zal deze reeds aanwezig zijn. De ContentProvider zal de data ontvangen en opslaan in bijvoorbeeld een lokale SQLite database. Beide methoden kunnen ook naast elkaar bestaan en dan gebruik maken van dezelfde ServerProxy. De ServerProxy is de class waar men typisch de REST of SOAP methoden implementeert zoals een Add of Remove functie. In geval van SOAP zal men hier de functies en data omzetten naar iets wat over het internet gaat (Marshalling) en het omzetten van de data die terugkomt (Unmarshalling). In geval van REST is dit de plaats waar een GET of POST wordt gedaan. Tevens is de ServerProxy de plaats waar eventueel de AccountManager aangesproken zou kunnen worden.
Conclusie Android heeft inmiddels een uitgebreide SDK met daarin een degelijke set aan componenten. Het is echter nog niet gemakkelijk om daarmee een connected App te maken. Gelukkig zijn er al vele software engineers en hobbyisten die hun bevindingen hebben gedeeld op het grote internet zodat toekomstige engineers nu prima uit de voeten kunnen met de SDK. Wat betreft het communicatie mechanisme is SOAP minder geschikt voor Android wanneer men niet gebruik maakt van een goed framework. Wanneer men bijvoorbeeld al van Windows servers gebruik maakt zal men eerder kiezen voor SOAP vanwege de tooling voor het maken van webservices. Wanneer men gebruik
6
maakt van Linux servers zal men eerder voor REST gaan in combinatie met LAMP. Deze oplossing is ook meer geschikt wanneer men naast de App ook met een website als UI dezelfde interface of server wil benaderen. Wanneer er nog helemaal geen servers of bestaande implementaties zijn dan is App Engine de uitkomst voor het maken van een multi platform oplossing. Android bied dus voldoende keuze en vrijheid aan de ontwikkelaar.
Bronnen statistische gegevens: 1. Nielsen, juni 2011, Telecom Research & Insights: “Smartphone Analytics” 2. Kinvey, augustus 2011, Mobile Cloud Backends: “3/4 of iOS and Android apps don’t connect to a backend”
Voor meer informatie Nspyre TG Android Luuk van Hal T. +31(0)88 8275 100 E.
[email protected] W. www.nspyre.nl Gerelateerd Android nieuws? Klik hier.
7
