Der Android Experts Day der MobileTech Conference 2012

Real-Life-Bauchschmerzen mit Android – und wie man damit umgeht

Hartmut Schlosser

Mobile-Entwicklung ist anders. Wer die Entwicklung für mobile Endgeräte bisher als bloße Spielart der Web- oder Enterprise-Entwicklung angesehen hat, dürfte spätestens beim Durchfallen der ersten eigenen App in den Bewertungen der App-Stores begreifen, dass im Mobile-Bereich eigene Spielregeln herrschen. Wer wirklich gute, erfolgreiche Apps schreiben möchte, muss profunde Kenntnisse über UI-Design und User Experience mitbringen und tief in die Feinheiten der jeweiligen Mobile-Plattform eintauchen. Der Android Experts Day, der den Android-Track der MobileTech Conference 2012 in Frankfurt abschloss, vermittelte genau diese tiefen Einblicke in die Programmierung mit Android – oder wie Speaker Lars Röwekamp es ausdrückte: Real-Life-Bauchschmerzen mit Android und wie man damit umgeht!

Was nutzt es beispielsweise, wenn eine App im Porträt-Modus perfekt funktioniert, beim Wechsel in den Landscape-Modus aber einfriert? Was tun, wenn der kleine Produkt-Katalog eines Online-Stores schön angezeigt wird, bei erhöhtem Datenaufkommen dann aber das Ruckeln beginnt? Und wie peppe ich eine App, die auf Android 2.2 schon etwas altbacken daherkommt, mit den neuen Features von Android 4.0 auf? Der Android Experts Day bot in seinen vier 90-minütigen Sessions eine breit angelegte Themenvielfalt – garantiert ohne Grundlagenvermittlung!

Gib dem Affen Zucker

Geben Sie Ihr Android Device doch einmal einem Affen in die Hand. Wenn dieser dann wild auf das Gerät einhämmert, sollten Sie sich freuen – denn das ist der beste Stresstest für Ihre App! Diese Metapher stimmte die Besucher des Android Experts Day auf das erste Thema ein: Android Testing. Arne Limburg von Open Knowledge beschrieb die Möglichkeiten, eine Android-Apps auf Herz und Nieren einem Qualitätscheck zu unterziehen. Von der kleinsten Einheit (Unittests auf Methoden-Ebene) über Funktionstests, Abnahme- und Regressionstests bis hin zu Stresstests wurden live verschiedene Szenarien durchgespielt.

Neben den Android-eigenen Test-Frameworks helfen Tools wie Robolectric (Unittestframework), Robotium (Funktionstests, das „Selenium für Android“) und MonkeyRunner (Regressionstests über Python/Jython Sktipts) beim Testen. Außerdem empfiehlt sich das Aufsetzen einer Continuous Integration Umgebung – beispielsweise mit Jenkins und Maven – um einen hohen Grad der Testautomatisierung und Regressionssicherheit zu erreichen. Der initiale Aufwand zum Einrichten einer solchen Umgebung (durchaus „3 bis 4 Tage Arbeit“) mache sich mittelfristig bezahlt, kann man doch schon beim zweiten Projekt dieselben Templates wiederverwenden. Auch die Arbeit mit dem Buildtool Maven könne sich auszahlen, sei aber vor allem bei Projekten mit vielen Dependencys sinnvoll. Bei kleineren Projekten bindet man die abhängigen Ressourcen lieber direkt ein oder zieht sie über Ant nach – denn: „Maven kann einem auch echt Zeit kosten.“

Und dann kam der eingangs erwähnte Affe zu seinem Recht. Mittels des Tools Monkey feuerte Limburg zufällige Events auf eine Android-App ab, die dann auch prompt die Segel streichen musste. Das Gute an dem Tool: Die Reihenfolge der „Affen-Aktionen“ ist reproduzierbar, auch die Wahrscheinlichkeit spezifischer Event-Arten lässt sich konfigurieren, sodass der Affe zur nützlichen Debugging-Hilfe wird.

Android 4 unter der Motorhaube

Lars Röwekamp, Open Knowledge, betrachtete im Anschluss die Neuerungen in Android 4.0. Zwar befindet sich Android 4 schon eine Weile auf dem Markt, doch aus Abwärtskompatibilitätsgründen dürften viele Entwickler noch nicht unbedingt alle neuen Features nutzen. Das Themenspektrum reichte von Fragments, UI-Verbesserungen, NFC, Wifi Direct bis hin zu neuen Schnittstellen wie das Social API und das Calendar API. Mit dem UI Loader lässt sich beispielsweise das asynchrone Laden von Daten bewerkstelligen – zwar kein echtes Lazy Loading, aber immerhin ein Laden, das die UI nicht blockiert. Gefühlt wird die App dadurch performanter – was Lars zu dem schönen Merkspruch veranlasste: „Die gefühlte Performance ist nicht gleich der realen Performance“. Das neue Architekturkonzept der Fragments sei zwar interessant, aber an einigen Ecken und Enden noch optimierungsbedürftig. Wohl auch Google selbst müsse sich noch an die neuen Architekturparadigmen gewöhnen, meinte Lars, und sagte voraus, dass die nächsten Android Updates 4.0.x mehr Klarheit schaffen werden.

A fool without a tool

Wer erfolgreiche Android-Apps programmieren möchte, muss sich gut mit den Entwicklertools auskennen. Während das Google SDK Team fast jeden Monat eine neue Version des Android SDKs veröffentlicht, hält die Dokumentation leider nicht immer Schritt. Dominik Helleberg von der inovex GmbH demonstrierte deshalb die versteckten Juwelen der Android Development Tools, denn gerade bei der Suche nach Performance- oder Speicherproblemen können die Tools den Arbeitsalltag erheblich erleichtern.

Zunächst ging Dominik auf die Layout Tools ein. Über einen WYSIWYG-Editor lassen sich Android UIs komfortabel via Drag-n-Drop erstellen. Wer sich dieses Werkzeug in einer früheren Version einmal angeschaut hat, und es als unbrauchbar zur Seite gelegt hat, sollte jetzt nochmal einen Blick riskieren. Das Tool hat große Fortschritte gemacht, und insbesondere der generierte Code ist extrem clean. Dominik demonstrierte das Eclipse Memory Analyzer Tool (MAT) mit dem sich auch in Android Speicherlecks aufspüren lassen. Die Performance lässt sich mit den Tools traceview, systrace und Tracer messen, wobei traceview am nützlichsten dabei ist, wenn es um die Häufigkeit von Methodenaufrufen und die Schnelligkeit deren Ausführung geht. Tracer ist eher für OpenGL-Programmierer interessant und zeigt GL-Kommandos Schritt für Schritt an.

Grundsätzlich ist das Messen von Performanz und Speicherverbrauch gerade im Mobile-Bereich von höchster Bedeutung: Nichts bringt einem schlechtere App-Store-Bewertungen ein, als langsame Apps oder blockierende User Interfaces!

Lessons Learned

Zum Abschluss brachten die drei Speaker ihre Lessons Learned auf den Punkt: große Datenmengen verarbeiten mittels Integration eines Datenbankgerüsts und Lazy Nachladen von Daten on-the-fly, Sicherheit der Daten durch Verschlüsselung mit SQLCipher, optimale Nutzung der nebenläufigen Programmierung in Android und das Meistern der Android-Fragmentierung, die sich bei genauerem Hinsehen als Mythos erweist: Nimmt man die Android-Versionen 2.2, 2.3 und 4.0 zusammen, erhält man nämlich eine Marktabdeckung von über 90 Prozent.

Das Fazit: In welche Probleme man in der Mobile-Welt läuft, ist auch dem Enterprise-Web-Entwickler zunächst einmal unklar. Umso wichtiger ist es, diese spezifischen Bedingungen des Mobile-Bereichs kennenzulernen und diese auch mit dem Kunden zu besprechen – noch bevor die Verhandlungen über Preise beginnen. Denn oft sind einfach scheinende Features im Mobile-Bereich schwierg zu realisieren. Wenn man Aufwände klar mit dem Kunden bespricht, werden vorher „unabdingbare“ Features oft zu „Nice to have – but too expensive“.

Bewegt man sich als Java-Enterprise-Entwickler auf die Android-Plattform zu, genießt man durch die gleichbleibende Java-Umgebung zwar einen gewissen Wiedererkennungswert. Dennoch sollte man nicht meinen, die bekannten Design Patterns aus der Enterprise-Welt einfach auf die Mobile-Welt übertragen zu können. Oft lenkt dies von den eigentlichen Problemen ab, denn trotz der enormen technischen Fortschritte der mobilen Devices haben wir es immer noch mit limitierten Ressourcen, prekärer Konnektivität und eigenen Hardware-Gegebenheiten und Bedienmuster zu tun.

Die Speaker raten deshalb jedem, der sich als Android-Entwickler positionieren möchte, sich beim Programmieren einer App stark am Lebenszyklus von Objekten bzw. Activities zu orientieren – etwas, das man als Nicht-Mobile-Entwickler so nicht kennt. Man muss eben verstehen lernen, was mit einer Activity passiert, wenn man die Orientierung des Gerätes ändert und vom Landscape- in den Porträtmodus wechselt.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.