«App oder nicht?» - ein Hackathon-Erfahrungsbericht

Problemstellung

Bei der OFFLINE evaluieren wir laufen unsere Produkte, die eingesetzte Software und unsere Vorgehensweisen. Immer mit dem Blick darauf, ob unsere Lösung noch den Anforderungen unserer Kunden gerecht wird. Mit dem Release der CareSuite 5 war wieder so ein Zeitpunkt gekommen, in dem wir unser Leistungsportfolio als Ganzes betrachtet haben.

Die CareSuite 5 bietet Pflegepersonal die Möglichkeit ihre Arbeit gezielter und effizienter zu verrichten. Bisher ist die Applikation jedoch ausschliesslich stationär als Desktop-Anwendung verfügbar. Damit die CareSuite sich noch besser in den flexiblen Pflegealltag integriert, braucht es neue, mobile Bedienmöglichkeiten: das Smartphone.

Da so eine gravierende Ausweitung des Produktportfolios immer mit einem Risiko und viel Aufwand verbunden ist, darf die Entscheidung zu mobilen Apps nicht leichtsinnig vollzogen werden. Dieser Blogbeitrag beschreibt unseren Weg zur Entscheidung, eine App zu entwickeln und unseren ersten Hackathon, in welchem wir in einer Kurzstudie die Machbarkeit einer solchen App überprüften.

Die Herausforderung

Gefühlt jede:r Programmierer:in wurde bereits danach gefragt, «ob sie/er denn eine coole App programmieren könne». Die Antwort ist leider ähnlich komplex wie die Aufgabe selbst. Die Bandbreite von verfügbaren Apps reicht von rein informativen Applikationen, welche genauso gut als einfache Website umgesetzt werden können, zu komplexen Aufgabenstellungen, welche sogar Desktop-Applikationen in den Schatten stellen.

Was soll die App also können? Die App soll den Benutzern der CareSuite erlauben, nicht nur am Arbeitsplatz die aktuellen Informationen abzurufen, sondern von überall aus.

Der Elefant im Raum

Um das grösste Problem gleich anzusprechen: Die App Entwicklung ist für uns Neuland. So stellen sich uns zwangsläufig die Fragen:

Schnell wurde uns klar, dass wir diese Fragen nicht von heute auf morgen und schon gar nicht ohne intensives Lernen beantworten können. Aber zu gross war unsere Motivation Neues zu lernen und unseren Kunden die CareSuite auch auf dem Smartphone anzubieten.

Als grosse Fans des «Learning by Doing» entschlossen wir uns, bei einem Hackathon eine Proof-of-Concept Applikation zu entwickeln, um uns diese Fragen zu beantworten.

Bewaffnet mit Maus, Tastatur, Headset und Webcam starteten wir also unser Abenteuer «App»!

Problemlösung

Hack-a-wasgenau?

Los gehts mit dem Abenteuer «Hackathon». Hack-a-wasgenau? Die Metapher mit dem Abenteuer beschreibt diese explorative Methodik sehr treffend. Bei beiden versucht man ein Ziel zu erreichen, man weiss nicht was einem erwartet und meist sind die gemachten Erfahrungen wichtiger als das Ziel selbst.

Zu Beginn des Hackathons steht die Aufgabe beziehungsweise das Ziel: In unserem Fall war dies eine simple CareSuite App zu entwickeln, welche nichts mehr tut als Patienten-Rufe anzuzeigen und per Push Notification auf diese Aufmerksam zu machen. Ein Bruchteil der Anforderungen an eine ausgewachsene Applikation, aber genug um uns mit den nötigen Werkzeugen vertraut zu machen.

Vorbereitungen werden bei Hackathons meist nur minimale getroffen - die Teams sollen sich ohne grosse Vorgaben möglichst organisch dem Problem stellen. Da die Fülle der möglichen Technologien bei uns sehr gross ist, haben wir bereits etwas recherchiert und uns auf zwei Frameworks (Cordova/PWA und Flutter) festgelegt, die wir jeweils in zwei Teams untersuchen möchten.

Wie läuft ein Hackathon ab?

Wir trafen uns wohlgenährt an einem Samstag um halb 2 (coronabedingt) digital im Konferenzraum. Da die Teams bereits definiert und die Technologien verteilt wurden, konnten wir nach wenigen Minuten loslegen.

Hackathons sind meist schnell getaktet, das heisst es finden viele Meetings statt um sich über den aktuellen Projektstand auszutauschen. Bei diesen Meetings wird jeweils der Stand abgeglichen, Erfahrungen ausgetauscht und die bisherige Arbeit kurz präsentiert.

Nach anderthalben Tagen mit viel Austausch, Freude und Trauer trafen wir uns am Sonntagabend, um unsere Erkenntnisse zu besprechen und unsere zentrale Frage «Können wir selbst eine App entwickeln, und wenn ja, mit welcher Technologie?» zu beantworten.

Hürdenläufer

Selten geht ein Informatikprojekt ohne mindestens kleinere Probleme über die Bühne. Auch wir mussten einige Hürden überwinden, einige davon haben wir uns sogar selbst in den Weg gelegt.

So setzte das Team «PWA» relativ viel Vertrauen in das Cordova Framework. Das Versprechen, die PWA zu einer nativen Applikation zu konvertieren war verlockend und Cordova schien eine grosse Community zu haben.

Bald wurde aber ein kritisches Problem festgestellt: Um die Push Benachrichtigungen einzubauen wurde ein spezielles Cordova-Paket benötigt. Dieses wiederrum benötigte die (Apple eigene) Entwicklungsumgebung XCode. Da diese nicht auf Windows/Linux Geräten installiert werden kann, war dies für uns ein Dealbreaker.

Deshalb musste das Team «PWA» von Cordova abweichen und weiterhin auf eine «reine» PWA zu arbeiten. Dies war ein gutes Learning. Frameworks sind nicht immer das Gelbe vom Ei und meistens lohnt es sich klein anzufangen und die Applikation schrittweise zu skalieren.

So wurden auch im Bereich der Push Notifications viel gelernt - sind diese bei nativen Applikationen relativ einfach einzubauen, benötigen sie für PWAs wesentlich mehr Aufwand.

Das Team «PWA» bewegte sich gezielt in der Nähe der von uns beherrschten Web-Technologien. Als Gegenstück dazu beschäftigte sich das zweite Team mit der nativeren und uns gänzlich unbekannten Variante: Flutter.

Flutter ist ein UI Toolkit von Google, welches in der Programmiersprache Dart geschrieben ist. Das Versprechen von Flutter ist es, eine einheitliche Codebasis auf Android, iOS sowie allen gängigen Betriebssystemen als native App veröffentlichen zu können.

Nach der Installation von Android Studio sowie dem Download von gefühlten 100 GB an Android SDKs und Emulatoren war Team Flutter nach relativ kurzer Zeit einsatzbereit. Obwohl Dart für uns komplettes Neuland war, fanden wir uns in der an C angelehnten Syntax schnell zurecht.

Mit nur wenig Mühe konnten wir innerhalb eines Tages einfache App-Layouts darstellen, Listen rendern, HTTP-Requests ausführen und Push-Notifications versenden.

Natürlich gab es aber auch beim Team Flutter Punkte, die negativ aufgefallen sind:

• In Flutter werden (ähnlich wie z. B. bei React) alle Layouts direkt im Code definiert. Es gibt also keine separate Template-Sprache, sondern nur eine endlose Verschachtelung von Dart-Objekten und Funktionsaufrufen. Dies wird besonders bei komplexeren Layouts sehr schnell unübersichtlich und bedarf guter Planung.

  Widget build(BuildContext context) {
  return Container(
    padding: const EdgeInsets.fromLTRB(8.0, 8.0, 8.0, 0.0),
    child: SizedBox(
      height: 200,
      child: ListView.builder(
        scrollDirection: Axis.vertical,
        shrinkWrap: true,
        itemCount: calls.length,
        itemBuilder: (BuildContext context, int index) {
          String key = calls.keys.elementAt(index);
          var data = calls[key];
          var date = DateTime.now()
              .difference(DateTime.parse(data["opened_at"])).inSeconds;
          print("Value: $data");
          return new Column(
            children: [
              new ListTile(
                title: new Text(data["call_type_text"]),
                subtitle: new Text(data["device_text_short"]),
                trailing: new Text(date.toString() + "s"),
                leading: new Icon(Icons.notifications_active)
              ),
              new Divider(),
            ]
          );
        }
      ),
    ),
  );
  }

• Die Zukunft von Flutter und Dart ist ungewiss. Beide Technologien gibt es bereits mehrere Jahre, leider haben sie aber nie so richtig an Fahrt aufgenommen. Flutter sowie Dart werden permanent weiterentwickelt und sind daher sicher noch weit entfernt davon, «Abandonware» zu werden. Wir brauchen jedoch eine Basis die mehrere Jahre hält und möchten uns daher nur ungern auf Google verlassen: Bekanntlich werden dort nicht-rentable Projekte gerne von heute auf morgen komplett gestrichen.

• Auch wenn Flutter viel des uns unbekannten Nativen der verschiedenen Zielplattformen abstrahiert, wird besonders bei Problemen schnell sehr spezifisches Know-How notwendig - welches wir derzeit nicht haben.

Fazit

Wie erwähnt - der Weg ist das Ziel und die Erfahrungen sind wichtiger als das endgültige Produkte - zumindest bei einem Hackathon.

Technisch

Nach diesen anderthalb Tagen waren wir nun in der Lage, unsere zentrale Frage zu beantworten:

Als Arbeitsinstrument

Die Erfahrung-über-der-Erfahrung hat uns den Wert eines Hackathons für kommende Projekte aufgezeigt. Da alle Entwickler in dieser Zeit dediziert an nur einem Problem arbeiteten, konnten wir schnell eine solide Basis erarbeiten.

Gerade in Zeiten in denen das Telefon alle 5 Minuten klingelt und neue Projekte Aufmerksamkeit verlangen, ist dies ein wertvolles Instrument, welches wir für neue Projekte gerne wieder einsetzen werden.