Android Best Practices with RoboGuice Best

Android Best Practice mit RoboGuice & Otto

Um der schier unendlich steigenden Nachfrage nach mobilen Applikationen hinterher zu kommen, ist das Wissen um Android Best Practices bei der Entwicklung von Handy Applikationen von wesentlichem Vorteil.

Im folgenden wollen wir aufzeigen, worauf bei der Entwicklung mit Android zu achten ist, welche Fallstricke man geschickt umgehen kann und wie man mit RoboGuice Boilerplate Code vermeiden kann. Zusätzlich wollen wir innerhalb unserer Best Practices zeigen, wie man mit Otto auf einfache Art und Weise einen Event-Bus einrichten kann, der eine saubere Trennung zwischen View und Businesslogik erlaubt. Hierdurch wird nicht nur die Geschwindigkeit der Applikation für den Nutzer sichtbar gesteigert.

Android Best Practice Grundgedanken

Das Aufsetzen eines neuen Projektes in IDEA IntelliJ ist denkbar einfach. Nutzt man das integrierte Template von IntelliJ kann man sofort auf Gradle-Basis loslegen. Doch leider haben wir bereits zu oft Projekte solcher Art gesehen. Aufgesetzt aus der IDE, ohne das Wissen von Best Practices losgelegt und den Quellcode, wie ein Geschwür, wuchern lassen. Das Resultat sind nicht nur Projekte die eine lange Einarbeitungszeit bedürfen sondern auch schlicht weg unwartbar sind. Technische Schulden wird dies heutzutage auch gerne genannt. Ausreden, die diese Schulden auf ein komplexes Produkt schieben werden nebenbei bemerkt auch gerne vorgeschoben. Dies ist aber nicht akzeptabel.

Dabei ist es so einfach mit ein paar Grundkenntnissen, auch ohne tiefergehendes Wissen um Android, sehr gut strukturierte und wartbare Projekte zu bauen.

Android Boilerplate Best Practices

Boilerplate ist die Bezeichnung für Quellcode, der immer wiederholt werden muss. Denken wir nur an Getter und Setter oder andere typische Muster aus verschiedenen Bibliotheken.

Um diesen Boilerplate-Code zu umgehen gibt es bereits einige gute Bibliotheken. Wir bevorzugen vor allem Dagger und RoboGuice. Zweiteres haben wir in unserem Beispiel oder Template Projekt – auf das wir am Ende des Artikels verweisen – eingebaut.
RoboGuice hilft typischen Android-Boilerplate zu verhindern. Vor allem bei dem referenzieren von UI-Elementen ensteht schnell Code, der sich immer wieder wiederholt. Im folgenden ein Beispiel für typische UI Referenzierung:

public class ExampleActivity extends Activity {

private Button myButton;

@Override
protected void onCreate(Bundle savedInstanceState) {
// …
myButton = (Button) findViewById(R.id.myButton);
myButton.setText( „Hello, “ + myName );
// …
}

Durch RoboGuice können UI-Elemente weitaus eleganter und lesbarer injeziert werden:

public class ExampleActivity extends RoboActivity {

@InjectView(R.id.name)
private Button myButton;

@Override
public void onCreate(Bundle savedInstanceState) {
// …
super.onCreate(savedInstanceState);
myButton.setText( „Hello, “ + myName );
// …
}

Natürlich lässt sich der Vorteil in diesem kurzen Beispiel nur erahnen, dennoch sieht es jetzt schon weitaus sauberer aus (kein Cast) und wird durch geschickte Vererbung noch praktikabler.

Das gleiche lässt sich mit RoboGuice durch die integrierte Dependency Injection (DI) erreichen. Das zugrunde liegende System ist dem von Spring aus der Java-Welt sehr ähnlich und funktioniert per Reflection. Ein gutes Beispiel kann hier gefunden werden: https://github.com/roboguice/roboguice/wiki

Best Practice mit Hilfe des Event-Bus von Otto

Trotzdem die Entwicklung von mobilen Applikationen noch recht jung ist, können Best Practices aus der Desktop- und/oder Webentwicklung zu Grunde gelegt werden. So auch die Trennung zwischen dem View und der Logik. Ist keine Logik im View enthalten, kann dieser schneller und einfacher verändert oder gar ausgetauscht werden. So ist es auch in der Android-Entwicklung. Damit man jedoch zusätzlich das mobile Gerät bei teuren Interaktionen durch den Nutzer nicht blockiert, bietet sich ein Event-Bus an. Interaktionen können an die Logik übergeben werden und Listener eingerichtet werden, die darauf lauschen, wenn die Logik mit ergebnissen zurück kehrt. Das Ergebnis – gerade bei Android – ist eine weiterhin funktionierende und flüssige Anwendung. Diese wird nicht durch die Berechnung der Logik blockiert. Ganz im Gegenteil, die Berechnung wird durch einen weiteren Prozess des Handys, im Hntergrund, ausgeführt.

Unter folgender URL wird anschaulich erläutert, wie der Event-Bus eingerichtet und Listener registriert werden. http://square.github.io/otto/

Das Best Practice Template

Wir haben basierend auf den genannten Punkten ein Best Practice Template für die Entwicklung von Android Applikationen angelegt. In unserem Github Repository unter folgender URL, könnt ihr dieses finden und gerne auch erweitern:

https://github.com/unicorn-it/android-mvp-example

Wir wünschen euch damit viel Spaß.

0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar