Im Nachfolgenden werde ich euch einige Basics zur Programmierung mit Android bzw. spezieller zu Android Wear geben. Es sind leichte Grundkenntnisse von Java und Android von Nöten, um alles zu verstehen. Der ergänzende Code ist lauffähig und es kann nach Belieben mit ihm herumgespielt werden, sodass man auch mit wenigen Vorkenntnissen ein bisschen basteln kann.

Den Code zu dem Projekt findest du hier: https://github.com/mammuth/Time-Reminder-Wear-App

Es empfiehlt sich, diesen als zip herunterzuladen und das Projekt in AndroidStudio oder IntelliJ zu öffnen, sodass du begleitend sehen kannst, was wir hier in dem Tutorial machen. Alternativ kannst du es natürlich auch mit git clonen (sofern installiert), oder die ‚Checkout from Version Control‚ Funktion von IntelliJ/AndroidStudio nutzen. Der Code ist sehr stark kommentiert, sodass das optimale Verständnis überall beschrieben steht, was passiert.

Wenn du nicht direkt weißt, wie man Android Studio und das Android SDK installiert, findest du super Anleitungen auf der Developer-Seite von Google: https://developer.android.com/sdk/index.html

 

 

Android Wear „Apps“

Was ist denn eigentlich eine Wear „App“? Grundsätzlich gibt es mehrere Möglichkeiten, wie man als Entwickler mit Smartwatches umgehen kann:

1. Eine Erweiterung der Smartphone App für die Uhr: Notifications, die die App auf dem Smartphone erstellt werden grundsätzlich automatisch auf die Uhr weitergeleitet. Diese können aber für Uhren angepasst, optimiert und erweitert werden. Zum Beispiel lassen sich mehrere „Screens“ hinzufügen, die man dann durch horizontale Wischgesten auf der Uhr wechseln kann, um mehr Inhalt (oder Reaktionsmöglichkeiten wie Antworten, Archivieren, oder ähnliches) übersichtlicher darzustellen. Auf dem Handy würden diese Screens dann nicht angezeigt werden. Details auf developer.android.com.
2. Eine App-Komponente erstellen, die direkt auf der Uhr läuft und die der Nutzer ohne sein Smartphone komplett bedienen kann. Das intuitivste Beispiel sind eingebaute Apps wie die Stoppuhr oder Google Play Music. (developer.android.com)

 

Kommen wir zum spaßigen Teil – unserer App:

Wir machen eine Produktivitäts-App, welche dich in regelmäßigen Abständen an die Uhrzeit erinnert. Dies kann zB. hilfreich sein, weil die Zeit nicht „wie im Flug“ vorüber geht, sondern man immer einen Überblick hat, wie viel Zeit vergangen ist, und was man in der Zeit erreicht (oder eben nicht erreicht) hat. Somit lässt sich ggf. effektiver Arbeiten.

 

0. Übersicht

Ausführliche Details und Erklärungen folgen im Verlauf des Artikels und im Quellcode. Die kurze Auflistung an diesem Punkt dient nur der groben ersten Übersicht.

Das Projekt teilt sich in zwei Module auf: wear und mobile. Innerhalb des mobile Moduls haben wir die folgenden vier Klassen:

1. EinstellungsActivity (Link zur Klasse in Github): Dies ist die Haupt-Acitivty der App auf dem Handy. Hier ist die Anzeige des Status in Form eines Switches eingebaut.
2. ErinnerungsVerwalter: Diese Klasse dient als Schnittstelle zur Verwaltung von Androids AlarmManager (developer.android.com. Hier wird die Erinnerung an das System „in Auftrag gegeben“ und/oder wieder gelöscht.
3. ErinnerungsReceiver: Dies ist der BroadcastReceiver, der vom System benachrichtigt wird, wenn es wieder Zeit für die nächste Erinnerung ist. Das ist quasi das Gegenstück zu unserem ErinnerungsVerwalter
4. WearSchnittstelle: Diese Klasse empfängt Nachrichten, die die Uhr über die MessagingAPI schickt. Dies geschieht in unserem Fall im wear Modul, wenn man in der Wear-App die Erinnerung de-/aktiviert.

Das mobile-Modul enthält WearActivity als einzige Java-Klasse. Dies ist die Activity, die auf der Smartwatch geladen wird, wenn unsere App gestartet ist.

An der Anzahl der Klassen in den zwei Modulen merkt ihr schon, dass auf der Uhren-Seite weniger gemacht zu werden scheint – so ist es auch, wir nutzen die Uhr als Ein-/Ausgabe und geben die dadurch erhaltenen Informationen immer an das Handy weiter, welches diese dann verarbeitet.

 

 

Der Smartphone – Teil

1. Das Layout der Einstellungs App

Zunächst erstellen wir das Layout der Einstellungs-Activity, welche wir benötigen um unsere App zu de-/aktivieren und einzustellen, wie häufig die App uns an die Uhrzeit erinnern soll. Das Layout speichern wir in der Datei res/layout/activity_einstellungen.xml (im mobile Modul des Projekts). Enthalten ist in dem Layout primär ein Switch, welcher verwendet wird um zu visualisieren ob die komplette App aktiviert oder deaktiviert ist.

Gewrapt wird der Switch in ein RelativeLayout. In diesem kann man Elemente relativ zu dem übergeordneten Layout und anderen Komponenten positionieren, was für unseren Anwendungsfall das einfachste ist.

Ihr könnt übrigens in AndroidStudio die Geräte ändern, in der euer Layout grafisch dargestellt wird (auch runde/eckige Smartwatches – hier zwar nicht sinnvoll, aber grundsätzlich sehr cool).

In dem Screenshot sieht man aber auch schon, dass der Grafik-Renderer von Studio mit Vorsicht zu genießen ist – denn dieser seltsame Schwarz-Weiße Switch, sieht in der Realität natürlich so aus, wie wir ihn erwarten.

 

Unsere Views bekommen jetzt noch aussagekräftige ID’s und ein paar Eigenschaften für ihre Optik und Positionierung zugewiesen. Mit den ID’s können wir gleich in unsere Activity auf den Switch ‚zugreifen‘, bzw. das richtige Element wiederfinden.

Und schon steht unser grobes Layout! Gehen wir über zu dem Code der Activity.

 

2. Die Einstellungs Activity (Smartphone)

In der Datei EinstellungsActivity.java (zu finden im src/ Ordner hinter dem Packagenamen de.mammuth.timereminder) können wir jetzt die Logik der Einstellungs-Ansicht programmieren.

Gemäß des Activity-Lifecycles wird beim Start der App onCreate() aufgerufen. Hier setzen wir dann in Zeile 34 mit setContentView() das oben erstellte Layout. Danach initalisieren wir unseren Switch, sodass wir dann in Zeile 54ff einen onCheckedChangeListener() auf ihn registrieren können. Listener sind ein sehr wichtiges Konstrukt, welches dir erlaubt Event-basiert zu programmieren und auf gewisse Sachen zu reagieren. Als Resultat wird der Code in onCheckedChanged() aufgerufen, sobald wir den Switch betätigen. In dieser Methode erledigen wir dann die Aufgaben: Änderungen bzw. Status des Switches abspeichern, dementsprechend die Erinnerung de-/aktivieren.

In der onCreate() passieren noch zwei andere Dinge: Zum einen initialisieren und verbinden wir den GoogleApiClient. Über den ApiClient können wir auf die DataAPI zugreifen, die wir für das Synchronisieren der Einstellungen („Sind Benachrichtigungen de-/aktiviert?“) mit der Wear benötigen. Wir holen uns explizit nur die Wear-Api mit addApi(Wearable.API) (und nicht etwa noch G+, Drive, Bewegungs-Erkennung, …). Des Weiteren initialisieren wir in Zeile 50 ein Objekt der Klasse ErinnerungsVerwalter. Diese Klasse schauen wir uns im nächsten Schritt genauer an.

Um die Einstellungen zu Speichern, oder bei einem Switch-Druck den neuen Status zu vermerken, haben wir zwei extra Methoden, getEinstellungen() und schreibeEinstellungen(boolean enabled). Hier werden die Schnittstellen der DataApi genutzt um die Einstellung zu speichern und zu synchorniseren.

 

 

 

3. ErinnerungVerwalter Klasse

In der EinstellungsActivity initalisieren wir zum Start der App einen ErinnerungVerwalter. In dieser Klasse geben wir mit den Methoden setzeErinnerung() und entferneErinnerung() einen Weckzustand an Androids AlarmManager, oder löschen eben bisherige Alarms.

Dazu deklarieren im Konstruktor in Zeile 33ff eine Instanz des AlarmManagers und sagen ihm, dass die Klasse ErinnerungReceiver aufgerufen werden soll, wenn Android unsere App zu der gewünschten Uhrzeit weckt. „In Auftrag“ gegeben wird der Alarm in Zeile 60 am Ende der Methode setzeErinnerung(). 

Denn zuvor müssen wir ja erst einmal herausfinden, wann der nächste Alarm überhaupt ist. Dafür haben wir die Methode getErstenAlarm(), die uns ein Date-Objekt zurückliefert. Hier nehmen wir einfach die aktuelle Uhrzeit, setzen die Minuten auf 00 und erhöhen die Stundenanzahl um eins. Somit haben wir einen Alarm zur nächsten vollen Stunde.

Bei so einer App ist es naheliegend, eine Erweiterung einzubauen, sodass man nicht nur alle volle Stunde, sondern vielleicht auch alle 30 Minuten oder 2 Stunden erinnert wird. Dies habe ich ursprünglich in der getErstenAlarm() berücksichtigt – die Unterscheidung in entsprechender Methode ist noch auskommentiert enthalten und vielleicht ganz interessant.

 

4. ErinnerungReceiver

Diese Klasse ErinnerungReceiver ist ein sog. BroadcastReceiver – in ihr wird der „Weckruf“ von Androids AlarmManager empfangen und verarbeitet, den wir im ErinnerungVerwalter aufgegeben haben. In unserem Fall soll hier eine Notification erstellt werden und auf allen Geräten angezeigt werden.

Um dies zu erreichen, haben wir eine Methode sendeBenachrichtigung(), welche in der onReceive() aufgerufen wird. onReceive() selbst wird, wie der Name bereits sagt, aufgerufen sobald der AlarmManager unsere App weckt. Zunächst erstellen wir uns in Zeile 41ein SimpleDateFormat mit der Form HH:mm (zB. 15:03 Uhr) und parsen damit den aktuellen Zeitpunkt als String: String time = sdf.format(new Date());

In Zeile 46f definieren wir, was geschehen soll, wenn der Nutzer auf unsere Notification klickt – nämlich die EinstellungsApp öffnen.

Mit Android 5 hat Google auch einen neuen NotificationBuilder eingeführt, welcher auch um die Funktionalität der Notifiactions auf Wearables erweitert wurde: NotificationCompat.Builder. Mit diesem bauen wir uns in Zeile 54ff die Notification, setzen das Icon, den Titel und die Beschreibung, wobei in die Beschreibung unsere oben abgefragte aktuelle Uhrzeit eingebaut wird (Zeile 58). Mit .setDefaults(NotificationCompat.DEFAULT_ALL) bestimmen wir noch, dass diese Notification auf jeden Fall auf allen Geräten angezeigt werden soll, also auch unserer Smartwatch. Mit setContentIntent() fügen wir hinzu, was bei Klick passieren soll und zu guter letzt haben wir noch ein Vibrations-Muster definiert, welches wir der Benachrichtigung anhängen.

Das VibrationPattern funktionert so, dass es immer abwechselnd die Zeit in Millisekunden angibt, die gewartet und dann vibriert werden soll. Bei uns also 0ms warten (zu Beginn), 200ms vibrieren, 100ms warten, 200ms vibrieren, …
Hier gibt es noch einiges an Spielraum, wo ihr euch selbst austesten könnt. So könnte man zB. ein großes Hintergrundbild setzen, ein Expanded Layout erstellen, oder weitere Actions hinzufügen. Probiert es aus!

Die Receiver Klasse muss im Android Manifest als solche gekennzeichnet sein: <receiver android:name=„de.mammuth.timereminder.ErinnerungReceiver„/>

 

5. WearSchnittstelle

Die WearSchnittstelle Klasse empfängt Nachrichten, die die Uhr über die Messaging API (gehört zur DataApi) schickt. Dies geschieht in unserem Fall in der WearActivity (im wear Modul), wenn man in der App die Erinnerung aktiviert oder deaktiviert.

Diese brauchen wir, weil der Nutzer über die Uhr ja die Erinnerung de-/aktivieren kann. Hierzu ist es natürlich notwendig, dass wir in Echtzeit von der Uhr erfahren, wenn der Nutzer diese Einstellung ändert. Wie die Uhr diese Benachrichtigungen schickt, sehen wir im nächsten Abschnitt in der WearActivity. Wenn die Message reinkommt, wird die Methode onMessageReceived() in der Klasse WearSchnittstelle aufgerufen. Diese ist ein WearableListenerService und wird in Zeile 24ff des Manifests auch als solcher gekennzeichnet.

Als erstes initialisieren wir uns eine Instanz des ErinnerungVerwalters – über den können wir schließlich die zukünftigen Erinnerungen beenden oder in Auftrag geben. In dem Switch-Case Konstrukt in Zeile 28ff finden wir heraus, welche Nachricht uns die Uhr geschickt hat (starten oder entfernen). Je nachdem benutzen wir dann die Methoden des ErinnerungVerwalters um den Alarm zu setzen oder zu entfernen: erinnerung.setzeErinnerung(); oder erinnerung.entferneErinnerung();

Auch posten wir eine Meldung auf das Handy, dass die Erinnerung de-/aktiviert wurde: Toast.makeText(this, „Erinnerung aktiviert„, Toast.LENGTH_SHORT).show(); 

Die schreibeEinstellungen() Methode ist wieder die Selbe, die wir bereits kennen. Sie nutzt den GoogleApiClient um den Status der App mit der DataApi zu speichern, sodass die Einstellung zwischen Smartphone und Uhr synchronisiert ist.

 

 

 

Der Wearable – Teil

6. Das Layout der Wear App

Wir haben ein Problem. Ein Problem, welches Android Entwickler grundsätzlich schon haben: Es gibt (zu?) viele Geräte – große, kleine, hochauflösende, niedrig-auflösende, … und bei Smartwatches leider auch noch: eckige und runde. Wenn man ein ganz normales Layout erstellt, wie man es gewohnt ist stolpert man über das Problem, dass es auf (mindestens) einer der zwei Uhr-Typen nicht gut aussieht:

 

 

Google hat hierfür allerdings eine halbwegs komfortable Lösung eingeführt: WatchViewStubs als Teil der noch leicht inoffiziellen Wearable UI Library. Man erstellt quasi zwei Layouts, eines für rechteckige, eines für runde Uhren, und die App inflated zur Laufzeit der Applikation dann das richtige Layout. Das machen wir in unserer Wear-App nun auch so.

 

Die Layout-Dateien der Wear-App findest du im wear Modul: /wear/src/main/res/layout/. Es sind drei Dateien: activity_wear, rect_activity_wear und round_activity_wear.

In activity_wear ist einfach nur die WatchViewStub enthalten, mit der Angabe, welche Layouts sie zu laden hat: app:rectLayout=“@layout/rect_activity_wear“ und app:roundLayout=“@layout/round_activity_wear“. In den beiden anderen Layouts definieren wir uns zwei TextViews und den Switch zum de-/aktivieren. Großartig unterscheiden tun die zwei sich nicht – primär sind nur die Margins angepasst.

Wenn die App jetzt auf einer runden Uhr gestartet wird, wird automatisch das runde Layout, bei einer eckigen das eckige Layout geladen.

Auch hier gibt es natürlich viel Spielraum, wie ihr die Oberfläche ändern könnt. So ließe sich grundsätzlich das Design aufhübschen oder vielleicht die zwei TextViews animieren oder ähnliches. In diesem Fall hätte sich für das Layouting auch ein einzelnes BoxInsetLayout gelohnt, anstelle der zwei extra Layouts. Wie das ginge, steht zB. hier. Spielt einfach ein wenig damit rum.

 

 

7. WearActivity

Kommen wir nun zu der App, die direkt auf der Uhr laufen soll. Hier erstellen wir nur eine Activity, die dann die Klassen unserer Smartphone-App verwendet um den Timer zu de-/aktivieren.

In der onCreate() der WearActivity setzen wir zunächst das eben definierte Layout der Activity: setContentView(R.layout.activity_wear); (Merke, dass wir hier das WatchViewStub als ContentView setzen). In Zeile 38ff erstellen wir anschließend ein WatchViewStub und registrieren einen onLayoutInflated() Listener auf ihm. Wenn das Layout geladen wird, initalisieren wir den Switch in der Activity (Zeile 43). Zu beachten ist, dass wir die Methode findViewById() auf dem WatchViewStub ausführen.

Zuvor haben wir noch, wie gewohnt in Zeile 30 den GoogleApiClient initialisiert.

Nachdem wir den Switch initialisiert haben, laden wir noch die Einstellungen über die DataApi mit der Methode getEinstellungen()

Woher wissen wir, wann der Nutzer den Toogle-Button in unserer Wear App gedrückt hat? Wie immer nehmen wir auch hier einen Listener, und registrieren auf unseren toggleButton einen onCheckedChangeListener (Zeile 49).

 

Nun fehlt noch die Synchronisation mit der Handy-App.

Wenn der Nutzer auf den Button klickt, wird wie wir es bereits kennen die Methode onCheckedChanged() aufgerufen. Hier nutzen wir nun die DataApi um eine Message zu erstellen, die dann an das Handy geschickt wird. Hierzu fragen wir alle verfügbaren Nodes ab und warten auf das Ergebnis (Zeile 56f). Haben wir eine Liste aller Nodes, so gehen wir diese durch und senden die gewünschte Message: /START_ERINNERUNG oder /ENTFERNE_ERINNERUNG.

Diese Message wird in der Smartphone App in der Klasse WearSchnittstelle empfangen; daraufhin wird der Alarm beim Android AlarmManager gelöscht oder gesetzt, wie oben in Punkt 5. erörtert.

Es hat sich der Status der App geändert – also müssen wir noch die Einstellungen in die DataApi sichern und rufen hierzu unsere Methode schreibe Einstellungen(boolean enabled) mit dem isChecked() Status des Buttons auf.

 

 

8. App auf Handy und Uhr laufen lassen

Um die App von Android Studio auf die Uhr zu laden ist ein klein wenig Vorarbeit nötig.

Die Idee dahinter ist, die Uhr mit Bluetooth mit dem Handy zu verbinden, das Handy ist währenddessen via USB an den PC angeschlossen. Als Ziel soll der PC mit der Uhr über USB mit dem Handy und dann über Bluetooth mit der Uhr kommunizieren und vice versa.

Um Debugging zu aktivieren muss nun folgendes gemacht werden:

1. Aktiviere USB Debugging auf dem Handy
   1. Gehe in die Einstellungen und suche ganz unten nach Entwickler Einstellungen
   2. Sollte der Eintrag nicht vorhanden sein, gehe zu Über das Telefon und drücke ein paar mal auf die Build Number. Gehe zurück und zu den jetzt erschienenen Developer Options.
   3. Aktiviere den Eintrag USB Debugging
2. Aktiviere Bluetooth Debugging auf der Uhr.
   1. Dies geht ebenso in den Entwickler Einstellungen in dem Settings Screen.
   2. Den Settings Screen erreicht man, indem doppelt auf den Homescreen getippt wird.
   3. Sollten die Developer Options nicht vorhanden sein, wiederhole obiges Spiel mit der Build Number
   4. Aktiviere Debugging über Bluetooth

In den Einstellungen der Android Wear App auf dem Handy muss noch Debugging über Bluetooth aktiviert werden. Der Status hierbei lautet jetzt Host: disconnected, Target: connected. Nun sind die Voraussetzungen erfüllt.

Als nächstes müssen wir eine „Weiterleitung“ zwischen der Uhr und dem Handy herstellen. Hierzu müssen wir in einem Terminal zwei adb (Android Debug Bridge) Befehle ausführen.

Navigiere mit cmd (für Windows. Erreichbar via Win-Taste + R und dann cmd starten) in das Verzeichnis, wo das Android-Sdk gespeichert ist und anschließend in den Ordner platform-tools (Linux und Mac Nutzer nehmen ihre Bash Shell). Wenn ihr Android Studio installiert habt, sollte sich der SDK Ordner innerhalb des Installations-Ordners befinden. In diesem Verzeichnis liegt das Executable von adb.

Der Befehl zum Navigieren lautet bei allen Betriebssysteme cd "/pfad/zum/ordner" (in Windows mit einem C:\ bzw. dem entsprechenden Laufwerksbuchstaben davor).

Nun führen wir hinterinander die folgenden zwei Befehle aus:
adb forward tcp:4444 localabstract:/adb-hub
adb connect localhost:4444

Der Bluethooth Debugging Status in der Android Wear App sollte sich jetzt geändert haben: Host: connected, Target: connected

 

Ab jetzt könnt ihr Befehle direkt auf der Uhr ausführen, indem ihr -e als Parameter an adb übergebt (übrigens: diese Kurzschreibweise klappt nur, wenn keine Android Emulatoren zeitgleich laufen).

Beispiel: adb -e logcat um in Echtzeit den Logcat der Uhr zu sehen.
(Für Linux/Mac User: Es lohnt sich die Ausgabe nach einem Teil des Packagenamens zu filtern: ./adb -e logcat | grep de.mammuth.)

 

Um die App jetzt auf die Uhr zu deployen, öffnet ihr die WearActivity im Wear-Modul, macht einen Rechtsklick und wählt Run ‚WearActivity‘ .

Es erscheint der gewohnte Dialog zur Geräteauswahl und hier wird die Uhr ausgewählt. Die Verbindung ist etwas langsam, habt also Geduld, bzw. beobachtet den Fortschritt in der Console von Studio.

 

Referenz hierzu auf developer.android.com

 

9. Weiterentwicklung & Optimierungsmöglichkeiten

Die App ist an einigen Stellen absichtlich vereinfacht oder (zu Gunsten der Verständlichkeit) teils etwas nicht optimal programmiert.

Auch gibt es einige naheligenden Erweiterungen, die getroffen werden können, wovon ich hier ein paar nennen möchte, sodass die Möglichkeit besteht, selbst ein bisschen weiterzubasteln.

1. Einstellung für Erinnerungsintervall
   1. Die App ist aktuell hardgecoded, dass sie alle 60 Minuten erinnert. Hier sollte man mehrere Zeiten anbieten, wie 30 Minuten oder 2 Stunden. Die Methode getErstenAlarm() in der Klasse ErinnerungVerwalter enthält schon die Anpassung für 30 Minuten.
   2. Wenn hier etwas geändert werden soll, muss sich überlegt werden, was alles angepasst werden muss. So ist es zB. primär das Speichern der Einstellungen, das überarbeitet werden muss.
   3. Von der Benutzung her würde ich vorschlagen, dass die Wear App nach wie vor nur de-/aktivieren kann, und man das Intervall am Handy einstellt. Hier eignen sich zB. RadioButtons für 2-3 Intervalle.
2. Design
   1. Man könnte ein Hintergrundbild (oder Farbe) einbauen und die Settings in GoogleNow ähnliche Cards verpacken. Dadurch sähe das Ganze gleich um Welten besser aus.
   2. Um eine solche Card zu erstellen, reicht es ein Layout zu definieren, welches um die gewünschten Card Elemente herum ist, und dieses mit ein paar Attributen anzupassen. Am einfachsten ist es, den Background des Layouts auf diese Drawable zu setzen, die ich vorbereitet habe. (Hierfür gibt es ab Android 5 übrigens auch extra Views wie die CardView: https://developer.android.com/training/material/lists-cards.html)
   3. Das Design der Wear App kann optimiert werden, indem man einen hübscheren Toggle Button erstellt. Auch sollte man ein BoxInsetLayout verwenden, statt der zwei separaten Layout-Dateien.
3. Die Notifications können verschönert werden, indem man ein bigBackgroundImage setzt, welches auf der Uhr dann unter der Notification angezeigt wird.
4. Animationen. Je nachdem, was zuvor schon gemacht wurde, können Views animiert werden. Wenn man in der Handy App zB. mehrere RadioButtons hat – warum lässt man diese nicht leicht einfaden oder ähnliches: https://developer.android.com/guide/topics/graphics/view-animation.html