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.

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.