UI-Design im Fokus

Android-Entwicklung für Windows-Entwickler – eine Einführung [Teil 2]
Keine Kommentare

Im mobilen Bereich kann man Android nicht ignorieren. Viele Entwickler sind in der Windows-Welt zu Hause und fragen sich, wie leicht oder schwer der Einstieg in die Entwicklung von Apps für Android-Geräte ist. Wir probieren es – in diesem Teil mit Fokus auf das UI-Design.

Im ersten Teil haben wir uns mit den Grundlagen der App-Programmierung für Android-Systeme beschäftigt. Das Ziel – eine erste „Hello World“-App – haben wir nach Installation und Konfiguration der Entwicklungsumgebung geschafft. In dieser Ausgabe wollen wir den Weg fortsetzen und uns primär mit dem UI-Design, also der Gestaltung des Aufbaus der Pages beschäftigen (Kasten: „Android für Windows-Entwickler – Ein Einstieg in drei Teilen“). Dabei wollen wir erneut die Position eines Entwicklers einnehmen, der in der Windows-Welt zu Hause ist und bewusst nach Parallelen und Unterschieden zwischen beiden Systemen suchen. Für Windows-Systeme erfolgt die Gestaltung des UI auf der Basis von XAML (Desktop, Windows 8-Apps, Windows Phone). XAML ist ein XML-Dialekt. Hier findet sich eine erste Gemeinsamkeit: Für den strukturierten und hierarchischen Aufbau des UI verwendet auch Android XML. Doch bevor wir uns mit den technischen Aspekten beschäftigen, sind einige grundsätzliche Vorbemerkungen zur Konzeption und zum Entwurf App im Allgemeinen und des UI im Speziellen angezeigt. Als Beispiel wählen wir die Umsetzung eines bekannten und einfachen Spiels (Kasten: „Beispiel mit Spaß und Potenzial“).

Android für Windows-Entwickler – Ein Einstieg in drei Teilen

In dieser Artikelserie präsentieren wir einen kompakten Einstieg in die Entwicklung von Apps für mobile Endgeräte mit Android-System.

Beispiel mit Spaß und Potenzial
Der Entwicklungszyklus wird anhand eines Beispiels verdeutlicht. Gewählt wurde dazu das bekannte Spiel „Schiffe versenken“. Dieses hat schon vor der Computerära zu interessanten virtuellen „Gefechten“ geführt. Die nachfolgende kurze Beschreibung des Spiels basiert hierauf. Es wurde bereits Ende des 19. Jahrhunderts gespielt und hat sich in seiner Grundstruktur nicht geändert. Es werden mindestens zwei Spieler benötigt. In diesem Fall hat jeder Spieler zwei 10 x 10 Felder: das eigene und das gegnerische Kampfgebiet. An den Seiten werden Buchstaben (A bis J) und an den oberen Rändern Zahlen (1 bis 10) notiert. In das eigene Feld trägt man – ohne Kenntnis des Mitspielers – seine Flotte ein. Schiffe werden durch zusammenhängende Kästchen symbolisiert. Über die Anzahl und Größe der Schiffe und über die Art der Platzierung sollten vor Beginn Einigkeit herrschen. Grundsätzlich gelten folgende Regeln:

  • Die Schiffe dürfen nicht aneinander stoßen.
  • Die Schiffe dürfen nicht über Eck gebaut sein oder Ausbuchtungen besitzen.
  • Die Schiffe dürfen auch am Rand liegen.
  • Die Schiffe dürfen nicht diagonal aufgestellt werden.
  • Jeder verfügt über insgesamt zehn Schiffe (in Klammern die Größe): ein Schlachtschiff (5), zwei Kreuzer (je 4), drei Zerstörer (je 3) und vier U-Boote (je 2). Durch die Wahl von kleineren Schiffen erhöht sich die Möglichkeit von Fehlschüssen und das Spiel dauert länger. Nach der Auslosung, wer zuerst schießen darf, nennt dieser die Koordinaten, z. B. B7. Der Gegner antwortet darauf mit folgenden Optionen „Wasser“, „Treffer“ oder „versenkt“. Wenn alle Felder des Schiffs getroffen sind, ist das Schiff versenkt. Der Schießende notiert dies in seiner zweiten Matrix. Der Beschossene muss die Treffer ebenfalls markieren. Er weiß damit, wann ein Schiff versenkt wurde. Es wird entweder abwechselnd geschossen oder immer so lange, bis ein Schuss ins Wasser geht. Dieses ist im Vorfeld festzulegen.

Dieses Spiel wurde u. a. deshalb ausgewählt, weil es bezüglich der App-Entwicklung folgende Vorteile und Erweiterungsoptionen bietet:

  • einfaches und allseits bekanntes Spielprinzip
  • Mehrspielermodus über Internet oder Einzelspielermodus gegen Computer
  • Unterstützung anderer Plattformen denkbar (iOS, Windows 8, Windows Phone)

App-Lebenszyklus aus Entwicklerperspektive

Auch wenn eine App lediglich über einen begrenzten Umfang an Funktionalität verfügt, ist eine umfassende Planung notwendig. Der Lebenszyklus einer Anwendung beginnt mit der Idee/dem Auftrag. Es folgen die Konzeption und das Design, die Produktion (Implementierung), die Installation – für Apps also üblicherweise die Bereitstellung über den Store der Plattform. Weitere Aufgaben sind ggf. die Organisation des Supports, das Bereitstellen von Updates zur Fehlerbereinigung und fortwährenden Anpassungen an erweiterte Bedürfnisse. Schaut man sich die Einsatzbedingungen einer App gegenüber einer klassischen Desktopanwendung an, so stellt man folgende entscheidende Unterschiede fest:

  • Apps werden für eine spezielle Aufgabe erstellt und haben einen begrenzten Funktionsumfang.
  • Die Gestaltung des UI ist stark reduziert. Die Bedienelemente ergeben sich direkt aus dem Content und sind nur im minimal notwendigen Umfang vorhanden.
  • Eine intuitive Bedienung ist zwingend. Nach dem Starten muss die Funktionsweise klar sein.
  • Der Vertriebs- und Installationsweg ist meist eindeutig und führt i.d.R. nur über den Store.
  • Apps bieten technisch betrachtet nur eine sehr eingeschränkte Möglichkeit zum Zugriff auf die Systemumgebung. Berechtigungen hierfür muss der User erst erteilen.
  • Konfigurationsmöglichkeiten der App durch den Anwender sind während des Installationsprozesses meist nicht vorgesehen.
  • Apps werden meist für einen anonymen Markt produziert. Natürlich existieren auch Aufträge von Unternehmen, jedoch sind die (potenziellen) Nutzer auch dann oft anonym.
  • Die Updatezyklen sind im Regelfall sehr kurz. Verbesserungen, Fehlerkorrekturen und Funktionserweiterungen münden meist in einer neuen Version, die direkt über den Store ausgeliefert wird. Die User akzeptieren häufige Updates besser als bei klassischer Software.
  • Es existieren grundsätzliche Richtlinien zur Gestaltung des UI und der Einhaltung bestimmter technischer und funktionaler Bestimmungen. Für die Aufnahme in den Store wird die Einhaltung bestimmter Mindestanforderungen geprüft. Nur dann hat die App eine Chance. Für Android finden sich die aktuellen Richtlinien hier.
  • Das Marketing für Apps basiert größtenteils auf Mund-zu-Mund-Kommunikation bzw. auf Empfehlungen über soziale Kanäle.
  • Die Lizenzgebühren für eine App sind meist sehr gering bzw. die App wird kostenfrei angeboten. Die Finanzierung erfolgt über die Bereitstellung von kostenpflichtigen Content bzw. durch die Schaltung von Werbung innerhalb der App.
  • Für viele Verwendungen existieren mehrere Apps, d. h. der Anwender hat oft eine gute Auswahl.
  • Die Benutzer sind nicht bereit, lange Lade-, Such- oder Rechenvorgänge zu akzeptieren. Man erwartet eine sofortige Reaktion der App auf eine Benutzeraktion.
  • Das Nutzungsumfeld (Smartphone, Tablet) unterscheidet sich wesentlich von einer Nutzung von Software auf dem Notebook oder Desktop-PC.
  • Anwender nutzen unterschiedliche Systeme (Android, iOS, Windows 8) und erwarten dennoch, dass die App auf allen Systemen verfügbar ist und sich das UI überall gleich anfühlt.
  • Über den Store können und geben die Nutzer direktes und kurzes Feedback. Der Erfolg einer App kann damit unmittelbar gepuscht oder zunichte gemacht werden.
  • Bei Nichtgefallen ist die App in wenigen Sekunden deinstalliert. Die User wenden sich dann unmittelbar einem Konkurrenzprodukt zu. Die Ausstiegshürden sind daher sehr niedrig.

Konzeption und Entwurf

Zunächst muss man sich über die Problemstellung, den gewünschten Funktionsumfang und existierende Lösungsansätze im Klaren werden. Es gilt, das gewünschte Funktionsspektrum auf den Kern zu beschränken. Ist die App erfolgreich und wurde ein erstes Userfeedback eingesammelt, können Erweiterungen bei Bedarf in Folgeversionen realisiert werden. In einem ersten Schritt ist das Fachkonzept zu erstellen. Als Hilfsmittel kommen alle bekannten textuellen und grafischen Notationsformen in Betracht, sofern sie ausreichend leichtgewichtig sind. Hier gibt es kein richtig oder falsch, bestenfalls können Empfehlungen ausgesprochen werden. Aus dem Methodenspektrum der UML hat sich nach Ansicht des Autors auf hoher Abstraktionsebene das Anwendungsfalldiagramm bewährt. Es ist leicht verständlich, schnell erstellt und hilft bei der Konzentration auf die Kernfunktionen. In Abbildung 1 ist das Anwendungsfalldiagramm für unseren Spieleentwurf zu sehen. Weitere Diagrammtypen können sinnvoll sein, um beispielsweise dynamische Aspekte zu modellieren, u. a. kann in einem Aktivitätsdiagramm (Abb. 2) das Verhalten der App dargestellt werden.

Abb. 1: Die Kernfunktionen im Anwendungsfalldiagramm

Abb. 1: Die Kernfunktionen im Anwendungsfalldiagramm

Abb. 2: Ein Aktivitätsdiagramm verdeutlicht den Ablauf

Abb. 2: Ein Aktivitätsdiagramm verdeutlicht den Ablauf

Auch eine kompakte verbale Formulierung (Kasten: „Kernfunktionen/Bedingungen für die Beispiel-App“) der grundsätzlichen Funktionsweise und der wichtigsten Annahmen ist hilfreich.

Kernfunktionen/Bedingungen für die Beispiel-App

  1. Zeitversetzter Mehrspielermodus, alternativ auch Einzelspielermodus (hierfür ist eine einfache KI zu entwickeln).
  2. Feldgröße: 10 x 10 (fest).
  3. Login für Mehrspielermodus notwendig.
  4. Schema für Punktberechnung muss noch erstellt werden. Verlorene Spiele führen zu Punktabzug, gewonnene Spiele zu Punktgewinn. Das Ausmaß ist abhängig von den Ausgangspunkten der Spieler und wie viele eigene Einheiten man bei einem Sieg noch hat.
  5. Gegnerauswahl im Mehrspielermodus erfolgt automatisch, z.B. auf der Basis der aktuellen Punkte.
  6. Platzierung der eigenen Schiffe beim Start des Spiels. Alternativ per Zufall oder manuell. Im Falle der manuellen Platzierung ist auf die zulässige Position zu prüfen.
  7. Jeder Spieler ist so lange am Zug, bis ein Schuss nicht trifft.
  8. Für einen vollständigen Spielzug hat ein Spieler maximal drei Tage Zeit, ansonsten hat er die Partie kampflos verloren.
  9. Führung einer Highscore-Liste (online).
  10. Konfigurationsmenü bietet zum Beispiel Farbeinstellungen.

UI-Protyping

Das Ziel ist es, bereits früh einen Entwurf des UI zu haben und diesen zur Diskussion zu stellen. Ganz klassisch mit Papier und Bleistift die Benutzerschnittstelle (zum Beispiel den Aufbau und die Anordnung der Controls) zu skizzieren, ist ein erster Ansatz. Diese Grobskizze ist natürlich nicht für eine externe Präsentation geeignet, hilft jedoch, den eigenen Ideen einen Rahmen zu geben. Der Vorteil ist klar: eine schnelle Umsetzung ohne technische Hilfsmittel. In Abbildung 3 zeigen wir eine Handskizze von zwei Screens für unsere Anwendung. Der nächste Schritt könnte darin bestehen, mittels eines Präsentations- oder Zeichenwerkzeugs eine grafische Repräsentation der wichtigsten UI-Elemente zu erstellen. Ein spezialisiertes und universelles Werkzeug für das Erstellen von UI-Prototypen ist Pencil. Mittels vordefinierten Symbolen kann ein guter Entwurf der Benutzeroberfläche erstellt werden. Die Elemente und Symbole repräsentieren die Controls der unterschiedlichen UI-Plattformen. Abbildung 4 zeigt einen Teilentwurf des UI auf der Basis von Pencil. Zu beachten ist, dass dieser Prototyp nicht lauffähig ist. Die Vorteile sind:

  • Verfügbarkeit vielfältiger Symbole für die verschiedenen Plattformen.
  • Schneller Entwurf durch das Zusammenfügen von Elementen in eine Präsentation.
  • Bekannte Technologie sowohl aus Sicht des Entwicklers und der Anwender, wie eine Zeichen- oder Präsentationssoftware.
  • Gutes Hilfsmittel für eine Abstimmung zwischen den Beteiligten im Rahmen einer Präsentation.
  • Keine Programmierkenntnisse notwendig. Dennoch sollten Kenntnisse über das UI-Design der Plattform vorhanden sein.
Abb. 3: Handskizze als ersten Entwurf des UI

Abb. 3: Handskizze als ersten Entwurf des UI

Abb. 4: UI-Prototyping mit Pencil

Abb. 4: UI-Prototyping mit Pencil

Ein derartig einfacher Ansatz weist auch Nachteile auf:

  • Grundsätzlich begrenzte Symbolauswahl, die nicht alle Möglichkeiten eines UI-Entwurfs umfasst. Anderseits ist die Reduktion auf das Wesentliche eine Voraussetzung für ein schnelles Erstellen von Prototypen.
  • Es wird kein lauffähiger Prototyp erstellt, lediglich eine Visualisierung.
  • Ablaufszenarios (Workflows) lassen sich nur schwer darstellen.

Nur in den seltensten Fällen wird man bei einer App mit einer Seite (Page) auskommen. Also werden die Inhalte auf mehrere Seiten verteilt. Auch hier gilt unbedingt: je Seite nur ein Thema. Über die Navigation muss man sich Gedanken machen. In einer App sind Menüelemente nicht üblich. Vielmehr erfolgt die Navigation direkt über den Content, sofern möglich. Ebenso spielt der Rückbutton eine entscheidende Rolle. Der „Weg durch die App“ kann mittels eines Navigationsdiagramms verdeutlicht werden. Anhand eines solchen Diagramms prüft man, ob die Bedienung intuitiv ist. Ist sie dieses, kann die programmiertechnische Umsetzung starten.

Auf der MobileTech Conference 2015 in Berlin gibt es vom 31. August bis 3. September jede Menge interessanter Sessions für Mobile-Entwickler.

In diesen MobileTech-Con-Sessions erfahren Sie mehr über die Entwicklung für Android, iOS & Co.:

 

UI-Design

Hier angelangt, geht es nunmehr um die Umsetzung der Seiten (in Android: Activities) in der Entwicklungsumgebung. Erfreulich für den erfahrenen Windows-Entwickler: Diese Activities weisen einen ähnlichen Aufbau wie die Formulare einer Windows-WPF-Anwendung (Definition erfolgt in XAML) auf:

  • Die Beschreibung des Aufbaus und die Platzierung der Elemente erfolgt in XML-Syntax.
  • Die Controls werden ineinander geschachtelt, für die oberste Ebene stehen verschiedene Layout-Container zur Verfügung.
  • Zu jeder Activity ist eine Java-Datei notwendig, diese ist mit den Code-Behind-Dateien aus WPF vergleichbar. Neben den Deklarationen und Initialisierungen enthält diese Datei auch die Methoden zur Signalverarbeitung auf Benutzerinteraktionen. Dazu gehören zum Beispiel die Aktionen, die durch das Drücken eines Buttons ausgelöst werden. Statt zur Entwurfszeit kann das Aussehen einer Activity alternativ auch zur Laufzeit generiert werden.
  • Eclipse bietet mithilfe des installierten ADT-Plug-ins die Möglichkeit, das UI mittels des grafischen Designers zu gestalten und im Property-Editor die Eigenschaften der Controls festzulegen bzw. zu ändern. Letztendlich wird immer XML-Code generiert, der ebenso direkt erfasst und angepasst werden kann. Erfahrene Entwickler werden das UI in XML definieren und das Ergebnis in der grafischen Vorschau betrachten.

Nach diesen grundsätzlichen Bemerkungen werden jetzt die folgenden Punkte betrachtet:

  1. Der Aufbau einer Activity in den XML- und Java-Dateien.
  2. Wichtige Controls zur Gestaltung des UI und deren Verwendung (Tabelle 1).
  3. Layout-Container für den hierarchischen Aufbau einer Activity.
  4. Hinzufügen und Einbinden einer weiteren Activity.
  5. Aktivierung (Wechsel) zwischen Activities während der Laufzeit.

Den Aufbau einer Activity kann man am besten studieren, wenn man sich dazu ein Beispiel betrachtet. Abbildung 5 zeigt das Ergebnis des XML-Codes von Listing 1. Nach grundlegenden Einstellungen zur Activity, wie Breite und Höhe, erfolgt die Angabe zum Layout, z. B. das LinearLayout. Innerhalb des Layout-Containers werden die einzelnen Controls platziert. Über Eigenschaften der Controls wird deren konkrete Anordnung, deren Verhalten und Aussehen bestimmt.

Abb. 5: Die Activity „Their Move“ in Eclipse

Abb. 5: Die Activity „Their Move“ in Eclipse

Listing 1: XML-Code zur Beschreibung der Activity „TheirMove“
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/root"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:background="#000000"
android:baselineAligned="false"
android:orientation="vertical" >
<LinearLayout
android:id="@+id/LinearLayout1"
style="@android:attr/buttonBarButtonStyle"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="center"
android:background="#000000"
android:orientation="horizontal"
android:paddingBottom="@dimen/activity_vertical_margin"
android:paddingLeft="@dimen/activity_horizontal_margin"
android:paddingRight="@dimen/activity_horizontal_margin"
android:paddingTop="@dimen/activity_vertical_margin"
tools:context="com.example.battleship.MainActivity" >
<Button
android:id="@+id/btnYourMove"
style="@android:attr/buttonBarButtonStyle"
android:layout_width="194dp"
android:layout_height="60dp"
android:text="@string/btnYourMove" />
<Button
android:id="@+id/btn1"
style="@android:attr/buttonBarButtonStyle"
android:layout_width="194dp"
android:layout_height="60dp"
android:clickable="false"
android:text="@string/btnTheirMove" />
<Button
android:id="@+id/button3"
style="@android:attr/buttonBarButtonStyle"
android:layout_width="194dp"
android:layout_height="60dp"
android:text="@string/btnFinished" />
</LinearLayout>
<TextView
android:id="@+id/textView3"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_margin="30dp"
android:text="@string/lbltheirmove"
android:textAppearance="?android:attr/textAppearanceLarge"
android:textColor="#436EEE"
android:textSize="45sp" />
<ScrollView
android:id="@+id/scrollView1"
android:layout_width="match_parent"
android:layout_height="0dp"
android:layout_weight="1" >
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_margin="30dp"
android:orientation="vertical" >
<TextView
android:id="@+id/textView1"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_marginTop="30dp"
android:text="Large Text"
android:textAppearance="?android:attr/textAppearanceLarge"
android:textColor="#FFFFFF" />
<TextView
android:id="@+id/textView2"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_marginTop="30dp"
android:text="Large Text"
android:textAppearance="?android:attr/textAppearanceLarge"
android:textColor="#FFFFFF" />
</LinearLayout>
</ScrollView>
<LinearLayout
style="@android:attr/buttonBarButtonStyle"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="center"
android:background="#000000"
android:orientation="horizontal"
android:paddingBottom="@dimen/activity_vertical_margin"
android:paddingLeft="@dimen/activity_horizontal_margin"
android:paddingRight="@dimen/activity_horizontal_margin"
android:paddingTop="@dimen/activity_vertical_margin"
tools:context="com.example.battleship.MainActivity" >
<Button
android:id="@+id/Button01"
style="@android:attr/buttonBarButtonStyle"
android:layout_width="194dp"
android:layout_height="60dp"
android:text="@string/btnNewGame" />
<Button
android:id="@+id/Button02"
style="@android:attr/buttonBarButtonStyle"
android:layout_width="194dp"
android:layout_height="60dp"
android:text="@string/btnHiScore" />
<Button
android:id="@+id/Button03"
style="@android:attr/buttonBarButtonStyle"
android:layout_width="194dp"
android:layout_height="60dp"
android:text="@string/btnSettings" />
</LinearLayout>
</LinearLayout>

Auch in Android wird die Struktur einer Activity durch einen Layout-Container bestimmt. Die wichtigsten Layout-Container sind:

  • RelativeLayout: Er ordnet die eingebetteten Elemente relativ zueinander bzw. relativ zu seinen Rändern aus. Dieser Layouttyp ist sehr flexibel und erlaubt eine einfache Umsetzung auch recht komplexer UIs.
  • TableLayout: Die Elemente werden in Zeilen und Spalten angeordnet. Der Aufbau ähnelt dem Erstellen von Tabellen in HTML.
  • GridLayout: Es wird ein Gitter erzeugt. Die Elemente werden in einzelne Gitterelemente eingeordnet. Ein Element kann auch über mehrere Zeilen/Spalten reichen. Diesen Layout-Container gibt es in fast identischer Form auch in WPF.
  • GridView: Ordnet die UI-Elemente in einer Galerie an; die Zahl der Spalten wird definiert, die Zahl der Zeilen ergibt sich automatisch.
  • FrameLayout: Es handelt sich um einen Platzhalter für View-Elemente, die zur Laufzeit ein- oder ausgeblendet werden.
  • AbsoluteLayout: Es erfolgt eine freie Positionierung der eingebetteten Elemente über die Angabe der Koordinaten. Grundsätzlich gilt für (Android-)Apps das Primat des relativen Layouts. Unterschiedliche Bildschirmgröße und Auflösungen verbieten eine absolute Positionierung.
Tabelle 1: Die wichtigsten „Widgets“ des Android-Systems [1]

Tabelle 1: Die wichtigsten „Widgets“ des Android-Systems [1]

Nur die wenigsten Apps werden lediglich mit einer Activity auskommen. Vielmehr sind die Inhalte auf mehrere Bildschirmseiten aufzuteilen. Um eine weitere Activity hinzuzufügen, sind folgende Schritte notwendig:

  1. Zum Projekt ist eine neue Klasse hinzuzufügen. Der Name der Klasse lautet auf den gewünschten Namen der Activity und sollte auch in der Bezeichnung dieses erkennen lassen. Also zum Beispiel java. Die Klasse muss von der Superklasse android.app.Activity ableiten. Am einfachsten ist dieses zu erreichen, indem man in Eclipse mit STRG + N das Dialogfeld zur Klassendefinition aufruft (Abb. 6). Die Datei der Klasse wird im Ordner des Projekts im Ordner \src abgelegt.
  2. Für die Definition des Layouts der Activity ist eine XML-Datei zu hinterlegen und zwar im Unterordner \res\layout. Am einfachsten kopiert man eine vorhandene Layoutdatei.
  3. Zwischen beiden Dateien (java- und XML-Datei) ist eine Verbindung herzustellen. Das geschieht über die Methode onCreate. Ein Beispiel ist in Listing 2 zu sehen.
  4. Activities sind anzumelden. Dieses geschieht dadurch, dass man die Manifest-Datei der App erweitert. Bei Betrachtung von Listing 3 wird deutlich, was gemeint ist. Activities mit besonderen Funktionen sind mit so genannten Intent-Filtern zu versehen. Die Start-Activity wird beispielsweise mit dem Intent-Filter intent.action.main ausgestattet. Damit ist festgelegt, welche Seite beim Starten aufgerufen wird.
Abb. 6: Der Assistent erzeugt die Klasse mit wenigen Klicks

Abb. 6: Der Assistent erzeugt die Klasse mit wenigen Klicks

Listing 2: Methode „onCreate“ zur Verbindung der „java“-Klasse mit der Layoutdatei
package de.itfachartikel.battleship;
import android.app.Activity;
...
public class YourMoveActivity extends Activity implements OnClickListener {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_yourmove);
Button btnTheirMove = (Button) findViewById(R.id.btnTheirMove);
btnTheirMove.setOnClickListener(this);
}

Listing 3: In der Manifest-Datei werden die Activities angemeldet
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="de.itfachartikel.battleship"
...
<application
...
<activity android:name=".SplashActivity" android:label="@string/title_activity_splash">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity
android:name=".TheirMoveActivity"
android:label="@string/app_name" >
</activity>
</application>
</manifest>

Das ADT-Plug-in in Eclipse bietet die Möglichkeit, die eben genannten Schritte automatisiert erledigen zu lassen. Dazu wählt man File | New | other … Im Dialogfeld ist nunmehr Android | AndroidActivity auszuwählen. In den folgenden Schritten sind das grundsätzliche Layout und der Name festzulegen. Ist das erledigt, bietet Eclipse an, allen notwendigen Anpassungen (u. a. die Eintragungen in der Manifest-Datei) selbstständig vorzunehmen. Eine wirklich hilfreiche Sache. Der Anwender muss zwischen den Activities wechseln können. Beispielhaft zeigen wir die „Verdrahtung“ der Interaktion zwischen den Activities TheirMove und YourMove. Beide Seiten enthalten jeweils einen Button, bei dessen Betätigung die jeweils andere Activity angezeigt werden soll. Dazu muss dem betreffenden Button ein Listener zugewiesen werden (entspricht der Ereignisbehandlungsroutine in WPF). Die Methode zum Listener enthält wiederrum den Code zur Ausführung. In diesem Fall den Aufruf der anderen Activity. Das geschieht über die Definition eines so genannten Intents (Listing 4).

Listing 4: Benutzerinteraktion durch Zuweisung eines Listeners
package de.itfachartikel.battleship;
import android.app.Activity;
...
public class YourMoveActivity extends Activity implements OnClickListener {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_yourmove);
Button btnTheirMove = (Button) findViewById(R.id.btnTheirMove);
btnTheirMove.setOnClickListener(this);
}
public void onClick(View v) {
// Show Activity 'Their Move'
Intent intent = new Intent(this, TheirMoveActivity.class);
startActivity(intent);
}

Ausblick und Fazit

Auch die Entwicklung einer App beginnt mit einer Analyse, gefolgt von Konzeption und Entwurf. Mittels Prototypen gilt es, besonders schnell einen Entwurf des UI zu präsentieren. Die Kernfunktionen wurden identifiziert und erste Lösungsansätze erstellt. Im kommenden Schritt geht es um die Implementierung der Funktionalität. Als erfahrener Windows-Entwickler hat man wahrscheinlich gemischte Gefühle: Zum einen fühlen sich Werkzeuge und Abläufe nach wie vor noch etwas fremd an, zum anderen kann man jedoch auch Gemeinsamkeiten feststellen, z. B. die XML-basierte Technik des UI-Layouts. Ein Wissenstransfer ist also möglich. Java und C# liegen auch nicht so weit auseinander, beides sind moderne objektorientierte Sprachen mit einem großen Deckungsgrad ihrer Konzepte. Man erkennt allerdings auch, dass insbesondere die unterschiedlichen Steuerelemente der Benutzeroberfläche von Windows- und Android-Apps eine plattformübergreifende Entwicklung nach wie vor schwierig gestalten. Tools, die jenseits von bloßem HTML eine systemübergreifende Entwicklung versprechen, müssen zwangsläufig als Basis den kleinsten gemeinsamen Nenner der Systeme verwenden. Noch komplexer wird es, wenn man iOS einbezieht. Daher lautet das Fazit: Sich mit nativer App-Entwicklung für Android zu beschäftigen ist (als Windows-Entwickler) auf keinen Fall falsch. Die Lernkurve ist nicht unendlich steil. In diesem Sinne „Es geht doch eigentlich ganz leicht“.

Lesen Sie hier weiter: Android-Entwicklung für Windows-Entwickler – eine Einführung [Teil 1]

Links & Literatur

[1] Lous, D.; Müller, P.: „Android 4 Programmierung“, Markt + Technik, 2013

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -