material/Examensarbeit Spittank/source/chapters/070-Android/070-main.tex

\chapter{Konkrete Umsetzung mit Android}\label{chpAndroid}

\section{Untersuchte Umsetzungsmöglichkeiten}

	\subsection{Automatisierung}
		Für Android sind verschieden Apps zur profil- oder regelbasierten Automatisierung des Systems erhältlich, die allesamt sehr zuverlässig funktionieren. Hervorzuheben sind die Apps \textit{Llama -- Location Profiles}, \textit{Locate} und \textit{Tasker}. Allen gemein sind die umfangreichen Möglichkeiten zur automatischen Reaktion auf bestimmte Ereignisse. Durch die Verfügbarkeit von Variablen und Kontrollstrukturen sind zwar grundsätzlich einige Betrachtungen unter der Perspektive der Veränderung der Wirklichkeit möglich. Tatsächliche Programmierung ist dies jedoch nicht, Objektorientierung ist schon gar nicht möglich. Dennoch kann dieser Ansatz für den Informatikunterricht interessant sein, denn alle Apps dieser Art können auch Skripte aufrufen, die etwa mit dem \gls{SL4A} entwickelt wurden.

	\subsection{Programmieren für Android}
		Unabhängig von den weiteren Ansätzen ist wie bei allen Plattformen die Entwicklung von mobilen Apps mittels stationärer Informatiksysteme möglich. Dies erfolgt grundsätzlich mittels der androidspezifischen Java-Variante, deren kompilierter Code nicht zum Bytecode von Standard-Java kompatibel ist. Hierzu stehen das umfangreiche \gls{SDK} und für rechenintensive Anwendungen zusätzlich das \gls{NDK} zur Verfügung, welches die Nutzung von C- und C++-Code erlaubt. Zum \gls{SDK} gehören diverse Werkzeuge, etwa eine auf \textit{Eclipse} aufbauende Entwicklungsumgebung, aber auch ein Emulator und die äußerst nützliche \gls{ADB}. Mit letzterer können \zb ein an den Entwicklungsrechner angeschlossenes Android-Gerät ferngesteuert und Dateien übertragen werden. Dies kann auch gelegentlich für die weiteren Ansätze nützlich sein. Erzeugte Apps (bis auf native Teile)  laufen unter Android jeweils in einer eigenen \gls{Dalvik}, abgeschottet von den übrigen Programmen. Da die Entwicklung für die Systeme bereits ausgeschlossen wurde, sind diese Details zunächst nur von begrenztem Interesse für den Unterrichtseinsatz.
	
	\subsection{Java}
	
		Inzwischen ist es auf Android-Geräten jedoch möglich, reguläre Apps komplett auf den Geräten zu erstellen, zu kompilieren und in ein App-Paket zu verpacken. Mit \textit{AIDE} steht hierzu sogar eine komplette Entwicklungsumgebung zur Verfügung, die mit Eclipse-Projekten kompatibel ist und sich somit in das \gls{SDK} einfügt. Dieser Ansatz hat auf allen getesteten Systemen reibungslos funktioniert. Die Vorteile liegen klar auf der Hand: Es besteht vollständiger Zugriff auf alle API-Funktionen und die erzeugten Apps lassen sich auf nahezu alle Android-Systeme transferieren sowie dort ausführen, ohne weitere Laufzeitkomponenten zu benötigen. Zudem bietet AIDE intensive Eingabehilfen, die die Programmierung erleichtern, etwa Autovervollständigung. So kann es kaum verwundern, dass der Autor nach Bekanntwerden dieses Ansatzes sein bisheriges Konzept verwarf und versuchte, diesen Ansatz für den Unterrichtseinsatz fit zu machen. Dass hier nur Java, nicht aber Python zur Verfügung stand, das nach den Kriterien nach Linkweiler \citep[S.~22~ff.]{LinkweilerDA2002} weniger gut geeignet erscheint, schien verschmerzbar zu sein.
		
		Leider waren die Versuche mit diesem Ansatz vergleichsweise fruchtlos. Es ergaben sich nämlich massive Probleme, die aus didaktischer Sicht nicht ignoriert werden können. So ist derzeit die vollständige Verkapselung der Android-API in Java nicht möglich. Grundlegende Elemente, etwa die bei Android üblichen Activitys, also Bildschirmansichten, müssen zumindest von den Android-Klassen abgeleitet werden. Dies führt dazu, dass die Autovervollständigung von AIDE faktisch unbrauchbar wird und ihre Ergebnisse mehr verwirren als helfen, da alle geerbten Attribute und Methoden in der Liste auftauchen. Außerdem muss für jede App eine Manifest-Datei erstellt werden, die alle wichtigen Bestandteile der App umfasst. Diese Dateien liegen im XML-Format vor und müssen manuell bearbeitet werden, was erweiterte Kenntnisse über strukturierte Dokumente voraussetzt. Eine didaktische Reduktion erscheint kaum möglich. Am schwersten wiegt jedoch die -- besonders auf den wohl in Schulen einzusetzenden, günstigeren Geräten -- extrem lange Dauer, die zum Testen des Codes erforderlich ist. Ist neben dem Compilieren doch noch das Verpacken, Signieren und Installieren notwendig. Dies geschieht zwar fast vollständig automatisch, kann aber selbst auf schnelleren Systemen einige Minuten dauern.
	
	\subsection{Pygame Subset for Android und Kivy}
		Mit dem \textit{Pygame Subset for Android} steht ein komplettes Framework für die Verwendung von Python und Pygame zur Verfügung. Die grundsätzliche Platt\-form\-un\-ab\-hän\-gig\-keit und die Verfügbarkeit der Pygame-Erweiterungen lassen den Ansatz attraktiv erscheinen. Der Autor hatte daher auf dieser Basis  versucht, die Klassenbibliothek zu entwickeln. Zwar gab es teilweise massive Performanceprobleme mit leistungsschwächeren Geräten, dennoch erschien eine Umsetzung sinnvoll möglich. Die Beschränkung auf einige wenige, speziellere Eigenschaften der mobilen Geräte (nur Beschleunigungssensoren, kein GPS usw.) erschienen zu Gunsten der Plattformunabhängigkeit verschmerzbar. Jedoch wurde noch während der Entwicklung klar, dass dieser Ansatz keine Zukunft hat. Recht plötzlich wurde die offizielle Unterstützung des Interpreters zu Gunsten von Build-Skripten aufgegeben, die die Entwicklung auf stationären Informatiksystemen erfordern. Hier kollidieren die didaktischen Interessen mit den Zielsetzungen des Projekts, das eine einfache Möglichkeit bieten will, Spiele in den Google Play Store zu bringen.
		
		Mit \textit{Kivy} steht ein Abkömmling von Pygame mit erweitertem \gls{API} zur Verfügung, der eine stärkere Plattformunabhängigkeit und zahlreiche UI-Komponenten bietet. Außerdem ist hier (noch) ein eigenständiger Interpreter verfügbar. Tests auf verschiedenen Geräten zeigten allerdings massive Instabilitäten, sodass der Einsatz von Kivy ebenfalls nicht sinnvoll erscheint.
		
	\subsection{Scripting Layer for Android}
		Letztlich blieb also nur der zuallererst untersuchte Ansatz der offiziellen \gls{SL4A}. Diese bietet die Möglichkeit, Python-Code auszuführen und verfügt über eine interaktive Konsole\footnote{Diese ist jedoch insofern  eingeschränkt, als hier aufgrund der in Android fehlenden Unterstützung von \enquote{readline} keine Befehlshistorie und keine Autovervollständigung möglich sind. Außerdem funktionierte sie nicht auf allen getesteten Geräten einwandfrei und zeigte teils wirre Ergebnisse.}. Außerdem läuft es grundsätzlich auf allen (auch älteren) Android-Geräten. Allerdings weist der Ansatz diverse Probleme auf. Interessante Module (Pygame, SDL usw.), die native Komponenten enthalten, sind nicht möglich. Die eingebauten Trigger zur Aktivierung von Skripten als Reaktion auf bestimmte Ereignisse funktionierten nur auf zwei der getesteten Geräte überhaupt und dort nur sehr unzuverlässig, die restlichen wurden beim Versuch Trigger einzurichten blockiert oder neu gestartet. Die Entwicklung des SL4A verläuft insgesamt äußerst schleppend. Das letzte Release des Python-Interpreters stammt aus dem März 2011. Von der Hauptanwendung ist zwar kürzlich nach über drei Monaten eine neue Version erschienen, diese adressiert jedoch keinen der wesentlichen Fehler, die noch in SL4A enthalten sind.
		
		Lässt man diese Probleme jedoch beiseite, funktioniert die SL4A von allen Python-Ansätzen am besten und zuverlässigsten. Die Python-Android-API stellt jedoch im Gegensatz zum Pygame Subset und zu Kivy nur einen Wrapper für als \gls{JSON} formatierte \glspl{RPC} zu einem laufenden SL4A-Server dar, den der Interpreter auf dem Gerät starten kann, wenn er benötigt wird. Dieser Wrapper ist wenig übersichtlich und die Dokumentation hinkt dem Entwicklungsstand hinterher. Die Menge der möglichen Funktionen ist jedoch sehr hoch. Einzig beim Zugriff auf die grafische Oberfläche bestehen große Lücken. Daran hat sich auch seit \cite{Spittank2011} nichts geändert. Es gibt insgesamt drei konkurrierende Varianten, von denen derzeit nur die DialogFacade für den Einsatz im Unterricht infrage kommt. Die WebViews kann man aus demselben Grund ausschließen wie Webapps, zudem ist die Verzahnung von WebViews und Skripten ausgesprochen umständlich und kaum sinnvoll zu verkapseln, da auf beiden Seiten Endlosschleifen erforderlich sind, die auf Events warten müssen. Da die Events nicht vorgefiltert werden können, sind während der Darstellung der Webviews keine weiteren Events möglich. Die FullScreenFacade unterstützt zwar theoretisch die androidtypischen GUI-Komponenten und -Konzepte, kann derzeit bestenfalls als Betaversion angesehen werden, auch wenn sie grundsätzlich vielversprechend ist. 
			
\section{Notwendige Werkzeuge}
	Für den Einsatz des \gls{SL4A} benötigt man nicht nur die entsprechende App, sondern auch den passenden Interpreter, in diesem Fall \textit{Python for Android}. Beides lässt sich nicht über den Google Playstore beziehen, sondern lediglich über die Projektwebseite bei GoogleCode \citep{SL4A}. Hier könnte im Unterrichtseinsatz eine Verteilung der notwendigen Pakete wie bei den ersten Aufgaben aus dem Konzept von Heming\vgl{Heming2009}{45} erfolgen. 

	\gls{SL4A} bringt zwar bereits einen sehr einfachen Editor mit, Apps wie \textit{Touchqode} oder \textit{DroidEdit} haben allerdings angenehmere Bedienkonzepte und ermöglichen das einfache Wechseln zwischen verschiedenen Dateien. Außerdem bieten sie zusätzliche Funktionen, etwa Suchen und Ersetzen sowie die Möglichkeit der Rücknahme von Änderungen. Zumindest Touchqode bietet zusätzlich zur Tastatur eine Reihe von Tasten an, die zur Eingabe von Sonderzeichen dienen, wie sie für die Programmierung notwendig sind. Besser ist allerdings die Verwendung einer geeigneteren \gls{OSTastatur}. Ideal ist hier die Open-Source-Tastatur \textit{Hacker's Keyboard}. Diese bildet eine vollständige PC-Tastatur inklusive Sondertasten nach. Diese kann aufgrund der schieren Anzahl von Tasten natürlich nur auf Tablets ihre volle Wirkung entfalten, trotzdem funktioniert sie auch auf Smartphones ordentlich. Dort wird die volle Belegung allerdings nur im Querformat angezeigt. Im Hochformat sind einige Tasten überhaupt nicht erreichbar.

	Sollen Trigger bzw. Events genutzt werden, muss eine geeignete App zur Profilbasierten Automatisierung installiert werden. Hier stehen, wie bereits erwähnt, Llama, Tasker und Locate zur Verfügung. Der Autor würde zu \textit{Llama} raten, da dieses nicht nur übersichtlicher als die anderen Apps ist, sondern zudem kostenlos angeboten wird. Zum Austausch von Quelltexten mittels QR-Codes wird ebenfalls eine passende App benötigt. Als gut geeignet hat sich hierbei \textit{QR Droid} erwiesen. 
	
\section{Klassenbibliothek}

	Der Aufbau und die Struktur einer Klassenbibliothek für mobile Informatiksysteme wurde im \referenz{chpGestaltung} beschrieben. Hier sind also nur die Besonderheiten für die Umsetzung auf Android zu bedenken. Es ist bei der \gls{SL4A} absolut unumgänglich, eine Klassenbibliothek zu erstellen, da die vorhandene \gls{API} lediglich die JSON-Calls abbildet, die zum SL4A-Server gesendet werden. Aus didaktischer Sicht ist dies vollkommen ungeeignet, da damit nicht objektorientiert gearbeitet werden kann und es sich um eine  unübersichtliche Zusammenstellung verschiedenster Funktionen handelt, die keine besondere Orthogonalität aufweist. Es werden etwa ähnliche Strukturen (\zb Listen von Nachrichten und Listen von Kontakten) vollständig unterschiedlich behandelt. 
	
	Da die SL4A Python als Skriptsprache anbietet, ist die Implementierung einer geeigneten Klassenbibliothek weitgehend problemlos möglich. Verpackt in \glspl{PyEgg} lassen sich diese auch leicht installieren. Allerdings ist an eine vollständige Umsetzung aufgrund der oben benannten Beschränkungen des Ansatzes nicht zu denken. Derzeit ist außer im Bezug auf Dialoge keine sinnvolle Umsetzung von UI-Klassen erreichbar. Die damit verbundenen Probleme wären für den Unterrichtseinsatz deutlich zu komplex. Damit fällt natürlich vorübergehend  jegliche Chance auf die Weiterverwendung eines großen Teils von \gls{SuM} weg. In anderen Bereichen muss man ebenfalls mit Abstrichen leben. Viele Events (Tastendrücke, Ortung, Sensoren usw.) sind nicht unmittelbar zugänglich. Entweder man verwendet hierzu externe Werkzeuge oder man fragt Sensorwerte ständig in einer Polling-Schleife ab. Letzteres geht jedoch zu Lasten der Akkuleistung und ist keine besonders clevere Idee, da dies im Standbymodus der Geräte nicht funktioniert und zu Deadlocks führen kann.

\section{Aktueller Stand}
	Da zunächst andere Ansätze präferiert wurden und hierfür die notwendigen Klassen erstellt wurden, liegt noch keine vollständige Umsetzung der Klassenbibliothek für Android vor. Die mehrfachen Neustarts bei der Implementierung zeigen hier ihre Folgen. Allerdings ist im jetzigen Zustand bereits ersichtlich, dass die Umsetzung mit Android grundsätzlich möglich ist, obwohl der Autor weiterhin Zweifel am \gls{SL4A} hat. Die de facto fehlenden Trigger sind ein Problem. Das Schlimmste ist jedoch die äußerst schleppende Weiterentwicklung, die die Zukunftsfähigkeit des Ansatzes zumindest mit kleinen Fragezeichen versieht.
	
	Da der Autor einen vollständigen Abdruck der Quelltexte für nur wenig sinnvoll hält, findet sich im Anhang lediglich ein kurzes Beispiel mit den notwendigen Klassen\vglr{secQuell}. Der Rest der bisher umgesetzten Klassenbibliothek findet sich auf der beiliegenden CD. Der gesamte Code wird zu einem späteren Zeitpunkt vom Autor unter einer freien Lizenz an geeigneter Stelle zur Verfügung gestellt werden, in der Hoffnung, dass sich Mitstreiter finden werden, die dabei helfen werden, die bestehenden Lücken zu füllen.