Van iOS – naar Android app development: mijn ervaringen

Van iOS – naar Android app development: mijn ervaringen

Collega Jille hield zich voorheen voornamelijk bezig met iOS app ontwikkeling, maar heeft nu ook zijn pijlen gericht op het ontwikkelen van native Android apps. Hieronder zijn ‘reis’ van native iOS app developer naar native iOS- én Android app developer. 

Dit artikel verscheen eerder in het Engels op Medium.com.


Laat ik maar meteen met de deur in huis vallen: Android development is fundamenteel anders dan ontwikkelen voor iOS. Toen ik bij beeproger solliciteerde had ik alleen ervaring met het maken van Native iOS applicaties, maar hier kreeg ik ook de kans om Android apps te bouwen.

Ik merkte dat er een aantal fundamentele verschillen zijn, waar je zeker tegenaan gaat lopen als je ook de stap van iOS naar Android (of vice versa) wilt maken. Vandaar dit artikel.

Ik schreef de apps in Swift en Kotlin, en hoewel deze talen qua syntax veel gemeen hebben is het het verschil tussen APIs dat schakelen tussen de twee platformen lastig maakt. Android gaat bijvoorbeeld compleet anders om met views dan iOS.

Libraries

Ik begin met een voorbeeld: ik werkte aan een app die foto’s moest laten zien. Klinkt simpel, hoort het ook te zijn; veel apps hebben foto’s! In iOS maak je een UIImageView en daar voeg je UIImages aan toe. Toen ik aan de Android versie begon probeerde ik eerst dezelfde aanpak.

Ik schreef data klasses met onder andere een Bitmap. Deze laadde ik vervolgens in een ImageView. Het resultaat: een gigantische hoeveelheid Out of Memory Exceptions wat resulteerde in het besteden van een heleboel uren aan memory debugging omdat het geheugen van de Bitmap objecten niet losgelaten werd.

Het resultaat van uren aan memory debugging 🙂

Hiervoor heb ik nooit met memory management hoeven te werken (en nu technisch gezien nog steeds niet) dus ik begon mijn zoektocht op StackOverflow (SO). Op een gegeven moment kreeg ik het voor elkaar de memory footprint van de app flink te verlagen.

Dit is gelukt door op het juiste moment de recycle methode te gebruiken op Bitmaps die niet meer gebruikt zullen worden. Daarna ruimen calls naar System.GC (garbage collection) een heleboel allocaties op. Het resultaat is hierboven zichtbaar.

Tijdens mijn zoektocht door talloze SO pagina’s heb ik de naam Picasso vaak voorbij zien komen. Dit is een image library die hetzelfde probleem oplost als waar ik tegenaan liep, en een aantal vergelijkbare dingen aanpakt.

Na een flinke tijd geworsteld te hebben met memory debugging, hakte ik de knoop door en installeerde ik de library. Ik stond versteld: niet alleen verbeterde dit mijn memory footprint enorm door dingen zoals het cachen van afbeeldingen, ik kon hierdoor ook een groot deel van m’n code voor het downloaden van deze afbeeldingen de deur uit doen.

Sayonara, ImageRequest.

Door de Picasso library te gebruiken heb ik bovenstaande klasse kunnen verwijderen en alle code betreffende het verwerken van afbeeldingen (vergroten, schalen en rond maken) kunnen vervangen met een regel code:

Mijn ogen waren geopend. Als ik mijn leven zoveel makkelijker kan maken met één library, hoeveel geweldige libraries staan me dan nog te wachten? Dezelfde dag verving ik al mijn netwerk code met gebruik van de OkHttp library, wat de memory footprint nog verder verbeterde en ervoor zorgde dat ik weer een heleboel code kon verwijderen.

API Levels

Hier ben ik flink tegen de lamp gelopen. Het is iets waar je best snel aan went, maar desalniettemin een struikelblok voor beginnende developers. Als developer ken je dat gevoel dat je een antwoord vindt voor exact dat probleem waar je tegenaan loopt. Als Android developer weet je ook hoe het voelt om daarna in de documentatie te lezen dat je voor de oplossing een hoger API level nodig hebt dan het laagste niveau dat je ondersteunt in je app.

Hierop volgt de speurtocht naar de precieze werking van de oplossing, zodat je deze na kunt proberen te bouwen. Ik wilde bijvoorbeeld een stuk code uitvoeren als een AnimatorSet klaar is met het afspelen van zijn animatie:

Een extension functie voor de AnimatorSet klasse.

Vanaf API level 24 kun je het resultaat van de getTotalDuration methode gebruiken in een postDelayed blok om code uit te voeren als de animatie klaar is. Helaas moest mijn app een lager API level ondersteunen, en dus schreef ik de oplossing hierboven.

Mooie bonus: bovenstaande extension functie kan ook tussen animaties aangeroepen worden tijdens het maken van het AnimatorSet object, om code uit te voeren op bepaalde momenten in de animatie.

Dit heeft me een waardevolle les geleerd: neem wat meer tijd als je op zoek bent naar oplossingen op SO. Het zou heel goed kunnen dat een antwoord uit 2013 niet meer relevant is, en vaak zijn recentere antwoorden een stuk verder op de pagina pas te vinden.

Een voorbeeld is toen ik JSON probeerde te parsen in de app. Dit is een van de kernelementen die in de app moeten zitten, omdat dit de manier is waarop de app communiceert met de backend die ik ervoor gemaakt heb. De eerste resultaten op Google schreven over BufferedReaders en StringBuilders; een heleboel boilerplate code met eigenlijk een hele simpele taak, en daarnaast staat je memory debugger vervolgens vol met Strings. Als ik iets langer had gezocht en net iets verder had gescrolld, had ik de suggesties gezien om libraries zoals GSON en OkHttp een kans te geven.

Wrap-up

Ik zou kunnen proberen een stuk te schrijven over de view lifecycle, en de interface builder van Android Studio, maar ik vind dat ik daar nog niet genoeg van gebruik. Ik ben gewend aan de terminologie van iOS development en Xcode, en bij Android werkt alles gewoon net even iets anders.

De meest waardevolle les die ik geleerd heb is dat je open minded moet blijven. Het is makkelijk om met tunnelvisie aan de slag te gaan met een opdracht, en een oplossing te vinden die lijkt op hoe je hetzelfde probleem aan zou pakken op iOS, maar zo simpel is het nou eenmaal niet.

Je moet het niet zien als het refactoren van iOS naar Android, maar als het vinden van oplossingen voor nieuwe problemen die op elkaar lijken, en die goed werken voor Android. Of dat het gebruik is van een library of het schrijven van je eigen oplossingen, je moet niet bang zijn om nieuwe dingen te proberen.


Vond je dit een interessant artikel?

Delen kan met één druk op de knop:

[shareaholic app=”share_buttons” id=”27605453″]

Gerelateerde artikelen: