Neuerungen seit dem letzten Semester

• Filteroptionen in der Rezeptliste

Der größte strukturelle Umbau fand in der Rezeptliste statt. Bisher wurden die Rezepte einfach als rohe Liste angezeigt, ohne Möglichkeit zur Filterung. Jetzt gibt es eine eigene Suchleiste mit Autocomplete-Vorschlägen der gefilterten Drinks, eine alphabetische Sortierung mit Drink-Nummer pro Karte, sowie einen Toggle-Filter für Signature Drinks.

• Kommentar-Sektion bei den Recipes

Das Herzstück des Projektes war die Erweiterung, dass jedes Rezept nun eine vollwertige Community-Section hat. User:innen können Kommentare mit Sternebewertung hinterlassen, auf Kommentare anderer antworten und eigene Kommentare wieder löschen. Die Bewertungen fließen in eine Durchschnittsbewertung ein, die prominent im Header der Rezeptkarte angezeigt wird. Die gesamte Kommunikation läuft in Echtzeit über WebSockets.

• Benötigte Zutaten einer Einkaufsliste hinzufügen

Bisher wurden alle nicht angegebenen Zutaten bei der Hauptsuche automatisch gesammelt und global in meinem Code zwischengespeichert. Das wurde grundlegend über ein Einkaufslisten-Feature überarbeitet: Pro Rezept kann der/die Nutzer:in nun selbst entscheiden, ob er/sie die fehlenden Zutaten zur Einkaufsliste hinzufügen möchte. Fehlende Zutaten werden in der Zutatenliste farblich in Orange hervorgehoben. Ein einzelner Button pro Rezept überträgt dann gezielt nur die fehlenden Zutaten in die Einkaufsliste. Die Einkaufsliste selbst unterstützt den Export als PDF über den nativen Android PrintManager sowie im CSV-Format.

Neben diesen Änderungen konnten viele Bugs behoben werden. Speziell einige Bugs, die die Funktionalität rund um die Erstellung von “Signature Drinks” (anlegen/löschen) als auch den Umgang mit gekennzeichneten Favoriten-Rezepten, eingeschränkt haben, existieren nicht mehr.

Technischer Part

Der Großteil an Technologien ist gleich geblieben. Im Frontend setze ich weiterhin auf NativeScript Angular bzw. Tailwind für das Design und im Backend SpringBoot. Das Backend habe ich dieses Semester erstmalig über den Online-Service Railway gehostet. Dazugekommen sind vor allem die WebSocket-Bibliothek @stomp/stompjs im Frontend sowie die entsprechende Spring WebSocket-Abhängigkeit im Backend.

Für die Kommentar-Funktion war von Anfang an klar, dass klassische HTTP-Requests nicht ausreichen , sonst wäre ein ständiges manuelles Aktualisieren notwendig gewesen, um neue Kommentare zu sehen. Die Wahl fiel auf WebSockets mit STOMP, einem einfachen Messaging-Protokoll das auf WebSocket aufsetzt und ein Publish-Subscribe-Modell ermöglicht. Im Spring Boot Backend wird dabei ein Message-Broker konfiguriert der eingehende Nachrichten an alle Subscriber des jeweiligen Rezept-Topics weiterleitet. Jedes Rezept hat seinen eigenen Kanal, zum Beispiel /topic/recipe/42/comments. Nur Nutzer:innen die gerade dieses Rezept offen haben, empfangen die Kommentar, die zu diesem Rezept abgegeben wurden. Der Controller nimmt neue Kommentare entgegen, speichert sie und schickt sie sofort an alle aktiven Subscriber:

@MessageMapping("/comments/create")
public void createComment(CreateCommentRequestDto request, Principal principal) {
    User author = userRepository.findByUsername(principal.getName())...;
    CommentResponseDto saved = commentService.createComment(request, author);
    messagingTemplate.convertAndSend(
        "/topic/recipe/" + request.getRecipeId() + "/comments", 
        saved
    );
}

Im Frontend übernimmt ein dedizierter CommentWebSocketService die gesamte Verbindungslogik. Er verwendet die @stomp/stompjs Bibliothek, schickt den JWT-Token beim Verbindungsaufbau mit und subscribt auf den zum Rezept passenden Topic-Kanal:

this.stompClient = new Client({
    webSocketFactory: () => new WebSocket(`wss://...railway.app/ws`),
    connectHeaders: { Authorization: `Bearer ${this.authToken}` },
    reconnectDelay: 5000,
});

this.stompClient.onConnect = () => {
    this.stompClient.subscribe(
        `/topic/recipe/${this.recipeId}/comments`,
        (message) => {
            const comment = JSON.parse(message.body);
            onCommentReceived(comment);
        }
    );
};

Herausforderungen & Learning(s) daraus

Die größte Herausforderung des Semesters waren eindeutig die WebSockets. Theoretisch klingt es simpel (Verbindung öffnen und Nachrichten empfangen), jedoch in der Praxis gab es einige Hürden. Zuerst die Authentifizierung: anders als bei normalen HTTP-Requests musste der JWT-Token über die STOMP connectHeaders mitgeschickt und im Backend extra validiert werden. Dann das Problem mit inaktiven Verbindungen, denn ohne der sogenannten “Heartbeat-Konfiguration” auf beiden Seiten kamen Nachrichten irgendwann einfach nicht mehr an (Fehlermeldungen wurden nicht geworfen). Zu guter Letzt das Aufräumen der Verbindungen, denn ohne explizites disconnect() blieben im Hintergrund immer mehr aktive Verbindungen offen.

Was das Aufräumen so schwierig gemacht hat, war der Pager, mit dem man zwischen den Rezepten swipen kann. NativeScript’s Pager-Komponente erstellt alle Rezept-Items gleichzeitig beim Laden, bei 14 Rezepten also sofort 14 WebSocket-Verbindungen und 14 HTTP-Requests, obwohl der/die Nutzer:in nur ein einziges Rezept sieht. Noch dazu wird ngOnDestroy beim Wischen zwischen den Items nicht zuverlässig aufgerufen, weil der Pager seine Views intern recycelt statt sie wirklich zu zerstören. Dadurch hat die Cleanup-Logik nie gefeuert.

Die Lösung war letztlich ein Umdenken: statt auf ngOnDestroy zu vertrauen, steuert jetzt ein Flag, ob die Kommentar-Sektion überhaupt gerendert wird. Sobald der Nutzer wegwischt, verschwindet die Komponente via *ngIf aus dem DOM, damit das Cleanup zuverlässig durchläuft. Das wesentliche Learning dabei, war ein gut ausgebautes Debugging zu haben.

Fazit und zukünftige TODOs

In diesem Projektabschnitt konnte ich mich erstmalig herausfordernd damit befassen, wie WebSockets technisch umgesetzt werden. Das war gleichzeitig eines der interessantesten und aufwändigsten Themen des Semesters. Die vielen Debugging-Sessions haben mich aber auch am meisten weitergebracht. Rückblickend bin ich sehr zufrieden damit, was ich mir vorgenommen hatte auch tatsächlich vollständig umgesetzt zu haben. Gerade das Bugfixing war diesmal besonders aufwändig, hat aber mit großem Erfolg geendet und manche Features meiner App brauchbarer gemacht.

An diesen Dingen sollte nun weitergearbeitet werden: Performance-seitig gibt es noch Luft nach oben, sowohl beim initialen Laden als auch bei den Screen-Wechseln merkt man stellenweise noch Verzögerungen die es zu optimieren gilt. Auch das Design ist noch nicht wirklich durchgängig einheitlich, was ich in einem nächsten Schritt konsequenter angehen möchte. Dazu kommt, dass ich bisher kaum echtes User-Feedback eingeholt habe, das soll sich ändern. Auf technischer Seite fehlen noch automatisierte Tests, die zur noch besseren Stabilität der App beitragen sollen. Schlussendlich wäre das große Ziel die App veröffentlichen zu können.

Beitragsbild: dieses wurde mittels Einsatz von KI erzeugt

The post Projekt WS25 | MixMatch (Fortsetzung) appeared first on Mobile USTP MKL.

Aufgabenstellung

Die einzige Vorgabe war, dass das Projekt eine technische Herausforderung beinhalten muss. Nachdem wir drei Ideen gesammelt hatten, entschieden wir uns dazu, eine App zu entwickeln, die Menschen motiviert, die Zeit wieder mehr mit ihren Liebsten zu genießen, ohne auf das Handy zu schauen. Die technische Herausforderung lag hierbei vor allem in der Verbindung zwischen den Geräten durch Bluetooth, aber auch in der Erstellung einer nativen, production-ready App.

MVP

Anfangs wurde von uns selbst ein MVP mit den grundlegendsten Funktionen definiert. Dazu zählte, sich als User einloggen bzw. registrieren und Sessions starten zu können, in der das Handy nicht verwendet werden sollte. Weiters ist es wichtig, die Verbindung zwischen den Geräten (egal ob NFC, BLE etc.) herzustellen und aufrechtzuerhalten. Die App sollte erkennen, wenn jemand das Handy verwendet, und das den anderen Geräten mitteilen. Wir hatten die Idee, dass die User*innen mehrere Modi spielen können, wobei nur der “Bill Splitter” zum MVP zählt. Dabei sollte man einen Rechnungsbetrag eingeben können und die App zeigt an, wer wie viel schlussendlich zahlen muss, basierend darauf, wie oft jeweils das Handy verwendet wurde. Die App sollte grundsätzlich nativ auf beiden Plattformen (iOS und Android) entwickelt werden und am Ende production-ready sein. Zudem hatten wir uns vorgenommen, eine CI/CD-Pipeline fürs Backend aufzusetzen und eine Website mit rechtlichen Informationen und Links zur App zu entwickeln. Die Website spielt vor allem für die Releases in den Stores eine Rolle.

Nice To Have

Als “Nice To Have” hatten wir uns primär die Erweiterung um 2 zusätzliche Modi vorgenommen: Beim Modus “Pot Lock” legen die Spieler*innen anfänglich fest, welcher Betrag pro Person in einen virtuellen Topf gegeben werden soll, und ab welcher Handynutzungsgrenze (“Threshold”) man seinen Einsatz verliert. Am Schluss teilen sich die Personen, die den Threshold nicht überschritten haben, den Topf. Beim Modus “Group Jar” legt die Gruppe einen Preis pro Handynutzung fest und am Ende der Session sagt die App, wer wie viel insgesamt in die Gruppenkasse zahlen muss.

Weitere Nice-To-Haves waren die Möglichkeit, dass Spieler*innen auch mittendrin einer Session beitreten können (falls jemand sich z. B. verspätet), dass sie sich nach einem Disconnect wieder reconnecten können und dass sie auch früher die Session verlassen können (falls jemand z. B. schon früher nach Hause gehen muss). Abgesehen davon wollten wir, dass die App auch komplett offline funktioniert, damit man sie auch in einer Keller-Bar mit schlechtem Empfang nutzen kann. Zusätzlich wollten wir die App zumindest in einem Store veröffentlichen.

Weiters hatten wir viele coole Ideen, die App durch Features wie Mini Games, einer KI-Funktion zum Rechnung-Scannen (für den Modus “Bill Splitter”), einer History, einem Streak, einer Realtime Abstimmung (für Notfallsituationen, in denen die Handynutzung toleriert wird), einem SSO-Login und einer direkten Zahlung in der App bzw. einer Importfunktion in eine App wie Splitwise oder Tricount zu erweitern, allerdings blieb dafür leider keine Zeit mehr – zumindest in diesem Semester.

Verwendete Technologien

App

Die Apps wurden jeweils nativ, in Swift für iOS und Kotlin für Android geschrieben, um Erfahrung im Bereich der nativen App-Entwicklung zu sammeln.

Website

Die Website wurde mit Next.js, einem React-basierten Framework entwickelt. Für das Styling wurde Tailwind CSS verwendet und für eine typsichere Entwicklung haben wir uns für TypeScript entschieden. Wir verwenden eine klassisch komponentenbasierte Architektur mit wiederverwendbaren Komponenten. Für die Containerisierung verwenden wir Docker.

Projektablauf

Die Arbeit am Semesterprojekt wurde in Sprints aufgeteilt (die an Masterklassen-Einheiten orientiert waren, wobei wir intern auch hin und wieder Meetings dazwischen hatten, wenn der Abstand zwischen den Masterklassen Einheiten zu lange war).

Als Projektmanagement-Tool und zum Verwalten des Backlogs wurde die Software “Linear” verwendet: vor jedem Sprint definierten wir, wer an welchen Tickets arbeitet und teilten diese im Team auf.

Das Endprodukt

Wir haben die MVP Funktionalitäten und Nice-To-Haves wie beschrieben umgesetzt, mit den folgenden kleinen Anpassungen: Unsere App funktioniert komplett offline mit Bluetooth LE und die Session ID wird über das Scannen eines QR-Codes unter den Spieler*innen ausgetauscht. Das Backend hatten wir zwar anfänglich aufgesetzt, es wird momentan allerdings nicht benötigt. Zusätzlich zu den 3 Modi gibt es nun auch einen vierten Modus, das “Basic Leaderboard”, mit welchem sich User*innen ihre eigenen Regeln festlegen können. Weiters implementierten wir einen Solomodus, sodass die App nicht nur in der Gruppe, sondern auch alleine (z. B. beim Lernen) verwendet werden kann. Außerdem setzten wir eine coole CI/CD Pipeline für unsere Website auf und veröffentlichten unsere App in nicht nur einem, sondern in beiden Stores (Apple App Store, Google Play Store).

Link zum iOS App Store-Eintrag

Link zum Android App Store-Eintrag

Beim ersten Öffnen der App wird man durch ein Onboarding geleitet, in welchem die App kurz vorgestellt wird. Hierbei muss man auch einen Namen angeben, welcher innerhalb der App für einen selbst verwendet werden soll. Schließlich landet man am Homescreen (Abb. 3, links). Über das Profil-Icon rechts oben hat man die Möglichkeit, den festgelegten Namen zu ändern. Über den Button “Start New Session” startet man eine neue Gruppensession und kommt zum New Session Screen (Abb. 3, Mitte) – diesen Button muss allerdings nur eine Person in der Gruppe klicken. Alle anderen klicken auf “Join Session”, welcher die Kamera öffnet, um den generierten QR-Code zu scannen, welcher einen dann auch zum New Session Screen weiterleitet. Der Button “Go Solo” führt zum Solomodus, welcher weiter unten genauer beschrieben wird.

Am New Session Screen werden die aktuellen Teilnehmer*innen und der ausgewählte Modus angezeigt. Der “Host” der Session (die Person, die auf “Start New Session” geklickt hat) hat zudem die Möglichkeit, den Modus auszuwählen (Abb. 3, rechts) und notwendige Einstellungen vorzunehmen (z. B. den Preis pro Nutzung für den Group Jar Modus zu setzen).

Wie angekündigt, gibt es auch einen Solomodus. Mit dem Klick auf “Go Solo” am Home Screen kommt man zum New Focus Session Screen (Abb. 4, links), welcher wie ein Group Jar Modus funktioniert – man muss also den Preis pro Nutzung festlegen. Während der Session (Focus Session Screen, Abb. 4, rechts) sieht man die gesamte Nutzungsanzahl und wie viel Geld man sich in das eigene Sparschwein zahlen müssen wird.

Ein weiteres spannendes Feature ist das Starten des Solomodus durch das Ablegen des Handys auf eine bestimmte Stelle. Wir stellen uns den Ablauf für User*innen folgendermaßen vor:

1. User*in setzt sich an den Schreibtisch.
2. User*in legt das Handy auf eine Ablagefläche.
3. bHere App öffnet sich und Solomodus wird automatisch gestartet.

Technisch funktioniert es mit einem NFC-Tag, der einen Deeplink enthält. Für die Projektevernissage 2026 haben wir 100 Tags (NTAG215) bestellt, beschrieben und hergeschenkt. Das Feature haben wir aktuell nur für Android implementiert.

Die App ist auf beiden Plattformen sowohl in Light Mode, als auch in Dark Mode, verfügbar.

Feedback und Verbesserungsmöglichkeiten

Durch die Teilnahme an der Projektvernissage konnten wir wertvolles User-Feedback für potentielle zukünftige Erweiterungen und Verbesserungen der App sammeln: der wohl größte Pain Point der aktuellen Lösung ist die Latenz des implementierten BLE-Mesh. Vor allem bei Sessions mit einer hohen Teilnehmeranzahl kann es aktuell bis zu mehreren Minuten dauern, bis alle Daten zwischen allen Geräten ausgetauscht wurden. Sollte das Projekt noch weiterentwickelt werden, wäre das wohl eines der ersten Tickets, das umgesetzt werden müsste.

Fazit aller Teilnehmer*innen

Im folgenden Abschnitt möchten wir noch unser Fazit und unsere Erfahrungen teilen, die wir im Zuge dieses Semestergruppenprojekts sammeln konnten.

David

Die Arbeit an bHere war für mich eine intensive und lehrreiche Erfahrung. Technisch gesehen war die Implementierung der Bluetooth-Low-Energy-Kommunikation sicherlich die größte Hürde. Es hat einige Iterationen und Research gebraucht, weshalb ich umso stolzer bin, dass wir schlussendlich ein funktionierendes BLE-Mesh auf die Beine stellen konnten.

Eine wichtige Lektion war für mich die Herausforderung der parallelen Entwicklung auf zwei Plattformen. Es zeigte sich schnell: Wenn Details nicht vorab klar definiert sind, kann es passieren, dass sie auf iOS und Android unterschiedlich umgesetzt werden. Das führte dazu, dass die letzten Wochen und Tage vor der Abgabe besonders intensiv waren, da wir viele dieser kleinen Unstimmigkeiten noch angleichen mussten. Auch den Prozess der Veröffentlichung hatte ich unterschätzt – insbesondere die Vorbereitung des Store-Eintrags und die zwingende 14-tägige Testphase im Google Play Store benötigen mehr Vorlaufzeit, als man zu Beginn vermuten würde.

Andreas

Anders als bei der einwöchigen WildWeek, die wir im Laufe des 2. Semesters hatten, wurden wir in diesem Semester in einem technisch herausfordernden Semesterprojekt auf die Probe gestellt. Dies forderte ein hohes Maß an Eigenverantwortung und gute Teamkommunikation. Insbesondere, weil wir die App bhere auf zwei Plattformen (Android und iOS) gleichzeitig aufgebaut haben. Die Tatsache, dass wir uns nicht wie in der WildWeek auf direkten Wege schnell austauschen konnten, machte das Projekt umso lehrreicher, weil es auch nebenbei die heutige Home Office Arbeitsweise gut widerspiegelt hat.

Persönlich habe ich mich speziell im Bereich der Android App Entwicklung einbringen können. Dort war ich mit einigen Kollegen an der Gestaltung der UI unserer Screens dran. Neben dem Entwicklungs-Part habe ich auch an der Gestaltung unseres App-Logos beigetragen und fürs Marketing die Bierdeckeln designed, welche wir dann als Merch an die Interessent:innen verteilt haben. Ich fand die Tasks sehr abwechslungsreich und konnte mich erstmals tiefgründig mit der Programmiersprache Kotlin auseinandersetzen. Erste wirkliche Programmiererfahrung von Apps hatte ich damals noch mit Java.

Rückblickend betrachtet bin ich froh gewesen, mit unserem Team eine solch innovative App auf die Beine gestellt zu haben. Die Umsetzung hat gezeigt, dass wir mit vielen guten Ideen und einigem Kreativitätsvermögen, auch technisch herausfordernde Anforderungen meistern können. Nichtsdestotrotz ist zu erwähnen, dass der Weg dorthin nicht immer einfach war. Durch die Parallelentwicklung (Android/iOS) mussten wir ständig so up-to-date sein, dass auf beiden Systemen ein ziemlich einheitliches Design und verhalten aufgebaut werden konnte. Außerdem waren zahlreiche Testläufe nötig, bis wir eine stabile, plattformübergreifende Lösung gefunden hatten, um zwischen allen Endgeräten ein BLE-Mesh aufzubauen, über das die Kommunikation schließlich zuverlässig stattfinden konnte.

Felix

Dieses Gruppen-Semesterprojekt war für mich eine sehr spannende Herausforderung, weil wir in einem großen Team eine komplette App für iOS und Android entwickelt haben und diese dann auch veröffentlicht haben. Im Vergleich zu der Wild Programming Week war es finde ich viel anstrengender, weil wir einfach über einen langen Zeitraum uns immer koordinieren mussten. Aber im Großen und Ganzen hat alles gut funktioniert.

Zum Start haben wir zuerst ein Backend entwickelt für User Anmeldung, was dann aber nicht verwendet wurde, weil wir die App offline verwenden wollten, das war anfangs frustrierend, weil dabei Zeit draufgegangen ist, aber natürlich verständlich. Dann habe ich auch ziemlich am Anfang eine Website entwickelt, die, wie ich finde, sehr gut geworden ist. Ansonsten habe ich im Android Team und beim Merch für die Projekte Vernissage geholfen. Das fand ich am spannendsten, da ich Kotlin besser kennenlernen konnte.

Das gesamte Projekt hat mir sehr gut gefallen, vor allem weil es ein sehr reales und arbeitsnahes Projekt war. Wir waren ein gutes Team und haben gute Meetings abgehalten. Es hat alles gut funktioniert, wenn auch nicht ohne Schwierigkeiten.

Caroline

Im Vergleich zur Extreme Programming Week im 2. Semester hatten wir diesmal mehr Zeit fürs Einarbeiten und Ausprobieren, wobei die Entwicklung einer nativen App auf zwei unterschiedlichen Plattformen dafür neue Herausforderungen mit sich brachte. Ich habe hauptsächlich gemeinsam mit Katharina an der iOS-Version gearbeitet, was im Pair-Programming sehr gut funktioniert hat. Besonders hilfreich war dabei, dass sie bereits mehr Erfahrung mit Swift hatte, wodurch ich mich trotz anfänglicher Unsicherheiten schnell einarbeiten konnte.

Eine der größten Herausforderungen war die Umsetzung der Bluetooth-Low-Energy-Kommunikation. Da es auf iOS im Wesentlichen nur Core Bluetooth gibt, mussten wir viele Teile selbst erarbeiten. Zunächst mussten wir die Grundlagen von BLE verstehen und verschiedene Ansätze ausprobieren, bis wir zu einer funktionierenden Lösung kamen, die über mehrere Geräte hinweg funktioniert. Besonders hilfreich war Davids erste Umsetzung eines Meshs auf Android, auch wenn die Übertragung der Logik auf iOS aufgrund plattformspezifischer Unterschiede nicht einfach war.

Zusätzlich haben wir die iOS-Version der App im App Store veröffentlicht, was für mich eine neue und spannende Erfahrung war. Dabei habe ich einen Einblick in den Release-Prozess sowie die dafür notwendigen Schritte und Anforderungen von Apple bekommen.

Insgesamt hat mir das Projekt nochmal gezeigt, wie wichtig klare Absprachen im Team sowie ein möglichst fertiges und einheitliches Design zu Beginn eines Projekts sind. Fehlende oder unklare Definitionen führen später nämlich zu Mehraufwand und Inkonsistenzen zwischen den Plattformen. Rückblickend war das Projekt jedoch sehr lehrreich und hat mir sowohl technisch als auch im Bereich Teamarbeit wertvolle Erfahrungen gebracht.

Sebastian

Auch wenn wir im zweiten Semester die Wild Programming Week hatten, in welcher wir eine App innerhalb einer Woche entwickeln mussten, war dieses Semesterprojekt doch noch einmal ein ganz neues Erlebnis. Eine App über ein ganzes Semester zu entwickeln hat das Ganze leichter wie auch schwerer gestaltet. 

Durch den Zeitrahmen hatten wir um einiges mehr Zeit zu entwickeln, nicht wie in der Wild Week. Aber auch durch diesen größeren Zeitrahmen wurde es schwerer, da es zum einen natürlich den Projektumfang erhöht hat. Gleichzeitig war es auch um einiges schwerer, den nötigen Arbeitsaufwand einzuschätzen, wodurch man zum Beispiel zu Beginn die Arbeitspakete zu klein für einen Sprint geschätzt hat. 

Ich war vor allem mit UI Umsetzungen auf Android, zusammen mit der Implementierung der Nutzungserkennung zuständig. Bei der UI Umsetzung der die größte Herausforderung die Abstimmung zwischen Android und iOS. Zwar sind beide Plattformen von der gleichen Basis ausgegangen, auf beiden gab es aber kleiner Änderungen, welche dafür gesorgt haben, dass das Design nicht komplett einstimmig waren und hat extra Arbeit gegen Ende benötigt zum Anpassen.

Im Ganzen war es aber wieder ein gutes Erlebnis, mit einem tollen Team. Das ganze kam mit wichtigen Erfahrungen, wie Programmiersprachen Erlernung, App Store Einrichtungen und auch das erneute zeigen, wie wichtig gute Kommunikation und Abstimmung ist, um extra Arbeit zu vermeiden. Ich wäre jederzeit bereit, noch ein Projekt mit diesem Team zu machen.

Jan

Es war sehr nett, mit allen Studienkollegen der Masterklasse ein Projekt umzusetzen. Spannend war, wie sich jeder mit seinen Stärken eingebracht hat. Gerne hätte ich noch mehr an diesem Projekt gearbeitet und dafür auf andere Lehrveranstaltungen verzichtet.

Das Projekt hat sich im Laufe der Zeit in eine spannende Richtung entwickelt. Features, die wir anfangs eingeplant hatten, haben sich bei genauerer Betrachtung als nicht wichtig oder sogar als störend erwiesen und wurden daher gestrichen. Ich bin beispielsweise sehr froh über die Entscheidung, dass die App zu 100% offline funktioniert und es kein Backend gibt. Das ermöglicht den flexiblen Einsatz der App, zum Beispiel in Kellerlokalen ohne Mobilfunk, und hat den Vorteil, dass User ohne lästige Account-Erstellung direkt loslegen können. Für uns als Team bedeutet der Wegfall eines Backends, dass wir die Applikation kostengünstiger und mit weniger Aufwand betreiben können.

Wir können stolz darauf sein, dass wir eine neuartige und wirklich nützliche Applikation geschaffen haben, die ausreichend stabil läuft. Natürlich sehen wir noch einige offene Themen, die wir gerne angehen würden. Schade, dass wir vorerst kaum Zeit mehr für bHere haben werden, da wir uns nun auf unsere Masterarbeiten konzentrieren müssen.

Katharina

Das Projekt “bHere” war für mich eine besonders wertvolle Erfahrung. In meiner Rolle als Projektleiterin übernahm ich die Moderation der Sprint-Meetings, repräsentierte die Gruppe gegenüber unseren Stakeholdern (unseren Masterklassenleitern) und behielt den Gesamtüberblick über Fortschritt und offene Punkte.

Zusätzlich war ich gemeinsam mit Caro für die iOS-Entwicklung verantwortlich. Wir haben intensiv im Pair Programming gearbeitet und unsere Zusammenarbeit war dabei sehr produktiv. Besonders spannend war die Integration der BLE-Funktionalität – dank Davids Vorarbeit konnten wir diese auch erfolgreich in die iOS-App einbinden. Die BLE-Kommunikation auch plattformübergreifend zwischen iOS und Android zum Laufen zu bringen, stellte allerdings eine technische Herausforderung dar, da sich insbesondere das Debugging der Verbindung als nicht so trivial erwies.

Zeitlich war das Semester ebenfalls herausfordernder als gedacht. Im Vergleich zur “Wild Week” erforderte dieses Semestergruppenprojekt ein noch höheres Maß an Eigenorganisation und Abstimmung. Gerade gegen Ende kamen viele Aufgaben parallel zusammen, wodurch Priorisierung und Struktur besonders wichtig wurden. Für zukünftige Projekte nehme ich außerdem mit, wie wichtig ein frühzeitig klar definiertes und abgestimmtes Design ist, um plattformübergreifend noch effizienter arbeiten zu können.

Ein besonderes Highlight war für mich die erstmalige App-Einreichung im App Store. Der umfangreiche Einreichungsprozess hat uns auf der Zielgeraden noch einmal intensiv gefordert, ich konnte daraus aber auch sehr viel lernen.

Insgesamt habe ich sehr viel Arbeit und Engagement in dieses Projekt investiert – sowohl in die technische Umsetzung der iOS-App, als auch in die Organisation und Qualitätssicherung des ganzen Projekts. Umso stolzer bin ich auf das entstandene Produkt und auf das, was wir als Team erreicht haben. 

Matthias

Das Projekt hat mir einen spannenden Einblick gegeben, wie komplex die Entwicklung einer mobilen App werden kann, wenn sie plattformübergreifend funktionieren und gleichzeitig komplett offline nutzbar sein soll. Besonders spannend fand ich es, gemeinsam im Team einen Lösungsansatz für unser Bluetooth-Mesh-System zu suchen. Vor allem, weil es für unseren Anwendungsfall keine bestehende Lösung gab. Ich habe dabei auch versucht, ein eigenes Konzept zu entwickeln. Dieses war zwar noch nicht vollständig ausgereift und hätte mehr Zeit benötigt, hat mir aber geholfen, die technischen Herausforderungen besser zu verstehen und viel von den Lösungsansätzen der anderen im Team zu lernen.

Intensiver beschäftigt habe ich mich mit der Umsetzung der Nutzungserkennung unter iOS. Ziel war es, das Verhalten der App während der Nutzung besser nachvollziehen und entsprechende Daten erfassen zu können. Dabei musste darauf geachtet werden, dass möglichst ähnliche Informationen wie auf Android gesammelt werden, damit die Nutzung plattformübergreifend vergleichbar bleibt. Dadurch konnte ich mich stärker mit dem Verhalten von Apps unter iOS auseinandersetzen und besser verstehen, wie Apps im Hintergrund arbeiten und wie solche Informationen sinnvoll für die Weiterentwicklung eines Produkts genutzt werden können.

Außerdem hatte ich die Möglichkeit, den Prozess rund um die Veröffentlichung der App im Apple App Store aus nächster Nähe mitzuerleben. Es war spannend zu sehen, welche Schritte und Anforderungen notwendig sind, bis eine App tatsächlich eingereicht und veröffentlicht werden kann.

Mit am meisten Spaß haben mir die Diskussionen rund um die User Experience der App gemacht. In den Meetings habe ich gemerkt, dass mich dieser Bereich besonders interessiert und ich mich dort auch am besten einbringen kann. Die Kombination aus technischen Überlegungen und der Frage, wie sich eine App für Nutzer:innen möglichst intuitiv bedienen lässt, fand ich besonders spannend.

Während des Projekts bin ich mit vielen neuen Themen in Berührung gekommen und konnte dabei viel lernen, sowohl technisch als auch in der Zusammenarbeit im Team. Gleichzeitig war die Arbeit durch die vielen gemeinsamen Lösungsansätze sehr motivierend, wodurch das Lernen fast nebenbei passiert ist.

The post Projekt | bHere – not on your phone appeared first on Mobile USTP MKL.

Nativescript – eine kurze Vorstellung

Mit NativeScript, das 2015 auf den Markt kam, wurde ein Framework präsentiert, das plattformübergreifende mobile Apps ermöglicht und zugleich direkten Zugriff auf die nativen Funktionen von Android und iOS bietet. Seit dessen Einführung wird es kontinuierlich weiterentwickelt und hat sich zu einer stabilen Lösung für die App-Entwicklung etabliert. NativeScript erlaubt es, Apps mit bekannten Web-Technologien wie JavaScript, TypeScript, Angular oder Vue.js zu erstellen, wodurch der Einstieg für Web-Entwickler besonders einfach ist. Gleichzeitig werden die UI-Komponenten direkt nativ gerendert, was eine nahezu maximale Leistung gewährleistet. Ein Großteil des Codes kann zwischen Android und iOS weiterverwendet werden, wodurch Entwicklungszeit und -kosten reduziert werden. Damit kombiniert NativeScript die Vorteile plattformübergreifender Entwicklung mit direktem API-Zugriff und nativer Performance.

Mit diesem Wissen im Gepäck gelang es mir meine Erstentwicklung als reine WebApp in Angular ohne grundlegenden Neuanfang im nativen Bereich durchführen. Das hat mir die Möglichkeit eröffnet viele Teile der ursprünglichen Angular-Programmierung in eine App zu übertragen, auch wenn dies mit einer gewissen Komplexität einherging.

Von einer Web-App zu einer nativen App

Der Wechsel von der ursprünglichen Angular Web-App zu einer nativen App mit NativeScript stellte einen entscheidenden Entwicklungsschritt dar. Während die erste Version ausschließlich im Browser funktionierte und auf klassische Web-Komponenten ausgelegt war, verlagerte sich der Fokus nun auf die mobile Nutzung, native Performance und eine tiefere Integration in die jeweilige Plattform. Diese Veränderung erforderte nicht nur technisches Know-how, sondern auch ein grundlegendes Umdenken im App-Design. Die Benutzeroberfläche musste für mobile Endgeräte neu konzipiert werden, denn alleine responsive Layouts reichten nicht mehr aus. Stattdessen waren eine intuitive Navigation, Gestensteuerung und schnelle Ladezeiten gefragt. Technisch konnten viele Angular-Module und Services zwar grundsätzlich übernommen werden, jedoch waren umfangreiche Anpassungen notwendig, insbesondere beim Routing, der Datenbindung und dem Zugriff auf systemnahe Funktionen wie dem Dateispeicher.

Optimierter Suchalgorithmus

Der ursprüngliche Suchalgorithmus stellte einen klaren Engpass dar, da jede Filteranfrage direkt an die externe API gesendet wurde. Das führte zu langen Ladezeiten und unnötiger Netzwerklast.

Mit dem neuen, optimierten Ansatz werden die Rezeptdaten nun beim Start der Anwendung automatisch aus der API geladen und in die lokale Datenbank geschrieben. Die Suche erfolgt anschließend vollständig serverseitig über diese Datenbank, wodurch Abfragen deutlich schneller und stabiler laufen. Gleichzeitig bleibt die Filterlogik flexibel: Nutzer:innen können nach Kategorie, Alkoholgehalt und Zutaten suchen, ohne dass alle Kriterien zwingend gesetzt sein müssen.

Die “Signature”-Drinks

Dieses neue Feature bietet dem/der User:in die Möglichkeit, sich seinen/ihren Drink (Cocktail) selbst nach eigenen Wünschen zusammenzustellen. Diese Drinks in Form von Rezepten werden entsprechend gekennzeichnet und sind mit dem/der Ersteller:in verknüpft. Die Datenspeicherung erfolgt in der selben Tabelle, wo die Drink Rezepte der API abgespeichert sind. Nach dem Anlegen eines “Signature”-Drinks stehen dem/der Ersteller:in die Möglichkeit zur Verfügung den Drink . Hier ein Blick in die App (Bild folgt):

Weitere Features/Verbesserungen

Redesign

Mit dem Wechsel von einer WebApp auf eine native Mobile-App wurde das bestehende Design nicht vollständig neu entwickelt, sondern gezielt modernisiert und an mobile Nutzungsszenarien angepasst. Der Fokus lag dabei auf einer klareren visuellen Struktur, einer verbesserten Bedienbarkeit sowie einem konsistenten Erscheinungsbild über alle Ansichten hinweg.

Ein wesentlicher Schritt war die Umstellung des UI-Designs auf das Utility-First-Framework Tailwind CSS, das eine deutlich effizientere Gestaltung und höhere Flexibilität bei der Komponentenentwicklung ermöglicht. Dadurch konnten wiederkehrende Layouts vereinheitlicht, Abstände und Typografie präzise gesteuert und das gesamte Erscheinungsbild minimalistischer und moderner gestaltet werden.

Zutaten Suchfunktion

Bisher musst man sich durch eine lange Liste von Zutaten “quälen” – mit einem neuen Suchfeld bei den Zutaten wurde dies nun deutlich vereinfacht.

Herausforderungen im Entwicklungsprozess

Anbei zwei wesentliche Herausforderungen, die sich während der Entwicklungsarbeit zunehmend herauskristallisiert haben:

Die mobile Umsetzung von MixMatch mit NativeScript und Angular brachte einige technische und strukturelle Herausforderungen mit sich. Der Umstieg von der bisherigen Angular-Webumgebung auf NativeScript erforderte eine Einarbeitung in neue Syntaxkonzepte und native UI-Komponenten. Viele Layouts und Funktionen ließen sich nicht direkt übernehmen, sondern mussten gezielt an mobile Anforderungen angepasst werden. Zudem NativeScript auch noch ein sehr “junges” natives Framework ist und die Dokumentation derzeit noch nicht als allzu ausgereift erscheint.

Gleichzeitig wurde deutlich, dass Teile des bestehenden Codes, insbesondere im Hinblick auf Wartbarkeit und Performance auf mobilen Geräten, zu komplex aufgebaut waren. Um dem entgegenzuwirken, habe ich z. B. Übersetzungen in separate Lokalisations-Files ausgelagert, anstatt sie direkt im Code zu halten. Auch die Datenverarbeitung wurde angepasst: Statt verschachtelter Aufrufe zu der thecocktaildb API erfolgt die Filterung nun über eine lokale Datenbank, nachdem alle Daten der externen API einmalig gespeichert wurden.

Resümee mit Ausblick

Das Projekt stellte in mehrfacher Hinsicht eine wertvolle Lernerfahrung dar – insbesondere durch den mutigen Schritt, mit NativeScript in ein für mich völlig neues Framework einzusteigen. Dieser Ansatz bot die Gelegenheit, die Stärken und Schwächen der Plattform unmittelbar kennenzulernen: Auf der einen Seite die hohe Flexibilität, die tiefe Integration nativer Funktionen und die Möglichkeit, moderne Frontend-Technologien wie Angular und Tailwind zu kombinieren; auf der anderen Seite aber auch die typischen Herausforderungen eines jungen Frameworks – etwa eingeschränkte Dokumentation, komplexe Build-Prozesse und teils unerwartete Kompatibilitätsprobleme.

Gerade dieser direkte Umgang mit den Schattenseiten und positiven Aspekten des Frameworks hat jedoch den größten Lerneffekt gebracht. Es entstand ein tieferes Verständnis für mobile App-Architekturen, die Bedeutung einer sauberen Code-Struktur.

Auch nach Abschluss dieser Entwicklungsphase bleiben einige naheliegende Erweiterungen vorstellbar, die sich mittelfristig umsetzen lassen. Dazu zählt etwa eine Kommentarfunktion, mit der Nutzer:innen direkt Rückmeldung zu einzelnen Drinks geben oder sich austauschen können. Ebenso wäre es denkbar, die „Signature Drinks“ für andere sichtbar zu machen. Mit der individuellen Möglichkeit, eigene Rezepturen anderen Usern/Userinnen sichtbar zu machen, können persönliche Rezeptideen einem weiten Publikum präsentiert werden.
Ergänzend ließe sich eine einfache Einkaufsliste integrieren, in der fehlende Zutaten gesammelt und als Liste exportiert werden könnte. Diese funktionalen Erweiterungen würden, wie üblich, Hand in Hand mit weiterem Bugfixing, Code-Optimierungen und kleineren UI-Verbesserungen erfolgen, um die App sowohl technisch als auch inhaltlich weiter zu stabilisieren, der Benutzerfreundlichkeit hin zu optimieren und auszubauen.

Beitragsbild: dieses wurde mittels Einsatz von KI erzeugt

The post Projekt SS25 | MixMatch (Fortsetzung) appeared first on Mobile USTP MKL.

Theoretische Grundlagen:

Was steckt hinter .NET?

Der erste Teil des Workshops widmete sich die theoretischen Grundlagen meines Workshopthemas anzueignen. .NET wurde im Jahr 2000 von Microsoft eingeführt und hat sich seitdem von einer proprietären Lösung hin zu einer freien, quelloffenen und plattformübergreifenden Software-Plattform entwickelt. Heute (in Version 9/10) deckt .NET ein breites Spektrum an Einsatzmöglichkeiten ab. Dieses erstreckt sich vom Web über Desktop bis hin zu Mobile.

Zentral ist dabei die Common Language Runtime (CLR), die als gemeinsame Laufzeitumgebung dient. Sie erlaubt es, unterschiedliche Programmiersprachen miteinander zu kombinieren, wobei C# die dominierende Sprache ist. Dieses Zusammenspiel sorgt für Effizienz, Konsistenz und Flexibilität in der Entwicklung.

Das .NET Ecosystem

Um den Aufbau von .NET besser zu verstehen, lohnt sich ein Blick auf das Ecosystem:

• Runtime & Core Libraries: Basis für die Ausführung von .NET-Programmen, inklusive Garbage Collector, Just-in-Time-Compiler und Standardbibliotheken.
• Languages: Offiziell unterstützt werden C#, F# und VB.NET, wobei C# in der Praxis dominiert.
• Frameworks: Unterschiedliche Bereiche, z. B. ASP.NET Core für Web, Blazor für moderne Frontend-Entwicklung, .NET MAUI für Mobile/ Desktop oder WPF/WinForms für klassische Windows-Anwendungen.
• Tools & IDEs: Visual Studio, Visual Studio Code, CLI-Werkzeuge.
• Community & Packages: Über NuGet steht ein riesiges Paket-Ökosystem bereit, das von Microsoft und der Community gepflegt wird.

Exkurs: C# als Rückgrat von .NET

Ein kurzer Exkurs führte in die Sprache C#, die als Rückgrat von .NET gilt. Sie kombiniert eine klare, objektorientierte Struktur mit modernen Sprachkonzepten. Besonders hervorzuheben sind Features wie LINQ, Lambda-Ausdrücke oder das asynchrone Programmiermodell mit async/await, die den Entwicklungsprozess spürbar vereinfachen.

Einsatzfelder von .NET in der Praxis

Das .NET-Framework ist äußerst vielseitig und findet Anwendung in verschiedensten Bereichen:

• Web: mit ASP.NET Core oder Blazor, wo sogar C# direkt im Browser laufen kann.
• Desktop: für klassische Anwendungen auf Windows und macOS.
• Mobile: plattformübergreifend mit .NET MAUI.

ASP.NET Core Blazor

Ein besonders spannender Teil des .NET-Ökosystems und daher extra hervorzuheben ist Blazor. Mit Blazor stellt .NET ein Front-End-Webframework bereit, dass komplett auf C# setzt und JavaScript in vielen Szenarien überflüssig macht.

Es gibt zwei Hauptvarianten des Frameworks:

• Blazor WebAssembly: Führt C#-Code direkt im Browser aus – clientseitig, ohne zusätzlichen Servercode.
• Blazor Server: Nutzt eine persistente Verbindung, bei der die Logik auf dem Server ausgeführt wird und die UI-Änderungen in Echtzeit an den Browser übertragen werden.

Die Vorteile von Blazor:

• Einheitliche Codebasis für Front- und Backend (kein Sprachmix nötig).
• Höhere Entwicklerproduktivität durch Wiederverwendung von Logik und Komponenten.
• Engere Integration mit dem gesamten .NET-Ökosystem.

Native Entwicklung mit .NET MAUI

Bevor es zur Umsetzung ging, habe ich im Workshop ausführlich .NET MAUI beleuchtet…

… das Framework, mit dem sich native Anwendungen für Android, iOS, Windows und macOS aus einer einzigen Codebasis entwickeln lassen.

Das Grundprinzip:

• Die Benutzeroberfläche wird in XAML beschrieben,
• die Logik in C# umgesetzt.

Diese klare Trennung verbessert Übersichtlichkeit, Wartbarkeit und Wiederverwendbarkeit des Codes.

Ein wichtiges Architekturprinzip ist das MVVM-Pattern (Model–View–ViewModel):

• View: definiert Layout und Darstellung
• ViewModel: enthält Logik, Eigenschaften und Befehle
• Model: Datenmodell mit Geschäfts- und Validierungslogik

Mit diesem erreicht man eine saubere und skalierbare App-Struktur.

Wichtige Konzepte in .NET MAUI

Damit die Theorie greifbarer wird, habe ich im Workshop die wichtigsten Bausteine, mit denen .NET MAUI arbeitet vorgestellt – Konzepte, die auch später in der praktischen Umsetzung wiederkehren:

In .NET MAUI gibt es vier Ausführungszustände (nicht ausgeführt, laufend, deaktiviert und gestoppt), die den Lebenszyklus einer App beschreiben. Diese Zustände regeln, wann die Anwendung gestartet, pausiert, fortgesetzt oder beendet wird. Sie sind entscheidend für Ressourcenmanagement, Statusspeicherung und die Reaktion auf Benutzerinteraktionen oder Systemereignisse.

Data Binding

Das Data Binding in .NET MAUI sorgt für eine Synchronisation zwischen UI-Elementen und ViewModel-Eigenschaften. Es unterstützt verschiedene Bindungsmodi (etwa One-Way und Two-Way), wodurch Änderungen automatisch zwischen UI und Datenmodell ausgetauscht werden. Dadurch wird Boilerplate-Code reduziert und die Wartbarkeit deutlich verbessert. Außerdem erlaubt es ein dynamisches Update der Benutzeroberfläche, sobald sich Daten verändern.

Dependency Injection (DI)

Dependency Injection ermöglicht eine lose Kopplung zwischen Klassen und steigert damit die Testbarkeit der Anwendung. In .NET MAUI können verschiedene Lebenszyklen definiert werden, etwa Singleton, Transient oder Scoped. Die Registrierung der Dienste erfolgt zentral in der App-Initialisierung (App.xaml.cs), was die Verwaltung der Abhängigkeiten übersichtlich und einheitlich gestaltet.

Bindable Properties

Bindable Properties sind spezielle Eigenschaften, die eine Datenbindung in benutzerdefinierten Controls ermöglichen. Sie erleichtern das Erstellen wiederverwendbarer UI-Komponenten und sorgen dafür, dass sich die Oberfläche automatisch aktualisiert, sobald sich eine Eigenschaft ändert. So bleibt das UI stets im Einklang mit den zugrunde liegenden Daten.

Behaviors

Behaviors dienen in .NET MAUI dazu, UI-Elemente um wiederverwendbare Logik zu erweitern. Dadurch kann Verhalten wie Validierung, Animation oder Interaktion modular und flexibel hinzugefügt werden – ohne die zugrunde liegende Code-Behind-Struktur zu verändern.

Shell-Navigation

Die Shell in .NET MAUI vereinheitlicht die Navigationsstruktur einer App. Sie unterstützt deklaratives Routing und Parameterübergabe, was Navigation besonders einfach und klar macht. Zudem erlaubt sie eine bequeme Verwaltung von Flyout-Menüs, Tab-Bars und anderen Navigationselementen. So wird der Implementierungsaufwand bei komplexeren Navigationsszenarien deutlich reduziert.

Components & Layouting

In .NET MAUI lassen sich wiederverwendbare Custom Controls erstellen, um die Benutzeroberfläche gezielt zu erweitern. Neben den Standardkomponenten können Custom Renderer und Community-Bibliotheken (über NuGet) eingebunden werden, um zusätzliche Funktionalität bereitzustellen. Das Layout basiert auf verschiedenen Pages wie ContentPage, NavigationPage und ShellPage, unterstützt Responsive Design und trennt Layout von Logik – was zu klar strukturierten, modularen Anwendungen führt.

Essentials

NET MAUI Essentials bieten eine einheitliche API für den Zugriff auf native Gerätefunktionen. Damit können Funktionen wie Kamera, GPS, Akku oder Sensoren genutzt werden, ohne plattformabhängigen Code schreiben zu müssen.

Praxisteil: WeatherApp (.NET MAUI)

Nach der ausführlichen Theorie folgte die praktische Auseinandersetzung mit dem .NET MAUI Framework, bei der wir die zentralen Konzepte in einer kleinen bzw. einfach gehaltenen Anwendung erprobt und umgesetzt haben. Entstanden ist dabei eine WeatherApp, die aktuelle Wetterdaten über eine API lädt, den Standort des Geräts berücksichtigen kann und über eine einfache Navigation verfügt. Die App ist so aufgebaut, dass es drei zentrale Seiten gibt: eine Startseite, die als Einstieg dient und erklärt, was die App macht, eine Einstellungsseite, auf der der gewünschte Standort festgelegt und gespeichert werden kann, und eine Wetterseite, die die eigentlichen Daten anzeigt. Hier die graphische Ansicht:

Der eigentliche Abruf der Daten ist im WeatherService gekapselt. Er ruft die API mit dem eingegebenen Stadtnamen oder den ermittelten Koordinaten auf, verarbeitet die JSON-Antwort und gibt ein eigenes Datenmodell zurück. Dadurch bleibt die Logik von der Oberfläche getrennt, und das Modell kann im gesamten Projekt wiederverwendet werden. Auf der Wetterseite bindet das ViewModel die Daten an die Oberfläche. Sobald über den Button „Wetter abfragen“ ein Request ausgelöst wird, landet das Ergebnis in einer Property des ViewModels. Über Data Binding wird diese Property automatisch im UI angezeigt, ohne dass zusätzlicher Code für die Aktualisierung nötig ist.

Eine weitere Funktion ist die Standortabfrage über MAUI Essentials. Mit Geolocation.GetLocationAsync wird die aktuelle Position ermittelt und als Koordinaten an die API übergeben. Dadurch lassen sich exakte Wetterwerte für die aktuelle Position anzeigen. Um beim Testen nachvollziehen zu können, welche Werte vom Gerät oder Emulator zurückkommen, habe ich Logging eingebaut. Damit sieht man direkt, ob die Koordinaten plausibel sind und welche Wetterdaten von der API zurückgeliefert werden.

In den Einstellungen kann der Nutzer einen Standardort hinterlegen. Dieser wird über Preferences dauerhaft gespeichert, sodass die App beim nächsten Start direkt darauf zurückgreifen kann. Das Eingabefeld ist dabei direkt an eine Property im SettingsViewModel gebunden. Wird ein Ort eingetragen, landet der Wert sofort im Code, beim Speichern zusätzlich in den Preferences.

Die Navigation zwischen den Seiten läuft über Blazor-Routen. So bleibt die Struktur klar und konsistent: Startseite, Einstellungen, Wetteranzeige. Damit ist die App modular aufgebaut und kann jederzeit um weitere Seiten erweitert werden.

Der Source-Code des Praxis-Projektes kann hier abgerufen werden:

Fazit

Zu Beginn hat vor allem die Grundeinrichtung eines neuen .NET-Projekts mit MAUI mehr Zeit in Anspruch genommen als geplant. Künftig werde ich diesen Schritt vorab erledigen, um im Workshop mehr Zeit zu haben und hektisches Coden zu vermeiden, das am Ende nur zusätzliches Bugfixing erfordert. Gleichzeitig konnte ich erste praktische Erfahrungen mit C# und der Windows-nativen Umgebung sammeln und habe gemerkt, dass mir die Wissensvermittlung in diesem Workshop jedenfalls leichter gefallen ist, als beim allerersten Mal. Insgesamt stimmt mich das zuversichtlich, hier eine gute Grundlage geschaffen zu haben, um im 3. Semester noch tiefer in die .NET-Entwicklung einzusteigen.

Folien der Präsentation:

Lehrreiche weiterführende Links:
https://dotnet.microsoft.com/en-us/learn
https://learn.microsoft.com/de-de/dotnet/core/introduction
https://learn.microsoft.com/de-de/dotnet/maui/?view=net-maui-9.0
https://learn.microsoft.com/de-de/dotnet/csharp/
https://www.it-schulungen.com/wir-ueber-uns/wissensblog/was-ist-net-maui-9-das-plattformuebergreifende-ui-framework-im-detail.html
https://medium.com/quick-code/understanding-the-net-ecosystem-f60f571e1152

Beitragsbild: https://www.unimedia.tech/wp-content/uploads/2023/11/Maui-1.webp

The post Workshop | .NET (MAUI/ASP.NET Core Blazor) appeared first on Mobile USTP MKL.

Technischer Aufbau

Im Hintergrund greift WebXR auf JavaScript-APIs zurück. Technisch gesehen setzt sich WebXR also aus diesen Bausteinen zusammen, die eng ineinandergreifen:

• Rendering
  Die Darstellung der 3D-Grafik erfolgt über WebGL oder aufbauende Frameworks wie Three.js, Babylon.js oder A-Frame. Das Rendering läuft in einer speziellen Schleife, die ähnlich wie requestAnimationFrame funktioniert, jedoch direkt an die Anforderungen der XR-Hardware angepasst ist. Eine Szene wird dabei in 3D präsentiert, indem die Perspektive für jedes Auge berechnet wird. Beide Bilder – links für das linke Auge, rechts für das rechte Auge – werden in einem Framebuffer kombiniert und anschließend an das XR-Gerät übergeben, sodass der Nutzer eine realistische stereoskopische Ansicht erhält.
• Gerätedaten
  Die API stellt Informationen über die aktuelle Position und Orientierung von Headsets bereit, erfasst Kameradaten für AR-Anwendungen und liefert Sensordaten wie Bewegungen, Beschleunigung, Rotation oder Barometerwerte. Typische XR-Geräte unterstützen 3 oder 6 Freiheitsgrade (DoF) und können interne oder externe Positionssensoren besitzen. Diese Daten werden abstrahiert, sodass die Anwendung nicht wissen muss, ob sie von einem High-End-VR-Headset, einem Smartphone oder einer AR-Brille stammen.
• Eingabemethoden
  Neben klassischen VR-Controllern können auch moderne Eingabeverfahren wie Handtracking, Blicksteuerung oder Gestenerkennung integriert werden. Bewegungen der Eingabegeräte werden in Vektoren umgewandelt, die die Anwendung für Navigation und Interaktion innerhalb der XR-Szene nutzt.
• Rendering-Schleifen
  Jede XR-Session läuft in einem eigenen Zyklus, bei dem pro Bild sowohl die Grafiken berechnet als auch die neuesten Tracking-Daten der Hardware abgefragt werden. Dadurch wird ein konsistentes XR-Erlebnis gewährleistet, bei dem Interaktion und Darstellung stets synchronisiert sind.
• Sicherheits- und Zugriffskontrolle
  Da XR-Anwendungen Zugriff auf sensible Daten wie Kamerastreams oder präzise Bewegungsprofile erhalten, übernimmt der Browser die Sicherheitsabfragen. Er fordert die Zustimmung des Nutzers ein und gibt nur die notwendigen Daten weiter, die für die jeweilige Session benötigt werden.
• Multi-View-Unterstützung und Spiegelung
  WebXR kann mehrere Ansichten gleichzeitig rendern. Typisches Beispiel ist das Stereo-Rendering für VR, bei dem getrennte Bilder für das linke und rechte Auge erzeugt werden. In AR-Szenarien können zusätzlich 3D-Inhalte mit Kamerabildern kombiniert werden. Optional kann die Szene auch auf einem 2D-Display gespiegelt werden, um das Erlebnis für Zuschauer sichtbar zu machen oder für Debugging-Zwecke.

Um ein Erlebnis zu starten, legt eine Website eine Session an (etwa „immersive-vr“ für Virtual-Reality-Inhalte oder „immersive-ar“ für Augmented-Reality-Erfahrungen). Der Browser kümmert sich dabei um die Kommunikation mit dem Betriebssystem und der Hardware. Er fragt nach den nötigen Berechtigungen und stellt der Anwendung die Daten in einem standardisierten Format zur Verfügung. Diese werden dann in Folge für das Redern gebraucht. Der Vermittlungsprozess kann von WebXR geräteunabhängig durchgeführt werden. Sensoren wie Beschleunigungsmesser, Gyroskope oder Barometer werden automatisch berücksichtigt, sodass Bewegungen des Nutzers präzise in die XR-Szene übertragen werden.

WebXR Einsatzgebiete

Zu den wesentlichen Bereichen, in denen WebXR Anwendungen mittlerweile stark vertreten sind, kurz ein Überblick:

• Industrie und Wartung: Techniker sehen AR-Überlagerungen mit Infos zu Maschinen, oder bekommen Schritt-für-Schritt-Anleitungen eingeblendet.
• E-Commerce: Online-Shops können Produkte in 3D oder AR darstellen. Nutzer können Möbel virtuell ins Wohnzimmer stellen oder Kleidung anprobieren.
• Kultur und Kunst: Museen schaffen virtuelle Rundgänge, oder bieten AR-geführte Touren, die einfach im Browser starten.
• Bildung und Training: Virtuelle Labore oder Simulationen sind direkt im Browser nutzbar, ohne teure Software-Installationen. Pilotprojekte zeigen, dass das den Zugang zu Lerninhalten erleichtert.

Hier nun ein paar Real-Beispiele zum Draufklicken:

WebXR in der Praxis (Code-Snippet)

Das folgende Code-Snippet zeigt, wie man mit WebXR und Three.js eine einfache AR-Anwendung erstellt kann, die es Nutzern ermöglicht, ein 3D-Modell direkt in ihrer realen Umgebung zu platzieren:

const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.xr.enabled = true;
document.body.appendChild(renderer.domElement);

const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(70, window.innerWidth / window.innerHeight, 0.2, 20);
scene.add(camera);

const light = new THREE.AmbientLight(0xffffff, 1);
scene.add(light);

const cube = new THREE.Mesh(
  new THREE.BoxBufferGeometry(0.2, 0.2, 0.2),
  new THREE.MeshBasicMaterial({ color: 0x00ff00 })
);
scene.add(cube);

const controller = renderer.xr.getController(0);
scene.add(controller);

const hitTestSource = new XRHitTestSource();
controller.addEventListener('select', () => {
  const hitPose = hitTestSource.getPose();
  if (hitPose) {
    cube.position.set(hitPose.position.x, hitPose.position.y, hitPose.position.z);
  }
});

function animate() {
  renderer.setAnimationLoop(animate);
  renderer.render(scene, camera);
}

animate();

Dieses Code-Snippet erstellt eine 3D-Szene mit Kamera, Licht und einem grünen Würfel als Objekt. Der WebGL-Renderer wird aktiviert und unterstützt WebXR, sodass AR-Funktionen direkt im Browser genutzt werden können. Ein XR-Controller erfasst die Eingaben des Nutzers, während ein Hit-Test die reale Position für das Objekt bestimmt. Tippt der Nutzer, wird der Würfel an dieser Position platziert. Die Szene wird kontinuierlich gerendert, sodass das Objekt in Echtzeit in der Umgebung angezeigt wird.

Chancen und Herausforderungen von WebXR

Ein zentraler Vorteil von WebXR liegt in der niederschwelligen Zugänglichkeit: Nutzer müssen keine zusätzliche App installieren, sondern können direkt über einen Link immersive Inhalte aufrufen. Das senkt die Eintrittsbarrieren erheblich und steigert die Reichweite. Darüber hinaus ermöglicht WebXR plattformübergreifende Entwicklung, sodass eine einzige Codebasis sowohl auf Desktop, Mobilgeräten als auch XR-Headsets funktioniert. Entwickler profitieren zudem von der engen Verzahnung mit etablierten Webtechnologien wie WebGL oder WebAudio, was die Integration bestehender Infrastruktur erleichtert und Entwicklungsaufwände reduziert. Fortschritte wie WebAssembly und WebGPU lassen erwarten, dass die Lücke in puncto Leistung zu nativen Anwendungen kleiner wird.

Auf der anderen Seite zeigen sich nach wie vor deutliche Einschränkungen. Die Unterstützung in Browsern und auf Geräten ist fragmentiert: Während einige Plattformen bereits solide WebXR-Funktionalitäten bieten, hinkt etwa Safari auf iOS noch hinterher. Auch die Performance bleibt bei komplexen 3D-Szenen hinter nativen Anwendungen zurück, was sich etwa in niedrigeren Framerates oder reduzierter visueller Qualität äußern kann. Ein weiterer kritischer Punkt betrifft die Sicherheit: Da WebXR im Browser läuft, sind klassische Webbedrohungen wie Phishing, bösartige Skripte oder Datenlecks nicht auszuschließen. Gerade weil WebXR-Schnittstellen Zugriff auf sensible Sensoren und Bewegungsdaten erlauben, sind strenge Berechtigungs- und Sicherheitskonzepte unverzichtbar. Schließlich erfordert die breite Kompatibilität oft Kompromisse bei Funktionsumfang und Detailtiefe, um auf möglichst vielen Endgeräten zuverlässig zu laufen.

Ausblick in die Zukunft

WebXR entwickelt sich rasant von einer experimentellen Technologie hin zu einem festen Bestandteil digitaler Erlebnisse. Diese Entwicklung zeigt sich besonders in vier zentralen Bereichen:

• Integration neuer Technologien: Künstliche Intelligenz und Mixed Reality machen WebXR-Erfahrungen individueller und immersiver, indem sie Inhalte dynamisch anpassen und reale mit virtuellen Elementen
• Mehr Leistung & Zugänglichkeit: Moderne Browser, leistungsstarke Geräte und schnelle Netzwerke ermöglichen bereits heute beeindruckende XR-Erlebnisse direkt im Web – ohne zusätzliche Apps oder komplizierte Installationen.
• Standardisierung & Interoperabilität: Mit Schnittstellen wie dem WebXR Device API entstehen plattformübergreifende Anwendungen, die auf unterschiedlichsten Geräten konsistent funktionieren und so ein breites Publikum erreichen.
• Neue Einsatzfelder: Neben Gaming rücken vor allem Bildung, E-Commerce und virtuelle Zusammenarbeit in den Fokus. Lernende profitieren von interaktiven Kursen, Unternehmen nutzen immersive Showrooms, und Kund:innen können Produkte realitätsnah erleben.

Fazit

WebXR verbindet das Web mit der Welt der XR-Erlebnisse und das recht unkompliziert direkt im Browser. Es macht VR und AR leichter zugänglich und bringt Vorteile in der Nutzung für Bildung, Industrie, E-Commerce und Kultur. Gleichzeitig gibt es noch Hürden bei Leistung, Sicherheit und Standardisierung. Nichtsdestotrotz haben sich schon einige Unternehmen an die Entwicklung reiner WebXR Anwendungen herangewagt. Doch mit der Weiterentwicklung von Hardware, offenen Standards und einer aktiven Community wird WebXR in den kommenden Jahren ein wichtiger Zugangskanal für immersive Inhalte werden.

Um nun selbst einen Eindruck gewinnen zu können, kann man unter WebXR – Samples checken, ob der eigene Browser WebXR unterstützt und im Falle einer Unterstützung direkt sich mit den Aspekten der WebXR API auseinandersetzen.

Links:
Beitragsbild – https://immersive-web.github.io/webxr-samples/media/logo/webxr-logo.svg
Bilder der Real-Beispiele – Quelllink direkt in den Bildern eingebettet
https://immersiveweb.dev/
https://immersive-web.github.io/webxr-samples/
https://developer.mozilla.org/de/docs/Web/API/WebXR_Device_API
https://www.rooom.com/de/blog/webxr-the-future-of-immersive-web-experiences
https://www.onirix.com/webxr-examples-development-extended-reality/
https://edbyto.com/edbyto/webxr-fuer-berufliche-aus-und-weiterbildung
https://www.edtechaustria.at/virtuelle-welten/
https://edbyto.com/edbyto/albion-press-virtuelles-museumserlebnis-in-webxr
https://webhosting.de/webxr-virtuelle-realitaet-browser/ https://developer.mozilla.org/de/docs/Games/Techniques/3D_on_the_web/WebXR

The post Blogbeitrag | WebXR – das Web als Tor in eine neue Dimension appeared first on Mobile USTP MKL.

Mit ergo4All soll eine digitale Lösung entwickelt werden, die ergonomisches Wissen und konkrete Anpassungsvorschläge allen Menschen zugänglich macht – unabhängig von Alter, körperlichen Voraussetzungen oder digitaler Kompetenz. Innerhalb der App steht dabei das Ziel im Vordergrund, individuelle Empfehlungen für gesundes Arbeiten und Alltagsbewegungen leicht verständlich und barrierearm bereitzustellen.
Je nach, welches Szenario (Heben/Tragen, etc.) man in der App wählt, bewertet die KI (gestützt auf maschinelles Sehen und den anerkannten RULA‑Score) Körperhaltungen aus einem kurzen in Echtzeit dokumentierten Video. Anschließend liefert sie dem/der NutzerIn leicht verständliche Hinweise zur Verbesserung der Haltung. Alle Daten werden lokal auf dem Gerät verarbeitet, daher findet keine Cloud‑Speicherung oder Tracking statt.

Zielsetzung

Am Anfang meiner Projektmitarbeit umfassten meine Aufgaben das Redesign bestehender App-Screens sowie die Erstellung neuer Screens mit entsprechender Navigation auf Basis des damals erstmalig überabeiteten Figma-Mockups. Dieses ist hier zu sehen:

Zusätzlich war ich beauftragt die Lokalisierung von Texten, Buttons und co. für Deutsch und Englisch über ein eigenes Lokalisierungsfile vorzunehmen. Im weiteren Verlauf wurde ich gebeten, mir auf einem eigenen GIT-Branch anzuschauen, wie die App für IOS gebuildet werden kann, um lauffähig zu sein. Zum Abschluss lag die Verantwortung für den Aufbau des Onboardings gemäß eines vorab abgestimmten Konzepts bei mir.

Durchführung

In ersten Schritten wurde ich von Dipl.-Ing. Ramon Brullo BSc technisch in die App eingeführt. Dabei wurde die klare Code-Struktur der App erklärt. Es handelt sich hierbei um eine Flutter-App, dessen Hauptsprache die Programmiersprache Dart ist

In den ersten Schritten wurde ich von Dipl.-Ing. Ramon Brullo, BSc technisch in die App eingeführt, wobei insbesondere die klare Code-Struktur einer Flutter-App (Programmiersprache Dart) erläutert wurde. Die Lokalisation erfolgt über ein JSON-File, die Codeverwaltung über GIT mit Sub-Branches und einer regelmäßigen Release-Pipeline. Die Commits orientieren sich am Standard der Conventional Commits, die wiederum die Release-Pipeline anstößt.
Ich nahm bei den fast jeden Dienstag stattfindenden Meetings zwischen unserem Projektteam und TU-KollegInnen teil, in denen Status und Fortschritte abgestimmt wurden. Anfangs lag mein Schwerpunkt auf der App-Lokalisation und dem Verständnis des Codes, bevor ich am Frontend größere Änderungen vornahm und regelmäßig Commits einbrachte. Für design-relevante Themen war Vivian Seidl BSc zuständig, mit der ich mich eng abstimmte.

Ein größeres Vor-Ort-Meeting Mitte Juni diente dazu, die Planung bis in den Herbst hinein gemeinsam mit den TU-KollegInnen festzulegen. Zudem habe ich mir in Flutter angeschaut, wie man einen iOS-Build macht und am Onboarding beteiligt. Das Frontend des Onboarding übernahm ich ganz, während Ramon die Backend-Einbindung in den Appflow übernahm.

Ergebnisse

Nachdem das Redesign abgeschlossen und alle fehlenden Screens ergänzt wurden, gliedert sich das App-Layout nun folgendermaßen (der Onboarding-Prozess, welche erst vor kurzem in der Form dazu kam, wird unterhalb erläutert):

Die App startet beim erstmaligen Öffnen mit einem Welcome-Screen samt Sprachwahl, bevor der/die NutzerIn nach einem Onboarding ins Hauptmenü gelangt. Von dort aus lassen sich direkt allgemeine Tipps zur Ergonomie-Themen oder konkrete Szenarien auswählen. Über den Tipps-Selection-Screen geht es in detaillierte Anleitungen zur Körperhaltung. Wählt man ein Szenario, bekommt man eine kurze Szenariobeschreibung und folgt der Aufnahmefunktion, mit der die eigene Haltung erfasst wird. Anschließend werden im Ergebnis-Screen eine Übersicht und Detailbewertungen angezeigt, inklusive spezifischer Analysen einzelner Körperbereiche. Durch das Redesign sind sind alle Texte lokalisiert und das Screen-Layout Großteils einheitlich.

Nachdem der/die UserIn die Sprache vorselektiert hat, startet in der gewählten Sprache beim erstmaligen Betreten in die App ein durchstrukturiertes Onboarding. Zuerst wird auf die Privatsphäre hingewiesen und erklärt was mit den gesammelten App-Daten passiert. vordem die App kurz und prägnant vorgestellt wird.

Nachdem die Sprache ausgewählt wurde, startet beim ersten App-Betreten ein klar strukturierter Onboarding-Prozess in der gewählten Sprache.

1. Privatsphäre – Zunächst wird erklärt, dass die App komplett offline funktioniert, keine Cloud und kein Tracking verwendet und alle Daten lokal am Gerät bleiben.
2. App-Übersicht – Danach folgt eine kurze Einführung, die den Zweck der App verständlich darstellt.
3. AGBs – Anschließend werden die Nutzungsbedingungen präsentiert, mit einem klaren Hinweis darauf, dass die Ergebnisse nur Informationscharakter haben und keine fachliche Beratung ersetzen.
4. Was ist Ergonomie? – Dieser Screen erläutert die Grundidee der Ergonomie und vermittelt, dass nicht das momentane Empfinden, sondern langfristige Gesundheit im Mittelpunkt steht.
5. Dein Nickname – Zum Schluss können NutzerInnen optional einen Spitznamen vergeben, um Ergebnisse leichter wiederzufinden.

Alle Texte der Onboarding-Screens wurden sorgfältig von einem Kollegen der TU Wien entwickelt, um Inhalte sprachlich präzise, leicht verständlich und zugleich den wissenschaftlichen Standard entsprechend.

Fazit und Ausblick

Bezugnehmend auf meine Vorkenntnisse im hybriden App-Development mit Flutter stellte sich dieses Projekt als sehr gewinnbringend für mich dar. Ich konnte mein Flutter-Wissen nicht nur auffrischen, sondern auch um neue technische Aspekte erweitern. Darüber hinaus erhielt ich durch meinen Teamkollegen Dipl.-Ing. Ramon Brullo, BSc wertvolle Einblicke in unterschiedliche App-Testansätze, deren Einsatzwahl und deren konkrete Umsetzung in Flutter.

Besonders hervorzuheben ist, dass mir Ramon auch das Konzept der Conventional Commits zeigte, das für mich völlig neu war. Ich konnte den Ansatz schnell nachvollziehen und habe diesen im Projekt selbstständig angewendet. Dadurch habe ich nicht nur die Struktur meiner Commits verbessert, sondern auch den Mehrwert von standardisierten Commit-Messages für Teamarbeit und Release-Prozesse erkannt. Ebenso waren die regelmäßigen Meetings und die enge Abstimmung im Team ein Mehrwert für mich. Sei es eine persönliche Weiterentwicklung im Hinblick auf Teamarbeit oder Projektorganisation.

Im Großen und Ganzen nehme ich aus dem Projekt 80 lehrreiche Stunden mit, in denen ich mein technisches Know-how im Bereich Flutter-Entwicklung erweitern, meine Arbeitsweise im Team verbessern und wertvolle praktische Erfahrungen in der koordinierten App-Entwicklung sammeln konnte.

Da es sich noch um ein derzeit laufendes Forschungsprojekt handelt, entspricht die aktuelle App-Version noch nicht der geplanten Veröffentlichung. Im Herbst werden noch einige zusätzliche Usability-Testings in Unternehmen durchgeführt, deren Ergebnisse in die finale Weiterentwicklung einfließen. Eine Veröffentlichung der App in die App-Stores ist noch im heurigen Herbst geplant.

Mehr zu dem Forschungsprojekt lesen? – https://research.fhstp.ac.at/projekte/ergo4all-ergonomie-fuer-alle

The post TFG | ergo4All Forschungsprojekt appeared first on Mobile USTP MKL.

Aufgabenstellung

Die Aufgabenstellung und das MVP wurde uns größtenteils vorgegeben, wobei wir vor allem bei den optionalen zusätzlichen Features mitreden konnten. Prinzipiell war die Idee, eine App zu entwickeln, über die man gewisse Echtzeitdaten wie Standort, Geschwindigkeit, Herzfrequenz etc. mit einer Gruppe austauscht. Einsatzbereiche gibt es dabei mehrere. Beispielsweise könnte man sich auf den Sport- (Laufen, Radfahren etc.) oder auf den Gesundheitsbereich (inkl. Fallerkennung) fokussieren. Letztendlich haben wir uns für den Bereich “gegeneinander Laufen” entschieden.

MVP (Minimum Viable Product)

Um am Ende sagen zu können, dass wir die Aufgabe gemeistert haben, wurde ein MVP (Minimum Viable Product) mit den grundlegendsten Funktionen definiert. Was den Client betrifft, waren das Auslesen und sinnvolle Übertragen von Sensor-Daten, Login und Teambildung aber auch eine “coole Darstellung” wichtig. Vor allem beim letzten Punkt sollten wir uns wirklich Gedanken machen, was im Kontext gut funktioniert, anstatt einfach nur alle Daten in Zahlenform anzuzeigen.
Serverseitig lag der Fokus auf der Verteilung der Daten in Echtzeit im Team.
Außerdem sollte die App auf mindestens einer Plattform nativ im Testmodus verfügbar sein.

NTH (Nice to Have)

Neben dem MVP wurden auch optionale Features notiert, genannt “Nice to Haves”, die dann umgesetzt werden sollten, sobald das MVP fertig ist. Diese Liste wurde auch während der Woche erweitert.
Dazu gehörte die Distribution auf beiden Plattformen (iOS und Android) oder das Einführen eines Handicaps, welches dazu genutzt werden kann, dass unterschiedlich starke Leute in einer Sportart gegeneinander antreten können. Eine History vergangener Sessions, eine Exportmöglichkeit der Daten, Gamification, das Laufen der App im Hintergrund, Micro-Interactions und Vibration waren ebenso Punkte auf dieser Liste. Andere Ideen waren die Berechnung eines Leistungswerts, Tests oder die Verwendung eines QR-Codes zur Gruppenbildung.

Verwendete Technologien

Im Projekt setzten wir auf Technologien, die wir bereits im vorherigen Semester kennenlernen durften bzw. mit denen einige unserer Gruppenmitglieder*innen bereits Erfahrung hatten. Von Anfang an war klar, dass sich eine native Umsetzung unserer App für sowohl Android als auch iOS wohl zeitlich nicht ausgehen würde, weshalb wir im Frontend auf eine Cross-Plattform Technologie setzten.

Frontend

Im Frontend arbeiteten wir mit dem Cross-Platform Framework Ionic (Capacitor), in Kombination mit der Frontend-Technologie React – geschrieben in Typescript. Die Wahl fiel darauf, da wir im 1. Semester unseres Studiums sowohl ein Projekt mit React umsetzen mussten, als auch in unserer Masterklasse mit dem Ionic Framework arbeiteten.

Die ersten Screen-Prototypes designten wir mit der Design-Software Figma.

Backend

Im Backend verwendeten wir NestJS, ebenfalls in Kombination mit Typescript, da wir diese Backend-Technologie ebenfalls im 1. Semester unserer Masterklasse in einem Projekt verwendeten und so die Einstiegshürde wegfiel.

Da unsere App sehr stark auf Live-Daten angewiesen ist (sowohl das Senden der aktuellen Sensordaten eines Users, als auch das Erhalten der Live-Daten anderer User während einer Aktivität), entschieden wir uns, hierfür auf Websockets zurückzugreifen, welche nahtlos in NestJS unterstützt wurden. Beim Erstellen einer Session für alle Teilnehmer*innen wurde ein Websocket “Topic” erstellt, welches in den Apps aller Nutzer*innen subscribed werden konnte und mit welchem immer die aktuellen Live-Daten in einem fest definierten Intervall ausgetauscht wurden.

Datenbank

Für die Persistenz unserer Daten setzten wir auf eine PostgreSQL Datenbank, ergänzt durch den Object-Relational Mapper (ORM) TypeORM. Wir wählten PostgreSQL aufgrund seiner Zuverlässigkeit und weiten Verbreitung als relationale Datenbank, was uns eine solide Basis für unsere Anwendung bot und zukünftige Skalierbarkeit ermöglichte. Ein weiterer ausschlaggebender Faktor war die exzellente Kompatibilität mit NestJS und die vorhandene Teamerfahrung mit TypeORM.

Die Struktur unserer Datenbank wird ist in diesem ER-Diagramm veranschaulicht. Die Kernentitäten bilden User, Session und Messerwerte. Zwischen :

• User: Hier hinterlegen wir alle notwendigen Benutzerinformationen, darunter Id, Vorname, Nachname, Email, Passwort und physiologische Daten wie Geburtsdatum, Groesse, Gewicht und Geschlecht. Diese Informationen sind essenziell, insbesondere das Geburtsdatum für die Berechnung der individuellen Herzfrequenzzonen.
• Session: Diese Entität verwaltet die Details der Lauf-Sessions, wie Id, Status, Enddatum, Typ und Startdatum.
• User_Session: Als Verbindungstabelle stellt sie die Beziehung zwischen Benutzern und Sessions dar und speichert die Rolle des Teilnehmers innerhalb einer Session.
• Messwerte: Diese zentrale Entität ist für die Speicherung der während einer aktiven Session gesammelten Sensordaten zuständig. Dazu gehören Zeitstempel, Geschwindigkeit, Breitengrad, Längengrad, Lage, Richtung, Herzfrequenz und Schrittfrequenz. Diese Daten bilden die Grundlage für unsere Echtzeitanzeigen und potenzielle historische Analysen.

Mit unserer PostgreSQL DB wird somit das Rückgrat unserer App, indem alle statischen Benutzer- und Sitzungsdaten sowie die dynamischen Sensordaten gespeichert sind, die für die Kernfunktionen und die Visualisierung notwendig sind, gebildet.

Um diese DB stabil und einfach zu handhaben, nutzten wir Docker. Das erlaubte uns, die PostgreSQL-Datenbank in einem eigenen, isolierten “Container” laufen zu lassen. Dies vereinfacht nicht nur die Einrichtung erheblich, sondern stellt auch sicher, dass die Datenbank immer in einer konsistenten Umgebung läuft und ihre Daten sicher verwahrt bleiben. Dank dieser Docker-Einrichtung konnte sich unser Backend-Service problemlos und zuverlässig mit der Datenbank verbinden, sobald diese bereit war. Die Konfiguration mit TypeORM wiederum sorgte dafür, dass unsere App die Daten korrekt lesen, schreiben und verwalten konnte. Besonders wichtig dabei waren unsere TypeORM Datenbank-Migrationen. Diese funktionieren wie kleine, versionierte Skripte, die es uns ermöglichten, die Struktur der Datenbank (wie z.B. neue Spalten hinzufügen oder bestehende ändern) im Laufe der Entwicklung schrittweise und kontrolliert anzupassen, ohne Daten zu verlieren.

OpenAPI

Damit wir in unserem Frontend nicht noch einmal alle Backend Objekte doppelt anführen müssen und um Zeit zu sparen, haben wir uns dazu entscheiden, den OpenAPI Generator zu verwenden. Die grundsätzliche Funktion von diesem ist, dass man im Backend mithilfe eines Decorators, wie Swagger, die Endpunkte definiert und dokumentiert. Mithilfe dieser Dokumentation, kann man dann für das Frontend Client-Funktionen erstellen lassen, welche mit dem Backend konsistent und typensicher sind. In unserem Backend haben wir Swagger verwendet, um per Decorator die Endpoint Spezifikationen anzugeben. Im Frontend haben wir dann die @openapitools/openapi-generator-cli installiert, welche einen Befehl bereitstellt, mit welchem man die API erstellen kann. Davor ist noch eine OpenAPI Spec Datei benötigt, welche openapitool.json heißt, in welcher man die Einstellungen für die API angibt. Danach kann man jederzeit die API generieren lassen und sie verwenden.

CI/CD

Für unsere Backend-Applikation wurde uns ein Server auf unserer FH-Cloud zur Verfügung gestellt. Haben wir nun unsere NestJS Applikation per FTP auf diesen Server geladen? Natürlich nicht! Haben wir stattdessen viel Zeit in Continuous Integration und Deployment (CI/CD) investiert? Selbstverständlich! Schon am ersten Tag der Woche haben wir ein docker-compose.yml geschrieben. Damit ließ sich die Backend-Applikation mit einer Postgres Datenbank starten. Mit der Unterstützung unseres Masterklassenleiters Armin haben wir am Morgen des zweiten Tages Docker auf unserem Server installiert. Dann haben wir einen GitLab Runner mit dem Shell Executor eingerichtet und das .gitlab-ci.yml geschrieben. Darin haben wir einen Deploy Job definiert, der bei einem Commit auf den “main” Branch docker-compose ausführt und damit die neueste Version der Anwendung auf unserem Server startet. Ebenfalls haben wir den Build unserer Android-App automatisiert. Dafür brauchte es einen Job um die Dependencies der Ionic App zu installieren, einen Job um die Frontend-Applikation zu bauen, einen um das .apk zu bauen und schließlich einen Job um das .apk zu publishen. Damit wir reproduzierbare Builds und einen sauberen Server haben, wollten wir all diese Jobs in Containern ausführen. Dazu mussten wir einen weiteren GitLab Runner aufsetzen, der dieses Mal den Docker Executor verwendet. Der Build der Android App verwendet das Image alvrme/alpine-android und die anderen ein simples Node.js Image. Continuous Deployment war geschafft, Continuous Integration folgte.

Wenn man ein neues NestJS-Projekt startet, werden automatisch Eslint mit Prettier und Jest eingerichtet. Damit das Code-Linting/Formatting und die Tests auch in der Pipeline ausgeführt werden, haben wir dafür jeweils einen Job in einem “test” Step in unsere Pipeline erstellt. Vorgelagert findet ein Job statt, der die Dependencies installiert. Alle drei Jobs werden in einem Node.js Image ausgeführt. Hätten wir noch mehr Zeit gehabt, hätten wir noch für das Frontend einen Linting- und Test-Job erstellt.

Im Hinblick auf CI war zwar die Basis für Unit Tests im Backend gelegt, aber leider fehlten uns die Tests, um wirklich Nutzen davon zu haben. Der GitLab Test Reporter zeigt die traurige Situation unserer Unit Tests (siehe folgenden Screenshot). Um das zu kompensieren, haben wir End-To-End-Tests geschrieben, die zumindest einen Teil der User Flows abdecken. Mit Cypress durchlaufen wir den Registrierungs- und Anmeldeprozess und starten einen neuen Gruppenaktivität. Die Cypress Tests werden leider nicht in der Pipeline ausgeführt, da unsere GitLab Runner mit den existierenden Jobs bereits alle Hände voll zu tun hatten. Gegen Ende der Woche, als der Zeitdruck stieg, mussten wir sogar manche Pipeline Steps deaktivieren, um das Deployment zu beschleunigen.

Internes App-Publishing

Eine der Anforderungen unserer Auftraggeber war es, die fertige App auch auf zumindest einer der beiden Plattformen auf eine beliebige Weise öffentlich zur Verfügung zu stellen. Wir entschieden uns dafür Firebase App Distribution zu verwenden, um unsere Android App einer fest definierten Personengruppe ausliefern zu können. Es wurde ein Build Job in unserer GitLab Pipeline eingerichtet, der uns ein APK-File gebaut hat und dieses über die Firebase CLI in einen geschlossenen Test hochgeladen hat, in denen sowohl alle Teammitglieder*innen als auch unsere Dozenten eingeladen wurden. So wurde nach jedem Commit auf unseren master-branch eine neue App-Version veröffentlicht, die mit einem Klick in der Firebase App Distribution App heruntergeladen werden konnte.

Sensoren

In Bezug auf Sensoren wurden wir mit verschiedenen Heart Rate Monitors (HRMs) wie Wahoo Tickr Fit und einem Modell von Moofit ausgestattet. Um diese Daten auslesen zu können, haben wir das Capacitor Community Plugin “Bluetooth Low Energy” verwendet.

Arbeitsablauf

Generell haben wir beschlossen, dass wir jeden Tag um 9 Uhr mit der Arbeit beginnen werden. Wir haben auch die gesamte Woche vor Ort gearbeitet, da wir es als die bessere Option empfunden haben und gehört haben, wie schlecht es der Gruppe ging, welche nur im Home Office gearbeitet hat. Um uns besser organisieren zu können, haben wir jeden Tag um 10:00 ein Daily Standup abgehalten, wo wir unseren derzeitigen Stand den Dozenten gezeigt und erklärt haben und wir Feedback auf diesen erhalten haben. Bei diesen Standups haben wir auch unsere Ziele für den Tag festgelegt, damit wir wissen, auf was wir uns fokussieren werden.

Ziel des ersten Tages war es, ein Monorepo auf GitLab anzulegen und das Projekt zu initialisieren. Im Frontend beschäftigten wir uns mit den ersten Sensoren, und im Backend wurde die Datenbank aufgesetzt und mit den Websockets begonnen. Weiters richteten wir Firebase App Distribution für die Android Plattform ein.

Am Dienstag besprochen wir, wie unsere Entities/Daten aussehen würden. Das Feature “User Registrierung und Login” wurde implementiert, und wir machten uns Gedanken über das UI-Konzept und die Datenvisualisierung. Zusätzlich überlegten wir uns die Verwendung und Berechnung der Rohdaten der Sensoren, und implementierten automatisierte Android Builds.

Am Mittwoch, nachdem wir Feedback zu unserem UI-Konzept erhielten, verfeinerten wir dieses und überlegten uns ein bestimmtes Szenario für die Datenvisualisierung. Danach machten wir uns daran, die UI umzusetzen, ClientSDK zu generieren und Endpoints und Services im Backend zu erstellen. Weitere Ziele waren, Sensordaten über Websockets schicken und empfangen zu können, und eine Session sowohl im Frontend als auch im Backend erstellen zu können.

In den letzten beiden Tagen ging es darum, alle Features des MVP fertigzustellen und letzte Bugs zu fixen. Dazu gehörten: Auth (Route Guard, Token, …), alles rund um Sessions (Create, Join, End, Leave), die Kommunikation der Daten über Websockets, Edit Profile, Datenvalidierung (null, -1, …), Loading Indicator, und mehr.

Am Freitagnachmittag wurde das Endprodukt präsentiert – mehr dazu etwas später in diesem Blogbeitrag.

Neben der Arbeit kam aber auch nicht der Spaß zu kurz. Darum nutzten wir als Team am 4. Tag der Wild Week (Donnerstag) die Möglichkeit, beim FH internen “IMFix” Event vorbeizuschauen. Neben Snacks, Bier und guter Laune konnten wir uns bei mehreren Multiplayer Spielen entspannen, bevor es dann in die heiße Endphase des Projektes ging.

Abgeliefertes Endprodukt

Unsere App ist in mehrere übersichtliche Screens unterteilt, die den User Schritt für Schritt durch den gesamten Ablauf führen. Von der Anmeldung über die Erstellung oder Teilnahme an einer Session bis hin zur aktiven Nutzung während eines Laufs sind alle Funktionen klar strukturiert. Im Mittelpunkt stehen dabei das Dashboard als zentrale Steuerzentrale, der WaitingScreen zur Organisation der Teilnehmer*innen, sowie das Userprofil, in dem persönliche Daten verwaltet werden können. Während einer aktiven Session rücken das Leaderboard und die Kartenansicht in den Vordergrund. Hier werden in Echtzeit alle relevanten Informationen der Teilnehmer*innen angezeigt. 
Bevor jedoch der eigentliche Ablauf startet, erfolgt der Einstieg über den Login oder die Registrierung.

Login und Registrierung

Beim ersten Öffnen der App wird der User auf den Login-Screen weitergeleitet. Hier kann man sich entweder mit bestehenden Zugangsdaten anmelden oder sich neu registrieren. Die Registrierung erfolgt über ein kurzes Formular, bei dem grundlegende Daten wie Benutzername, E-Mail-Adresse und Passwort abgefragt werden.

Dashboard

Sobald der Login oder die Registrierung abgeschlossen ist, gelangt der User auf das Dashboard. Hier stehen zwei Optionen zur Verfügung: Entweder eine neue Session zu erstellen oder einer bestehenden Session beizutreten. Diese Optionen sind jedoch zu Beginn ausgegraut dargestellt und können erst genutzt werden, wenn bestimmte Voraussetzungen erfüllt sind.

Auf dem Dashboard befinden sich drei Buttons zur Aktivierung der benötigten Sensoren:

• GPS
• Herzfrequenzsensor (inkl. Bluetooth-Verbindung zu einem Wearable)
• Heading-Sensor

Zu Beginn sind alle drei Buttons rot eingefärbt, um anzuzeigen, dass die jeweiligen Sensoren noch nicht aktiv sind. Nach dem erfolgreichen Aktivieren – sei es durch das Einschalten eines Gerätesensors oder die Herstellung einer Verbindung – wechselt die Farbe auf grün, was visuell signalisiert, dass der jeweilige Sensor nun einsatzbereit ist.

Erst wenn entweder das GPS-Signal oder der Herzfrequenzsensor aktiviert wurde, werden die beiden Optionen „Session erstellen“ und „Session beitreten“ freigeschaltet und können ausgewählt werden. Optional kann zusätzlich der Heading-Sensor aktiviert werden, der später auf der Karte eine genauere Bewegungsrichtung ermöglicht.

Beim Beitritt zu einer Session muss zuvor die Session-ID, die man über einen QR-Code oder eine Nachricht erhalten hat, in ein Inputfeld eingegeben werden. Danach geht es automatisch weiter zum nächsten Screen.

WaitingScreen

Am WaitingScreen wird die aktuelle Teilnehmerliste angezeigt. Dort sieht der User, wer sich bereits angemeldet hat. Die Liste aktualisiert sich automatisch, sobald weitere Personen hinzukommen.

Über den Abmelde-Button kann sich der User jederzeit wieder von der Session entfernen. Man wird dabei direkt zurück ins Dashboard geleitet. Sollte jedoch der Host selbst auf „Abmelden“ klicken, wird nicht nur die eigene Verbindung getrennt, sondern die komplette Session gelöscht, inklusive aller Teilnehmerinnen. Auch in diesem Fall gelangen alle automatisch zurück ins Dashboard.

QR-Modal

Für den Ersteller der Session gibt es die Möglichkeit, einen QR-Code zu generieren. Dieser Button befindet sich oberhalb der Teilnehmerliste. Nach dem Klick öffnet sich ein Modal, in dem der QR-Code angezeigt wird. Dieser enthält die Session-ID und kann über einen Button ebenso in die Zwischenablage kopiert werden. Zusätzlich gibt es die Möglichkeit, die Session-ID direkt per Nachricht oder Social Media zu teilen. Wenn der Host entscheidet, dass alle bereit sind, kann die Session jederzeit über den Start-Button gestartet werden.

Sobald der Host einer Session auf “Start” klickt, kommen alle User*innen einer Session auf das Leaderboard. Dort befindet sich das Grundkonzept unserer App. Ganz oben am Screen findet man zwei Tabs, um zwischen 2 Ansichten zu wechseln: das Leaderboard und die Kartenansicht.

Leaderboard

Oben am Bildschirm findet der*die User*in die Ranganzeige. Der eigene Rang wird ziemlich groß dargestellt, damit man sofort erkennt, wo man sich am Leaderboard befindet. Gleich darunter findet sich das eigentlich wichtigste Feature unserer App, nämlich die visuelle Anzeige der Herzfrequenz und der Geschwindigkeit. Die Herzfrequenz wird bei uns in 3 Zonen eingeteilt. In der mittleren Zone befindet sich die “ideale Herzfrequenz” für den*die User*in für die aktuelle Aktivität. Sobald man sich in der linken oder in der rechten Zone befindet, bedeutet das, dass die Herzfrequenz zu niedrig bzw. zu hoch ist. Die “ideale Herzfrequenz” berechnet sich aus dem Alter des Users bzw. der Userin, damit die Fairness bei Teilnehmer*innen unterschiedlichen Alters erhalten bleibt. Die visuelle Darstellung wurde als Balken gelöst, da wir so die 3 Zonen in Farben unterteilen konnten und die aktive Herzfrequenz auf diesem Balken hin- und herwandern kann. Innerhalb der Balken befindet sich auch die Anzahl der Punkte, die man bekommt, je nachdem, in welcher Zone man sich befindet. Das Punktesystem für die Herzfrequenz wurde so gelöst, dass nur die mittlere Zone, also Zone 2, die meisten Punkte (+5 Punkte) bekommt. Die anderen zwei Zonen bekommen jeweils +2 Punkte. Somit bekommt der*die Nutzer*in alle 3 Sekunden, je nach Zone, die Punkte gutgeschrieben. 

Unterhalb des Herzfrequenz-Balkens befindet sich der Geschwindigkeits-Balken, dieser basiert auf dem gleichen Prinzip. Je nach Geschwindigkeit gehen die Punkte nach oben, je schneller desto mehr Punkte. Auch hier wurde der Balken in mehrere Zonen unterteilt, die farblich markiert sind.

Unterhalb der beiden Balken befindet sich auch schon das Leaderboard. Dort werden alle Teilnehmer*innen angezeigt, sowie deren Punktzahl. Alle Punkte werden permanent alle 3 Sekunden geupdatet, damit das Board ständig in Bewegung ist. Wenn sich Plätze ändern, passiert dies in einer überlappenden Animation. Außerdem werden Plätze 1-3 in den klassischen Farben Gold, Silber, Bronze dargestellt.

Kartenansicht

Auf dieser Seite befindet sich eine Karte von “Leaflet”, die in voller Bildschirmgröße dargestellt wird. Sie dient dazu, dass man jederzeit alle Teilnehmer*innen aktiv auf der Karte verfolgen kann, sollte sich beispielsweise ein*e User*in in einer anderen Stadt befinden. Alle Teilnehmer*innen werden jeweils als Dreieck, in einer individuellen Farbe, dargestellt. Wir haben uns für Dreiecke entschieden, weil wir so die Richtung anzeigen können, in die sich ein*e Nutzer*in bewegt. Aufgrund zeitlicher Begrenzung war das auch schon die Funktion unserer Karte.

User-Profil

Das Userprofile ist sehr simpel gehalten und bietet nur die Möglichkeit, Daten der Nutzer*innen zu ändern, wie zum Beispiel das Alter. Außerdem befindet sich dort der Logout Button.

Endpräsentation und Feedback

Ablauf der Präsentation / Abgabe

Am Nachmittag des fünften und letzten Tags der Extreme Programming Week war es soweit: das Produkt der Woche sollte präsentiert werden. Kurz vor dem ausgemachten Termin mit unseren Masterklasseleitern war es noch recht stressig, da noch einige kleine Bugs aufkamen, die gefixt werden mussten. Trotzdem schafften wir es recht pünktlich, mit der App-Demo anzufangen.

Zuerst installierten wir die App auf unseren Handys: auf Android via Firebase App Distribution und für iOS direkt von Xcode am Laptop auf das iPhone via USB-Kabel. Danach zeigten wir unseren Masterklasseleitern, wie man sich in der App registrieren und einloggen kann, und wie das Dashboard und die Account-Seite aussehen, sobald man eingeloggt ist. Die Herzfrequenz-Sensoren, welche wir zur Verfügung hatten, wurden unterschiedlichen Personen angelegt und mit Handys verbunden.

Schließlich war es Zeit für eine Demonstration der App in einem echten Szenario: eine Person unter uns erstellte eine Session und alle anderen traten dieser bei. Sobald alle drinnen waren, machten wir uns auf den Weg. Während einem Spaziergang rund um das Gebäude (der Rückweg wurde sogar gelaufen!) probierten wir die App aus und beobachteten dabei unsere eigenen Werte (Herzfrequenz, Position, Geschwindigkeit), sowie die Punkte auf dem Leaderboard.

Als wir zu dem Raum der Lehrveranstaltung zurückkehrten, gaben unsere Masterklasseleitern ihr Feedback zu unserem Endprodukt. Dadurch, dass wir die Anforderungen des MVP erfüllten, und auch noch einige Nice-To-Have-Funktionalitäten einbauten, war unser Projekt erfolgreich. Wir freuten uns über die positiven Rückmeldungen und über Ideen für mögliche Erweiterungen und Verbesserungen der App.

Erhaltenes Feedback: Verbesserungspotenzial

Im Laufe der interaktiven Live-Demo und im Anschluss zur Präsentation erhielten wir folgendes Feedback:

• Die WebSocket-Verbindung bricht öfters ab (z.B. beim Wechsel von WLAN zu Mobilen Daten, und auch nach einer Weile von Inaktivität). Eine Möglichkeit, sich (automatisch) wieder verbinden zu können, sollte implementiert werden.
• Die Berechnung der Daten (Punkte für das Leaderboard) wird momentan clientseitig durchgeführt. Die Berechnung sollte serverseitig passieren.
• Wenn sowohl die Herzfrequenz, als auch die GPS-Daten null sind, verschwindet der visuelle Balken dieser Person im Leaderboard.
• Der Code, der eingegeben werden muss, um einer Session beizutreten, sollte kürzer sein. Zusätzlich wäre ein eingebauter QR-Code-Reader cool. (Dies hatten wir eigentlich vor, es ist sich zeitlich aber leider nicht ganz ausgegangen)
• Es wäre gut, während der Session sehen zu können…
  • …wie akkurat die Daten sind (z.B. Position).
  • …ob eine Person einen Herzfrequenz-Sensor verbunden hat. (Zusätzlich wäre es von Vorteil, sich während der Session auch später noch mit einem Herzfrequenz-Sensor verbinden zu können.)
  • …ob eine Person momentan disconnected ist.
• Ein Nice-To-Have wäre noch, dass man in dem Leaderboard während der Session auf einzelne User*innen draufklicken kann, um Detaildaten zu der Person zu sehen. Eventuell könnten in der View die Daten der anderen Person auch gleich mit den eigenen verglichen werden.

Fazit aller Teilnehmer*innen

Im folgenden Abschnitt möchten wir noch unser Fazit und unsere Erfahrungen teilen, die wir während der Extreme Programming Week sammeln konnten.

Katharina

Ich bin sehr stolz auf das, was wir in diesen fünf Tagen geleistet haben. Die Extreme Programming Week hat nicht nur unsere Zeitmanagement-Skills, sondern auch zum ersten Mal unsere koordinierte Zusammenarbeit als Team auf die Probe gestellt. Ich war positiv überrascht, wie gut dies funktioniert hat – ich glaube, die täglichen Meetings haben sehr stark zu unserem Erfolg beigetragen.

Meine Aufgaben während der Woche waren unter anderem das Leiten der Meetings, das Testen und Debuggen der nativen Funktionalitäten (insbesondere auf dem iPhone) und Frontend Development. Dabei habe ich mich zum Beispiel intensiv mit Device-Daten (Geolocation, Accelerometer, Gyroskop, etc.) beschäftigt, um diese einerseits in der App anzuzeigen, und andererseits, um sie zur Berechnung von Herzfrequenzzonen, Kalorienverbrauch und sogar einem Schrittzähler zu verwenden. Letzteres hat es aus Zeitgründen leider nicht in das Endprodukt geschafft, aber die Erfahrungen, welche ich dabei gesammelt habe, bleiben mir erhalten.

Im Laufe der Woche hatte ich auch die Möglichkeit, gemeinsam mit Caro im Pair-Programming-Stil an der Authentifizierung im Frontend zu arbeiten. Diese Art des Arbeitens war recht neu für mich, aber ich muss sagen, dass ich eine sehr positive Erfahrung damit gemacht habe – wenn zwei kreative Köpfe zusammenkommen, kann so einiges entstehen!

Zusammenfassend kann man sagen, dass die Woche recht stressig war, besonders gegen Ende hin, aber ich habe sehr viel dabei gelernt. Vom technischen Know-how bis hin zu Leadership, Zeitmanagement und Team-Skills war alles dabei. Ich wünschte, ich hätte noch mehr Einblick in das Backend und den CI/CD-Prozess bekommen können, aber aus Zeitgründen war das nicht möglich. Alles in allem blicke ich positiv auf die Extreme Programming Week zurück: es war eine spannende Woche voller wertvoller Erfahrungen, welche uns als Team noch enger zusammengeschweißt hat, und aus der ich viel neues Wissen für die Zukunft mitnehme.

David

Ich blicke gerne auf die Wild Week zurück und bin stolz auf das Endprodukt, das wir als Team in der Woche geschaffen haben. Es war schön zu sehen, wie jedes Teammitglied seine bisherigen technischen Erfahrungen bei den verschiedenen Teilaufgaben des Projekts einbringen konnte. Durch das Setup (alle Teammitglieder ständig in einem Raum) konnten wir das Know-How auch sehr gut mit allen teilen.

Sehr motivierend fand ich auch die Aufteilung in tägliche Sprints mit einem Meeting in der Früh, in dem wir immer die Aufgaben definierten und zwischen den Teammitgliedern verteilten, da man so ein festes Ziel für den Tag vor Augen hatte, auf das man hinarbeiten konnte.

Ich konnte auf jeden Fall ein paar persönliche Learnings aus der Wild Week mitnehmen: Da das zu entwickelnde Produkt ja am Freitag zu präsentieren war und dadurch die Zeit ein extrem limitierender Faktor, war es essentiell, sich auf das MVP zu konzentrieren und sich nicht in Details zu verlieren. Das hat im Laufe der Woche mal mehr, mal weniger gut geklappt. Es ist auch gar nicht so leicht, stets den Fokus auf die Grundfunktionalität zu behalten, da man bei Projekten mit kompletter Entscheidungsfreiheit als Entwickler automatisch darüber nachdenkt, welche Features man nicht noch hinzufügen könnte. Gegen Ende der Woche hat sich das Pareto-Prinzip aus meiner Sicht auch wieder zum Teil bewahrheitet. Durch Erfolgsmomente am Anfang des Projekts ist man leicht dazu verleitet anzunehmen, dass die Entwicklungsgeschwindigkeit im selben Tempo bis zum Abschluss beibehalten werden kann – was sich nicht bewahrheitet hat. In einem zukünftigen Projekt dieser Art wäre es für mich wichtig, mehr Fokus darauf zu legen, wirklich beim MVP zu bleiben und den ganzen Entscheidungsprozess über zusätzliche Features erst gar nicht aufkommen zu lassen.

Aus technischer Sicht fand ich super, mich wieder mehr mit React beschäftigen zu können. Hier habe ich einiges an Know-How aus der Woche mitnehmen können. Zusätzlich fand ich die Diskussionen mit meinen TeamkollegInnen über Architekturentscheidungen sehr spannend und fand es super, das ganze Tech Setup inkl. CI/CD für ein Projekt dieser Art von Grund auf einzurichten. Es war auch das erste Mal, dass ich an einer App gearbeitet habe, die hauptsächlich Websockets als Kommunikationskanal verwendet – es war spannend, mal mit einem anderen Schnittstelle als REST zu arbeiten.

Andreas

8 Teammitglieder, fast 5 Tage Entwicklungszeit und eine gemeinsame App-Idee realisieren – das war unser intensives und lehrreiches Projekt am Anfang des 2. Semesters, aus dem ich persönlich viel mitnehmen konnte. Die Woche war geprägt von enger Teamkommunikation, klarer Aufgabenverteilung und vielen kleinen Abstimmungen, die am Ende zu einem funktionierenden Gesamtprodukt geführt haben. Besonders interessant war für mich, wie unterschiedlich einzelne Teammitglieder an Aufgaben herangegangen sind – sowohl inhaltlich als auch methodisch. Dabei habe ich nicht nur verschiedene Denkansätze kennengelernt, sondern auch praktische Coding-Tipps und Lösungsstrategien aufgeschnappt, die mir in Zukunft sicher weiterhelfen werden.

Mein Fokus lag zu Beginn auf der Planung unserer Datenbank. Zusammen mit Matthias habe ich verschiedene Datenbanktypen – wie z.B. relationale, NoSQL und Time-Series DBs – hinsichtlich ihrer Eignung für unseren Use Case bewertet. Auf Basis dieser Überlegungen sind wird bei einer klassischen relationalen DB geblieben, für die Matthias und ich ein erstes ER-Diagramm entworfen haben, das wir anschließend im Team besprochen und gemeinsam überarbeitet haben. Auch wenn dieser Prozess Zeit gekostet hat, konnten wir dadurch eine saubere, tragfähige Struktur aufsetzen, die sich später fast vollständig problemlos in NestJS integrieren ließ. Im weiteren Verlauf (nachdem der technische Aufbau der DB gestanden ist) habe ich mich verstärkt dem Frontend gewidmet, insbesondere der Nebenmaske für die User*innendaten, die noch nicht von meinen Kolleg*innen bearbeitet wurden. Dort konnte ich eigenständig erste Komponenten entwickeln, gerade bei Bereichen mit direktem Bezug zur Datenbank. Bei komplexeren Problemen habe ich auf Pair Programming gesetzt, um gemeinsam mit dem gebündelten Stärken meiner Kolleg*innen gezielte Lösungen zu finden.

Eine besondere Herausforderung war auch für mich der Umgang mit dem begrenzten Zeitrahmen bei gleichzeitigem Anspruch auf sauberen, wartbaren Code. Ich habe gelernt, wie entscheidend es ist, in der Entwicklung frühzeitig sinnvolle Prioritäten zu setzen – also die „richtige“ Reihenfolge zu finden: Was muss funktionieren, was ist optional, und was kann man notfalls zurückstellen? Diese Balance war nicht immer einfach, aber essenziell, um alle Kernfunktionen zuverlässig umzusetzen. Mein Versuch, am Ende noch die Safe-Area technisch sauber zu integrieren, ist trotz mehrerer Ansätze gescheitert – aber genau daraus habe ich am meisten gelernt: Nicht jede Idee lässt sich unter Zeitdruck noch sinnvoll umsetzen, und pragmatisches Handeln ist oft wichtiger als Perfektion im Detail.

Um mein Fazit abzurunden, möchte ich gerne festhalten, dass dieses Projekt nicht nur meine technischen Fähigkeiten weiterentwickelt, sondern auch mein Verständnis für effiziente Teamarbeit unter Druck geschärft hat. Besonders der Umgang mit begrenzter Zeit und die bewusste Fokussierung auf das Wesentliche haben mir gezeigt, worauf es in realen Entwicklungsprozessen wirklich ankommt.

Felix

Die Programming Week war für mich auf jeden Fall ein Highlight. In einer relativ großen Gruppe so ein Projekt in nur 5 Tagen umzusetzen war nicht nur super anstrengend, sondern auch spannend und lustig. Ich muss echt sagen, dass ich sehr viel gelernt habe, auch wenn ich leider von manchen Bereichen des Projekts nicht so viel mitbekommen habe, was aber durchaus verständlich ist, wenn man unter diesem Zeitdruck steht.

Ich habe viel im Pair-Programming gearbeitet und das vor allem am Frontend. Das war für mich echt nützlich, da ich so schneller in das Projekt und in React reinfinden konnte. Ich habe mit Caro zuallererst begonnen, dass wir den Heart-Rate-Sensor mit Bluetooth verbinden können und die Daten auslesen können, das hat Anfangs ein bisschen schwierig funktioniert, aber dann haben wir zusammen auch schnell eine Lösung gefunden, was gerade am ersten Tag super motivierend war. Auch sonst war das gesamte Projekt sehr gut aufgebaut, weil wir jeden Tag mit einem Meeting begonnen haben, um die heutigen Ziele festzulegen. Anfangs dachte ich, dass wird ja dann echt einfach am Freitag fertig zu werden, wenn alles so schnell weitergeht, aber wie so oft unterschätzt man dann den Stress der letzten Tage. Wie ich schon einmal erwähnt habe, hätte ich noch sehr gerne mehr in das Backend und in die Websockets geschaut, aber leider war das zeitlich nicht mehr ganz möglich, aber dafür konnte ich im Frontend fast überall mitarbeiten, was natürlich auch dort mein Wissen verbessert hat.

Das gesamte Projekt haben wir echt gut als Gruppe gemeistert. Wir hatten Spaß, waren gestresst und haben alle glaube ich sehr viel dabei gelernt. Das Endprodukt konnte sich bei der Präsentation auch sehen lassen, außer vielleicht ein paar kleine Bugs. Ich konnte auf jeden Fall sehr viel lernen und würde diese Art von Projekt gerne wiederholen, auch wenn eine Pause nach dieser Woche sehr gut getan hat. 

Caroline

Es war sehr spannend zu sehen, wie viel man zu acht in einer Woche bzw. 5 Tagen schafft zu entwickeln. Ich habe mich vor allem mit dem Frontend beschäftigt und dabei meist Pair Programming mit verschiedenen Personen betrieben. Dieses Konzept ist mir bereits aus dem Bachelor bekannt und mir persönlich gefällt es sehr gut, da man so schneller Fehler bemerkt.

Montags habe ich mich mit Felix um die Verbindung zum Heart Rate Sensor gekümmert. Anfangs gab es ein paar Schwierigkeiten, doch dann folgte das Erfolgserlebnis. Die Verwendung von HRMs und Bluetooth LE war für mich neu, aber sehr interessant. Dienstags habe ich mich vor allem mit dem Login- und Registrierungs-Screen beschäftigt und dafür anfangs Farben und Schriftarten global definiert und Tailwind aufgesetzt. In Bezug auf die Formulare auf den zwei Screens nutze ich React Hook Form, wobei ich die Library zu einem späteren Zeitpunkt ersetzt habe, da der State nicht immer aktualisiert wurde. Nachdem wir am Mittwoch unser UI-Konzept und die Datenvisualisierung überarbeitet hatten, habe ich mit Felix die Umsetzung des LiveActivity-Screens begonnen. Donnerstags war ich mit Katharina für den Authentifizierungscheck beim Aufruf gewisser Routen verantwortlich und habe Andi beim Bearbeiten der Profilinformationen geholfen. Am letzten Tag war Endspurt angesagt und somit auch Bug Fixing. Dabei habe ich einerseits David bei der Verwendung der WebSockets im Frontend unterstützt, andererseits Matthias bei der Session Erstellung/Teilnahme.

Ich finde, wir haben das als Gruppe sehr gut gemeistert, mit dem Daily Planning am Anfang war klar definiert, was gemacht wird, und das Endprodukt (bis auf die paar Bugs) kann sich sehen lassen. Vor allem was die Verbindung mit den Sensoren und die Erstellung eigener sogenannter Guarded Routes betrifft, habe ich einiges gelernt, was auch in Zukunft hilfreich sein könnte. Neben den technischen Aspekten habe ich nochmals gesehen, wie wichtig es ist, sich zuerst auf das MVP zu konzentrieren und sicherzustellen, dass das die anderen auch tun, da man sonst Zeit verliert und sich verrennen kann.

Sebastian

Die Wild Week war ein wirklich interessantes und spannendes Erlebnis. Ein ganzes Projekt in nicht einmal 5 Tagen auf die Beine zu stellen war extremst stressig, aber auch wirklich toll zu sehen, was man eigentlich in so kurzer Zeit auf die Beine stellen kann, wenn man sich wirklich ins Zeug lägt. Auch konnte ich einiges aus dieser Woche mitnehmen.

Zum einen hatte ich bisher noch keine Erfahrung mit Ionic in Verbindung mit React. Ich habe nur Ionic und Angular oder React Native verwendet, aber nicht beide zusammen. Auch habe ich einiges über die Verwendung von Herz Sensoren erfahren, auch wenn meine Erfahrung hier etwas kurz gekommen ist, da ich größtenteils im Backend zuständig war. Ich hätte sehr gerne auch andere Bereiche mir angeschaut, aber aufgrund des Zeitstresses ist es verständlich, dass dies nicht wirklich möglich war. In der Woche habe ich manchmal allein gearbeitet, zum Beispiel für die Erforschung, wie das Accelerometer im Handy funktioniert oder im Backend die Datenspeicherung über die passenden Endpoints zu ermöglichen, habe aber auch einiges im Pair Programming gemacht. Auf beiden Seiten. Auch wenn ich diese Technik schon aus dem Bachelor kannte, ist es trotzdem immer interessant zu sehen, wie gut Pair Programming funktioniert. Eine weitere Person neben sich zu haben, die sich nur darauf konzentrieren kann, was geschrieben wird und sofort erkennen kann, wenn man eine Sache vergisst oder welche einem bei Problemen hilft, ist sehr wertvoll, vor allem wenn nicht jede Person im Team an einer eignen Sache arbeiten kann.

Im großen und ganzem finde ich das die Wild Week wirklich toll gelaufen ist. Wir haben uns viel vorgenommen, dies aber auch toll hinbekommen. Mit den Daily Stand-ups, welche wir immer in der Früh gemacht haben, konnten wir uns jeden Tag auf unsere Ziele festlegen und auf diese fokussieren. Man konnte auch wirklich gut erkenne, weshalb das Prinzip eines MVPs existiertet. Ich hätte nichts dagegen, einmal wieder so ein Projekt zu wiederholen.

Jan

Es war eine spannende Woche! In fünf Tagen haben wir viel diskutiert, Entscheidungen getroffen und fleißig in die Tasten gehauen. Das Ergebnis ist ein Proof of Concept, der unsere interessante App-Idee greifbar macht. Mit diesem Ergebnis sind wir insgesamt sehr zufrieden. Allerdings schwingt beim „insgesamt“ auch ein kleiner Vorbehalt mit: Hätten wir vielleicht noch mehr aus dieser Woche herausholen können?

Viel Zeit hat unser Team zur Konzeption der App aufgewendet. Diese Zeit scheint mir rückblickend gut investiert. Es war wichtig, eine Idee auszuarbeiten, die wir spannend und sinnvoll fanden. Erst mit dieser klaren Vorstellung konnten wir mit Elan loslegen. Unsere Schwächen sehe ich eher bei der Aufteilung und Priorisierung der Arbeit. Die Features der App haben wir in Backend und Frontend unterteilt und zu unabhängig voneinander umgesetzt. Das führte dazu, dass im Backend Funktionen implementiert wurden, die im Frontend letztlich keine Verwendung fanden. Wie im Kapitel zu CI/CD erwähnt, haben wir außerdem zu viel Energie in unsere Pipelines gesteckt. Ein weiteres Problem der Aufteilung war, dass das Zusammenführen der Arbeiten erst spät erfolgte, wodurch wir auch erst spät auf Probleme aufmerksam wurden. Sinnvoller wäre es wohl gewesen, wenn Sub-Teams End-to-End an einzelnen Features gearbeitet hätten, sodass die App schrittweise gewachsen wäre.

Insgesamt war es jedoch eine produktive Woche, in der wir als Team nicht nur viel geschafft, sondern auch viel Spaß gehabt haben. Es war wirklich schön, sich fünf Tage lang intensiv in ein völlig neues Thema zu vertiefen – eine willkommene Abwechslung! Die Erfahrungen aus dieser Woche und das gestärkte Teamgefühl werden uns im nächsten Projektsemester mit Sicherheit zugutekommen.

Matthias

Die Programming Week war eine besonders spannende Challenge, nicht nur weil innerhalb weniger Tage eine funktionierende App entstehen sollte, sondern vor allem, weil es zwar klare Anforderungen gab, die konkrete Umsetzung aber völlig offen war. Genau dieser Freiraum hat die Kreativität im Team gefördert und es ermöglicht, eigene technische und gestalterische Lösungen zu entwickeln.

Zu Beginn haben wir im Team die Aufgaben verteilt und mögliche Technologien abgestimmt. Dabei hat sich schnell gezeigt, dass mein Interesse vor allem im UX-Bereich liegt, weshalb ich mich intensiver mit dem Dashboard als zentralem Einstiegspunkt sowie weiteren Screens beschäftigt habe. In den darauffolgenden Tagen habe ich an der Umsetzung zentraler Screens wie dem WaitingScreen sowie der QR-Code-Generierung und Sharing-Funktion gearbeitet und diese in sinnvolle Komponenten aufgeteilt. Auch ein Versuch, einen QR-Code-Reader zu implementieren, gehörte dazu. Besonders positiv war für mich das Pair Programming, da es unter Zeitdruck spürbar entlastet hat und gleichzeitig neue Perspektiven eingebracht hat. Die Woche war intensiv, aber genau dadurch auch sehr lehrreich. Ich habe gemerkt, wie wichtig es ist, Prioritäten zu setzen und die Zeit gut einzuteilen. Auch die Zusammenarbeit im Team hat dabei eine große Rolle gespielt. Eine gute Abstimmung, Aufmerksamkeit bei Überschneidungen und ein respektvoller, unterstützender Umgang haben wesentlich dazu beigetragen, dass wir effizient arbeiten konnten und gleichzeitig eine angenehme Atmosphäre hatten.

Am Ende bin ich stolz auf das, was wir als Team in dieser kurzen Zeit erreicht haben. Besonders wertvoll war für mich die Erfahrung, meine eigenen Stärken gezielt einzubringen und gleichzeitig neue Arbeitsweisen kennenzulernen. Ich nehme aus dieser Woche viele Erkenntnisse mit und würde eine solche Erfahrung jederzeit wieder machen.

The post Blog | MoveMates appeared first on Mobile USTP MKL.