Om iedereen weer up to speed te brengen, ik heb een aantal blogs geschreven over het ontwikkelen van een Android app ten behoeve van trainingen bij het honkbal team van m’n zoon. Ik ben begonnen met uitwerking van de initiële ideeën, de verzoeken van de Product Owner (hoofdtrainer), de technische uitdagingen om tot de app te komen zoals deze nu is. Er ontbreekt echter nog één stap, namelijk hoe krijg je de app op de telefoons/ tablets en hoe pas je hem in de praktijk toe.
Zoals ik in een eerdere blog schreef kan je de app testen op virtuele apparaten, een ‘emulator’ en op echte telefoons / tablets door de app via een USB kabel te installeren. Dat werkt in de ontwikkelfase natuurlijk prima, maar op het moment dat je wil uitrollen naar meerdere clients wereldwijd is dat natuurlijk niet meer te doen. En moet je de stap maken naar: (tromgeroffel…)
Google play
Om de app op de Google Play Store te krijgen moet je een ontwikkelaarsprofiel registreren en 25 euro eenmalige fee betalen en dan ben je klaar.
Of toch niet?
Google en ook Apple hebben de afgelopen jaren onder andere te maken gekregen met EU wetgeving waarin privacy geregeld moet worden. Verder is de druk op beide partijen toegenomen om de consument beter te beschermen. Dit wordt gedaan door apps te weren die:
- onnodig veel gegevens verzamelen (voor doorverkoop);
- gebruikt kunnen worden voor illegale praktijken (bijv. stelen van credit card gegevens);
- Kwetsbare mensen beschermen. Denk aan jonge kinderen die zo maar voor honderden euro’s aan leuke dansjes voor hun karakter in spelletjes kunnen kopen.
Als beginnende app programmeur / auteur krijg je dus ook te maken met deze wet- en regelgeving. Voordat je een app kan publiceren moet je een hele reeks aan vragen doorwerken, moet je een privacy statement hebben geschreven en op een website gepubliceerd hebben. Daarnaast moet je ook aangeven of je app geschikt is voor, dan wel gericht is op (jonge) kinderen.
Echter, Google heeft veel van die stappen gestroomlijnd, je hoeft zelf niet een privacy statement te schrijven, je kan een template van Google krijgen. Google helpt je ook met de website, met een paar klikken heb je deze dan ook online.
Sit back, relax, get rich?
En dan is het rustig zitten tot het geld binnenstroomt? Nou nee, je hebt net het financiële en juridische deel afgerond, nu volgt het technische deel. Want je zal vanuit Android Studio een release versie van de app moeten compileren en deze moeten uploaden. Je kan er voor kiezen om een release pipeline op te zetten of de stappen handmatig te doorlopen.
Google heeft bij deze stappen ook meegedacht met de auteurs, het proces is gestroomlijnd om het publiceren zo makkelijk mogelijk te maken. Als geregistreerde auteur heb je toegang tot jouw eigen release omgeving in de Play Store. Hier biedt Google je verschillende opties om je app te testen met een gesloten groep testers, testers uit een land of zelfs de hele wereld.
Sit back…
Nee, nog niet relaxen, want voordat jouw app in de store komt voert Google een (code) review uit. Zo lang deze review nog niet is afgehandeld, kan niemand bij de app. Pas nadat Google de review heeft gedaan is de app in de Play Store te zien. Je krijgt na de review meteen ook een rapportage met problemen die men ontdekt heeft bij de app, zoals potentiële performance problemen bij bepaalde types telefoon, dat de layout op sommige tablets niet goed zal zijn. Je kan er dan zelf voor kiezen om deze problemen op te lossen.
Nadat ik al deze stappen had doorlopen en m’n app eindelijk beschikbaar kwam voor de door mij gekozen besloten testteam, begonnen de problemen pas echt.
Een library die je kan gebruiken bij Android apps heet crash-a-lytics. Zoals de naam zegt, kan je crashes analyseren. En crashen deed de app prima! Deze “crash library” stuurt foutmeldingen van crashes terug naar de ontwikkelaar om op te lossen. Je krijgt in jouw release omgeving van Google Play deze meldingen te zien, op welk type toestel deze fout is opgetreden, en welk Android OS ten tijde van de crash gebruikt werd. Na registreren en vervolgens inloggen, ontstond er een crash op een, na nadere analyse, wel heel vreemde plek. De code zou op die specifieke plek de beschikking moeten hebben over gegevens om de account ook lokaal op te slaan, zodat je ook zonder internet connectie kon inloggen op de app. Maar… bij debuggen bleek dat die gegevens op een emulator er gewoon al wel waren, maar op een fysieke telefoon niet.
#hoedan??
Heel simpel, de code ging te snel. Bij het registreren vraagt de app om gegevens om de gebruiker lokaal op de telefoon te kunnen opslaan. Echter, de aanvraag werd verzonden uit de ‘registreren class’, het antwoord kwam op fysieke telefoons te laat terug en werd niet opgeslagen, want de code was op dat moment al weer terug op ’t inlogscherm. En op die plek in de code kon de app niets meer met deze gegevens.
Er zijn twee opties om dat op te lossen.
- Wachtstap inbouwen. Een wacht van 2 seconden is misschien nog wel te doen, maar krijg je in die 2 seconden wel antwoord terug?
- Classes schrijven die om kunnen gaan met asynchrone gegevens afhandeling.
Met optie 2 los je veel problemen op en leer je weer wat nieuws, dus ik mag weer aan de bak! 😊
Lost dat alle uitdagingen op? Dat lees je in de volgende aflevering van mijn blog.
Met vriendelijke groet, Edwin
