In den letzten vier Wochen war ich intensiv mit der Planung, sowie mit Tests und Experimenten beschäftigt. Hierbei konnte ich interessante und coole Techniken, Libraries und Plugins finden, wurde aber auch in meiner Annahme, dass die Arbeit komplexer wird als ich es mir gewünscht hatte, bestätigt.

Planung

Derzeit plane ich gröbere Arbeitsblöcke für das nächste Halbjahr ein. Bis zum Ende der sechs Monate (April 2017) muss die App fertiggestellt sein.

Ende dieses Monats (1 / 6) soll eine tiefgründig ausgerichtete Detailplanung aufgestellt sein. Ein sehr tückischer Akt, da ich keine Erfahrung im App-Programmieren besitze, die Frameworks und Dienstleister erst neu auf den Markt gekommen sind und ich zeitlich stark limitiert bin.

Um den Misserfolgsfaktor maximal zu reduzieren habe ich bereits diverse Voraussetzungen an mich selber erfüllt und neue aufgestellt. Die Entscheidung dieses Projekt überhaupt aufzunehmen habe ich definitiv erst nach einem Probelauf mit einer Test-App getroffen (Nativescript Tutorial App). Die erste Schranke wäre damit überwunden. Mein Ziel ist es jede weitere Schranke zu öffnen, und sollte dies mal nicht klappen weil eine Funktion nicht implementierbar oder zu zeitaufwändig ist, so werde ich den bestmöglichen Umweg suchen und wieder auf den Weg zurückfinden.

Experimente

Zur Planung gehört auch die Definierung einer Funktions-Liste. Über Wochen und kürzlich auch sehr intensive Tage habe ich mich beim Üben und Recherchieren inspirieren lassen.

Was wünscht sich ein Klavier-Spieler?
Die Antwort darauf soll sein: Apphoven!

Ich habe eine umfassende Liste mit diversen Werkzeugen und Funktionen aufgestellt, die sich ein (angehender, als auch fortgeschrittener) Pianist wünscht. Beim Klavierüben im Duo sehne ich mich bereits seit langem nach einem stillen, aufzeichnenden Metronom. Jeder kann das Tempo mithilfe des lauten metrischen Schlags halten. Interessanter wird es jedoch, wenn die App zuhören, den Beat erkennen und dann auf das Tempo schliessen könnte. Während des Übens hätte man quasi eine Geschwindigkeitsanzeige, wie man sie aus der Amatur von Autos kennt. Noch interessanter wäre aber die Analyse: An welchen Stellen wurde unbewusst beschleunigt und verlangsamt? 

Um solche Funktionen zu ermöglich, muss grosses technisches Know-How gegeben sein. Daher wird es eher schwierig die Funktion zu implementieren. Ich habe recherchiert und komme nun zu einer, der wichtigen Erkenntnisse der Experimentier-Phase.

# Native Library Konflikt

Android als auch iOS haben diverse native Bibliotheken, die sich ums Audio-Processing kümmern. Nativescript unterstützt diese als Thrid-Party-Plugins zwar, setzt aber eine duale Programmierung voraus. Sollte ich es abgesehen von der Komplexität der Beat-Recognition und MIDI-Programmierung schaffen solch ein stilles Metronom für eine der beiden Plattformen zu programmieren, müsste ich für die andere von Null anfangen. Wenn es soweit ist, werde ich mich wohl vorerst auf die Android-Programmierung fokussieren, da ich bereits einige Recherchen zum Thema im Android-Developing-Bereich anstellen konnte.

# Modularität

Um in diesem komplexen Wirrwarr nicht unterzugehen, setzte ich auf modulare Programmierung. Mitunter der Hauptgrund, wieso ich mich für Angular2 entschieden habe:

Services & Funktionen, die von verschiedenen Komponenten der App benötigt werden, sind extra einzelne, unabhängige Bestandteile der App:

Die Login-Komponente der App benötigt beispielsweise einen Service, welcher eine Verbindung zu Firebase zur Authentifikation öffnet. Dieser Service soll jedoch kein fester Bestandteil der Login-Komponente sein, er wird per Import eingebunden. Der Zweck ist folgender: Die App benötigt für die meisten Funktionen ständig eine Verbindung zur Firebase-Datenbank. Auch die Inhalte für den Theorieteil, das Profil etc. werden von Firebase abgerufen.

Datenbank-Service
Login-Komponente (Firebase-Service Import)
Profil-Komponente (Firebase-Service Import)
Theorie-Komponente (Firebase-Service Import)

Um den Verbindungs-Service nicht für jede Komponente neu zu erstellen, wird dieser einmalig, objektorientiert programmiert und zur Wiederverwendung ausgelegt. Per Import kann der Service dann ganz einfach überall verwendet werden. Die Vorteile der Modularität liegen auf der Hand: Wartungen und Problemsuche sind deutlich einfacher und effizienter; kein doppelter Code (weniger Speicherplatz wird beansprucht, weniger Fehlerpotential, mehr Übersicht). Ausserdem können Services und Komponente modular dazu- oder abgeschaltet werden. Sollte das stille Metronom schlussendlich doch nicht wie gewünscht funktionieren, kann ich die betreffenden Services und Komponente einfach ausklinken und die App funktioniert dennoch einwandfrei weiter!

Ausblick

Der nächste Blogpost wird das Thema Git & Github behandeln. Bereits jetzt habe ich eine Repository für Apphoven erstellt, in welcher ich mit der Programmierung der App anfange: Das Grundgerüst der App und Testfunktionen werden in dieser Pre-Alpha Version der App erstellt.

Wer sich den Code schonmal anschauen und live bei der Entwicklung dabei sein will, kann unter folgendem Link die Github-Repo finden:

 apphovenAlpha