Projekt-Setup für die Entwicklung kommerzieller Android-Applikationen

Für Android-Projekte, die einen signifikanten Anteil von Business- oder Spiellogik enthalten, lohnt es sich, die Applikation in separaten Modulen zu entwickeln. Insbesondere Komponenten zum Ausführen der zentralen Abläufe auf dem PC können sinnvoll sein.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 14 Min.
Von
  • Kai Altstaedt
Inhaltsverzeichnis

Für Android-Projekte, die einen signifikanten Anteil von Business- oder Spiellogik enthalten, lohnt es sich, die Applikation in separaten Modulen zu entwickeln. Insbesondere Komponenten zum Ausführen der zentralen Abläufe auf dem PC können sinnvoll sein.

Der Android-Debugger ist gut und schnell, allerdings kann er niemals die Bequemlichkeit und Geschwindigkeit eines Code-Compile-Test-Zyklus der reinen PC-Entwicklung erreichen. Der Unterschied in der Geschwindigkeit wird noch größer, wenn man von der Entwicklung der Engine zur Entwicklung der Inhalte (Geschäftsprozesse oder Level-Design) kommt. Der Bedarf nach separaten GUI-Schichten entsteht quasi von selbst, wenn von Anfang an das Ausführen der Anwendung auf einem PC Teil der Projektanforderungen war.

Als Beispiel, um die Mechanismen zum Modularisieren des Codes in separate Projekte zu illustrieren, soll das Spiel "Fluki" dienen. Hier geht es darum, eine kleine Flunder durch Labyrinthe zu steuern. Die Grafik-Engine des Spiels nutzt OpenGL. Die strukturellen Parameter des Projekts sind:

  • Es soll sowohl eine kostenfreie Version mit als auch eine kostenpflichtige ohne Werbung aus dem gleichen Quellcode entstehen.
  • Das Spiel soll 72 einzelne Level haben, wobei das Level-Design den folgenden Entwicklungszyklus durchläuft: Die Level werden in einem Excel-Sheet mit einem kleinen Code-Generator erzeugt.
  • Der Test des Leveldesigns erfolgt in einer nativen Java-Swing-Umgebung auf einem PC, das finale Überprüfen auf den Android-Geräten (Emulator und echte Hardware).

Der Fluki-Entwicklungszyklus: Leveldesign, Test auf PC und Android-Gerät (Abb. 1)


Der Fokus des Artikels liegt auf dem Erzeugen einer passenden Eclipse-Projekt-Struktur und nicht im Zeigen einer Hardware-Abstraktion. Um jedoch die Design-Strategie der Hardware-Unabhängigkeit zu erklären, ist ein kleiner Code-Abschnitt am Ende des Artikels aufgeführt.

Aus den Anforderungen ergibt sich die Trennung des Codes und der Ressourcen in Module. Alle Module sind als eigene Eclipse-Projekte realisiert, die einander in unterschiedlicher Weise referenzieren.

  • Das Core-Modul enthält die zentralen Elemente der Geschäfts- oder Spiellogik. Das gesamte I/O ist dabei über Interfaces oder abstrakte Basisklassen gekapselt. Somit enthält das Core-Modul keinen plattformspezifischen Code.
  • Das Android-Library-Modul enthält den gesamten plattformspezifischen Code für die Android-Umgebung und zusätzlich Ressourcen wie Layouts, Bilder, Sounddateien, Texte und so weiter. Es umfasst außerdem eine Implementierung des I/O-Layers für die Android-Plattform.
  • Das Android-Free-Version-Modul ist ein ausführbares Android-App-Projekt. Es dient allerdings ausschließlich als "Launcher" der Funktionen (Activities) des Android-Library-Moduls im eingeschränkten (freien) Modus.
  • Das Modul "Android Full Version" ist genau wie das Free-Version-Modul ein ausführbares App-Projekt. Es startet die Funktionen im Android-Library-Projekt im uneingeschränkten, werbungsfreien Modus.
  • Das PC-Modul enthält alle JUnit-Tests für das Core-Modul, eine Implementierung des I/O-Layers für den PC und einen einfachen Swing-Client für die Anzeige und Navigation.

Das vorgestellte Basis-Schema lässt sich auf beliebige Applikationen übertragen und hat sich in der Vergangenheit bewährt. Die Referenzen zwischen den Projekten sind dabei auf unterschiedliche Weise in Eclipse realisiert.