I had already seen Agent Device before, because I also use Callstack’s React Native on-device AI package and follow some of their work. But the performance testing use case really caught my attention. The idea was simple but powerful: let an AI agent click through a mobile app, collect snapshots of performance numbers and check where frame drops or slow interactions happen. So I wanted to try it myself with one of my React Native builds.

What is Agent Device?

Agent Device is a CLI tool that lets AI agents control mobile apps. It can work with iOS and Android apps, including React Native apps, native apps and apps running on real devices, simulators or emulators.

Instead of only looking at code, the agent can actually interact with the app. It can inspect the UI, understand what is currently on the screen, tap elements, scroll, type into inputs, take screenshots, collect logs and repeat actions. That makes it useful for mobile testing, because the agent can behave more like a real user. It does not only follow a fixed script. It can look at the current app state and decide what to do next based on the UI.

Why performance testing?

Performance problems in mobile apps are not always obvious in the code. Sometimes a screen looks completely fine, but when you use it on a real phone, it feels slow. Maybe an animation drops frames. Maybe a list scrolls badly. Maybe opening a modal causes a short freeze.

That is why I thought Agent Device could be interesting for performance testing. My idea was not to replace proper profiling tools. You still need real profiling when you want detailed information about the JS thread, native rendering, memory usage or expensive renders. But Agent Device can help with the first layer of testing. It can go through the app automatically and collect signals about where the app feels slower or where frame drops happen.

My setup

For my test, I created a build and installed it on a real Android device. Of course, this could also work with emulators. But for performance testing, I think real devices make more sense. A real device gives you more realistic performance behavior. It has real hardware limits, real touch input and real rendering conditions.

After installing the app, I installed the Agent Device CLI. Then I used Antigravity with Gemini 3.5 Flash to control the agent. I used this model because the task was not really about deep reasoning. It mostly needed to follow instructions, use the allowed Agent Device commands and document what happened. Also, the free token limits were good enough for testing this kind of workflow.

Then I wrote a prompt that explained the use case. The agent should open the app, navigate through all screens, interact with different UI elements and take snapshots of the performance numbers. It should also watch out for frame drops, slow transitions and screens that feel less smooth. I also allowed the agent to use all the Agent Device commands it needed, so it could inspect the UI, tap elements, scroll and move through the app without asking every time.

Why this is useful

The biggest benefit for me is that the agent can do the boring part. Normally, performance testing often starts with manually opening the app, clicking around and trying to notice where something feels bad. This works, but it is easy to forget screens or to test in a different way every time.

With Agent Device, the agent can go through a defined flow again and again. It can collect snapshots, describe problems and give a first overview of possible performance issues.

This could be especially useful before releases. You could let the agent run through the main flows and check if there are obvious frame drops or slow interactions before shipping a new version.

What I learned

The most important thing is to see this as an extra testing layer, not as a replacement for proper profiling. Agent Device can help you detect where something might be wrong. But after that, you still need to investigate why it happens. Maybe the issue is caused by too many re-renders, heavy images, expensive calculations, navigation transitions or something happening on the native side.

Still, I think this workflow is really promising. It connects AI agents with real mobile app usage, not just code generation. The agent does not only write or review code. It actually uses the app and checks how it behaves.

I tested this workflow with my own app, Swiva. It is a React Native app for saving activities, places and ideas, and then swiping through them when you need inspiration. If you want to check it out, you can find it here: swiva.app

Final thoughts

I first saw the idea for performance testing with Agent Device on X/Twitter, and after trying it myself, I think it is a very practical use case. There are probably many more possibilities for this kind of mobile automation. QA flows, regression testing, onboarding checks, accessibility testing or release checks could all be interesting.

For me, performance testing was just the first thing that made the tool click. Letting an AI agent move through a real app, collect snapshots and point out possible slow parts feels like a small but useful step towards more automated mobile testing.

The post Automated Performance Testing for React Native with agent-device appeared first on Mobile USTP MKL.

Kurzer Rückblick

TripSync ist eine React Native App, die die Urlaubsplanung in Gruppen vereinfacht. Man kann bereits generelle Reiseinformationen festhalten und eine gemeinsame Packliste führen. Siehe dazu auch meinen vorherigen Blogeintrag: https://mobile.fhstp.ac.at/allgemein/projekt-tripsync/. Nun hat unter anderem noch der Screen mit den geteilten Notizen gefehlt, weshalb ich mich darauf fokussierte.

Vorgehensweise

Als erstes probierte ich aus, direkt in React Native geteilte Notizen zu implementieren, wobei ich hier gleich einmal scheiterte. Deshalb entschied ich mich dann dazu, das Ganze mit einer WebView und einem zusätzlichen Webprojekt umzusetzen.

Um die Technologien und ihr Zusammenspiel zu verstehen, setze ich anfangs ein unabhängiges Projekt mit eigener Authentifizierung und Backend auf. Für TripSync passte ich dann vieles an das vorhandene React Native Projekt und das entsprechende Backend an und optimierte das Ganze für Mobile bzw. die WebView. Das ist der Grund, warum im Endeffekt zwei Projekte entstanden sind, bei denen ich dann mit der Zeit jeweils noch unterschiedliche Funktionen ergänzte.

Screens und deren Features

Tripsync – geteilte Notizen

Auf dem Notizen-Screen der App können Notizen zum aktuell im Profil ausgewählten Urlaub verfasst werden. Dabei gibt es eine Toolbar, die alle wichtigen Bearbeitungs- und Formatierungsmöglichkeiten beinhaltet:

• Rückgängig machen
• Wiederholen
• Rechtschreibprüfung ein-/ausschalten
• Formatvorlage
• Fett/Kursiv/Unterstrichen
• Schriftfarbe
• Textmarkierungsfarbe
• Formatierung zurücksetzen
• Ausrichtung
• Aufzählung
• Checkliste
• Bild einfügen
• Tabelle einfügen/bearbeiten

Die Toolbar befindet sich immer am oberen Rand des Screens, wodurch das Formatieren erleichtert wird. Viele der Bearbeitungsmöglichkeiten werden sofort auf den ausgewählten Text angewendet. Beim Tippen auf das Tabellen-Icon hingegen öffnet sich ein Bottom-Sheet, wo die Anzahl an Spalten und Zeilen für eine neue Tabelle festgelegt werden können. Befindet sich der Cursor in einer Tabelle, ändert sich das Tabellen-Icon und das Bottom-Sheet beinhaltet diverse Bearbeitungsmöglichkeiten, wie z.B. Spalte/Zeile einfügen oder löschen.

Unter der Toolbar sieht man, wer gerade online ist und an den Notizen arbeitet. Daneben befindet sich ein Icon, das angibt, ob die Notizen synchronisiert sind. Mittels Live-Cursor wird einem angezeigt, wo sich die anderen Personen befinden. Dieser ist basierend auf dem Namen der Person in einer speziellen Farbe eingefärbt.

Im Header gibt es außerdem die Möglichkeit, den Link zu dieser Notizen-Seite zu teilen oder zu kopieren, wodurch die Notizen auch im Browser geöffnet werden können. Hier gilt ebenso: Man muss sich anmelden und dem Urlaub angehören, um die Seite öffnen zu können. Die Funktionen sind dieselben wie in der App, nur kann man die Notizen hier zusätzlich auch drucken.

Geteilte Notizen extra

Das Nebenprojekt erinnert an Google Docs. Es lassen sich Notizen verwalten sowie Texte schreiben, bearbeiten und formatieren. Hierbei wurden weitere Technologien genutzt und zusätzlich andere Funktionen eingebaut (Verwaltung mehrerer Notizen, Kommentare, Benachrichtigungen, Erwähnungen und Einstellung der Schriftgröße).

Home

Generell kann die Web-Applikation nur verwendet werden, wenn man sich über Clerk angemeldet oder registriert hat. Der angemeldete Account wird dann oben rechts in der Ecke angezeigt. Daneben gibt es die Möglichkeit, die aktuelle Organisation auszuwählen oder eine neue zu erstellen. Auf der Home-Seite werden alle Notizen aufgelistet, die dieser Organisation zugeteilt sind. Man kann diese über das Drei-Punkte-Menü umbenennen oder löschen, oder über den Button eine neue Notiz erstellen. Erstellt man eine neue Notiz oder klickt auf eine vorhandene drauf, so gelangt man zur Detailseite.

Detail

Auf der Detailseite kann man zusammen mit anderen, die ebenso der Organisation angehören, Notizen schreiben. Links oben wird der Name der Notiz angezeigt, mit der Möglichkeit diese zu bearbeiten. Auf der rechten Seite sieht man die Avatare aller aktuell anwesenden Personen. Hinter dem Glocken-Icon verbergen sich die Benachrichtigungen, die einem mitteilen, wenn man wo erwähnt wurde. Die Toolbar beinhaltet dieselben Funktionen wie beim Projekt für TripSync, nur gibt es zusätzlich noch die Möglichkeit, die Schriftgröße zu ändern und Kommentare zu verfassen. Die Kommentare werden auf der rechten Seite des Screens angezeigt und man kann auf diese reagieren und antworten. Auch bei diesem Projekt werden einem die Positionen der anderen Personen mittels Live-Cursor angezeigt.

Technologien

Tripsync – geteilte Notizen

App:

• React Native WebView

Web:

• Next.js + React
• TipTap Editor
• Liveblocks für Realtime Collaboration
• Zustand für State Management
• Shadcn als UI-Library

Geteilte Notizen extra

• Next.js + React
• TipTap Editor
• Liveblocks für Realtime Collaboration
• Zustand für State Management
• Shadcn als UI-Library
• Convex als DB
• Clerk für Authentication

Challenges und Learnings

Anfangs wurde ich direkt mit dem Problem konfrontiert, dass es eine neuere Version der Expo SDK gab und mein Projekt nicht mehr mit der Expo Go App kompatibel war. Ich musste also diverse Packages des Projekts updaten und dann feststellen, dass es einen Versionskonflikt mit einer Library gab. Glücklicherweise wirkte sich das nicht kritisch auf das Projekt aus, sodass die Anwendung weiterhin einwandfrei funktionierte.

Die nächste Hürde war herauszufinden, wie ich generell geteilte Notizen in React Native umsetzen kann. Ich musste feststellen, dass das nicht so einfach geht, weshalb ich mich dann dazu entschied, eine WebView herzunehmen und ein neues Projekt aufzusetzen. TipTap Editor und Liveblocks haben mir hierbei die Arbeit erheblich vereinfacht.

Schwieriger wurde es, als es an den Feinschliff ging. Dabei musste ich besonders darauf achten, dass die Namen der Personen jederzeit korrekt angezeigt werden (auch in den Erwähnungen und Benachrichtigungen). In Bezug auf die Authentifizierung musste ich auch das ein oder andere ausprobieren. Vor allem in Zusammenhang mit der WebView brauchte ich eine Lösung, den JWT-Token übergeben zu können, der dann weiterverwendet werden kann. Allgemein musste ich mir auch überlegen, wie ich das mit der Authentifizierung mache, sodass das Webprojekt einerseits in der App verwendet werden kann, aber auch als eigenes Projekt im Browser funktioniert. Je nachdem, wo man sich befindet, wird man nämlich zur Login-Seite der App oder des Webprojekts geleitet, wenn man nicht authentifiziert ist.

Außerdem musste ich feststellen, dass es auf mobilen Geräten nicht so trivial ist, ein Element wie die Toolbar in Kombination mit einem Editor dauerhaft am oberen Bildschirmrand zu fixieren. Eine klassische position: sticky-Lösung, bei der die Toolbar zunächst einem anderen Element folgt und erst beim Scrollen oben “andockt”, funktionierte in diesem Fall gar nicht. Letztlich konnte ich das Problem lösen, indem ich die Toolbar als erstes Element platzierte und die Postion bei Scroll- oder Sprungbewegungen dynamisch aktualisiert habe, sodass sie zuverlässig am oberen Rand angezeigt wird.

Fazit

Durch das Projekt konnte ich wertvolle Erfahrungen mit verschiedenen neuen Technologien sammeln. Besonders im Bereich Realtime Collaboration habe ich gemerkt, wie mächtig Liveblocks in Zusammenhang mit TipTap Editor ist. Auch Convex als Realtime-Datenbank sowie Clerk für die Authentifizierung habe ich zuvor noch nie genutzt, war jedoch positiv überrascht, wie unkompliziert sich beide Lösungen integrieren lassen. Insgesamt hat mir das Projekt gezeigt, wie sinnvoll und effizient es manchmal sein kann, auf vorhandene Libraries zurückzugreifen, anstatt jede Funktionalität von Grund auf selbst zu entwickeln.

The post Projekt | TripSync – geteilte Notizen appeared first on Mobile USTP MKL.

Doch React Native allein ist nicht immer der einfachste Startpunkt. Wer sich den Einstieg erleichtern und viele wiederkehrende Aufgaben automatisieren möchte, kommt an Expo kaum vorbei.

Im 2. Semester meines Masterstudiums in Interactive Technologies hielt ich in der Masterklasse Mobile einen Workshop ab, der eine Einführung in die App-Entwicklung mit React Native und Expo gab:

React Native – die Basis

React Native wurde 2015 von Meta (Facebook) veröffentlicht und ist seither ein fester Bestandteil der mobilen App-Entwicklung. Ziel ist es, die aus dem Web bekannte React-Philosophie auch auf mobile Plattformen zu bringen: Komponentenbasiert, wiederverwendbar und flexibel.

Vorteile von React Native

• Plattformübergreifend: Eine Codebasis für Android und iOS
• Performance: Native UI-Komponenten, keine WebViews
• Entwicklerfreundlich: Hot Reloading beschleunigt den Entwicklungsprozess
• Ökosystem: Riesige Community und viele Open-Source-Bibliotheken
• Erfolgreiche Einsätze: Unternehmen wie Facebook, Uber, Airbnb oder Tesla setzen auf React Native

Im Vergleich zu Frameworks wie Ionic oder Flutter zeigt sich ein klarer Unterschied:

• Ionic nutzt stark Web-Technologien und WebViews, was aufwändige Apps schnell an Grenzen bringt.
• Flutter verwendet eine eigene Rendering-Engine und ein komplett eigenes UI-System. Das bietet Flexibilität, geht aber zulasten von App-Größe und Integration in die nativen Systeme.
• React Native dagegen greift direkt auf native APIs zu und integriert sich harmonisch in iOS und Android.

Expo – das Turbo-Framework für React Native

Wer mit React Native arbeitet, merkt schnell: Obwohl es in vielen Fällen einfacher ist als native Entwicklung, braucht man dennoch viel Konfiguration. Build-Tools, Signierungen, App-Store-Prozesse – all das kostet Zeit und Nerven.

Genau hier kommt Expo ins Spiel. Expo ist ein Open-Source-Framework, das wie eine Art „Abkürzung“ für React-Native-Projekte funktioniert.

Was Expo bietet

• Vorgefertigtes SDK mit Zugriff auf Kamera, Standort, Push-Notifications u. v. m.
• Expo Go App: Einfach QR-Code scannen und die App direkt auf dem Smartphone testen – ohne Build-Prozess.
• OTA-Updates (Over-the-Air): Apps können direkt aktualisiert werden, ohne dass der App Store durchlaufen werden muss.
• Schneller Start: Keine komplizierte native Konfiguration notwendig – besonders für Einsteiger ein riesiger Vorteil.

Ein praktischer Vergleich:
Während man bei klassischem React Native oft erstmal eine komplexe iOS- oder Android-Konfiguration anlegen muss, startet man mit Expo praktisch „out of the box“ – fast so, als würde man ein neues React-Webprojekt mit Next.js beginnen.

Expo Go – Entwickeln ohne Hürden

Ein Highlight von Expo ist Expo Go. Statt bei jeder Änderung die App neu bauen zu müssen, scannt man mit der Expo-Go-App auf dem Smartphone einfach einen QR-Code und testet die Anwendung sofort live.

Für Entwickler bedeutet das:

• Sofortiges Feedback bei Änderungen
• Weniger Zeitverlust durch Builds
• Schnelleres Prototyping

Besonders im Teamwork oder bei Präsentationen vor Kunden ist das ein enormer Vorteil, weil Feedback in Echtzeit umgesetzt werden kann.

Expo Application Service (EAS) – Von der Idee in den Store

Früher war der Weg von einer funktionierenden App zum Eintrag im App Store oft eine große Hürde. Mit EAS (Expo Application Service) nimmt Expo Entwicklern auch diesen Teil ab.

Die wichtigsten Funktionen:

• EAS Build: Der Code wird auf Expo-Servern in native Apps für iOS und Android kompiliert. Auch das Signieren übernimmt Expo.
• EAS Submit: Der automatische Upload in den Apple App Store und Google Play Store spart enorm viel Zeit.

Ein besonderer Vorteil: Windows-Nutzer benötigen keinen Mac, um iOS-Apps zu bauen und hochzuladen – eine Einschränkung, die viele Entwickler bisher blockiert hat.

Praxisbeispiel: TODO-App

Ein klassischer Einstieg in die App-Entwicklung ist eine TODO-App. Im Zuge des Workshops wurde eine solche erfolgreich mit den Studenten umgesetzt:

• Nutzer können Aufgaben anlegen, abhaken und löschen
• Die Daten werden lokal gespeichert

Das klingt simpel, zeigt aber: Schon mit wenigen Zeilen Code lassen sich funktionale und plattformübergreifende Apps erstellen – ohne tief in die nativen Eigenheiten von iOS oder Android einzusteigen.

Der vollständige Sourcecode der App aus dem Workshop kann hier heruntergeladen werden:

Fazit – Warum Expo?

React Native ist schon für sich ein mächtiges Framework. Doch Expo hebt die Effizienz und Benutzerfreundlichkeit noch einmal auf ein neues Level. Besonders für kleinere Teams, Start-ups oder Einzelentwickler bedeutet das: schneller Ergebnisse, weniger technische Hürden und ein klarer Fokus auf die eigentliche App-Idee.

Ob für Prototypen, MVPs oder vollwertige Produktions-Apps – Expo bietet eine moderne, schlanke und praxisnahe Lösung, die den gesamten Entwicklungszyklus abdeckt:
Von der ersten Zeile Code über das Testen auf dem Smartphone bis hin zur Veröffentlichung im App Store.

Wer also nach einem Weg sucht, mobile Apps ohne Umwege zu entwickeln, findet in React Native mit Expo einen idealen Einstieg.

Downloads

The post Workshop | Expo (React Native) appeared first on Mobile USTP MKL.

Screens und deren Features

Die App beinhaltet eine Authentifizierung, sodass die Funktionen erst nach dem Login bzw. der Registrierung genutzt werden können.

Profil

Hat man sich eingeloggt, kann man in seinem Profil alle seine geplanten Urlaube verwalten. Hier lässt sich einer der aufgelisteten Urlaube auswählen, der dann für alle anderen Tabs bzw. Screens gilt. Man kann einen neuen erstellen, einem beitreten oder einen löschen bzw. verlassen. Im Profil gibt es außerdem die Möglichkeit sich über das Menü wieder abzumelden.

Um einem Urlaub beizutreten, benötigt man den zugehörigen Code. Dem bzw. der Ersteller*in wird nach dem Erstellen des Urlaubs die Möglichkeit geboten, den Code mittels der „Share“-Funktion zu teilen.

Info

Auf dem Info-Screen werden alle Informationen zum aktuellen Urlaub angezeigt. Dazu gehören Titel, Zeitraum, Beschreibung und die Teilnehmer*innen. Hierbei kann man die Informationen auch bearbeiten und den Code nochmals teilen, falls man noch wen hinzufügen möchte.

Packliste

Die Packliste ermöglicht es mehreren Personen, gemeinsam eine Urlaubscheckliste zu erstellen und direkt zuzuweisen, wer was mitnimmt. Dabei gibt es oben den allgemeinen Bereich mit noch nicht zugeordneten Gegenständen und nachfolgend für jedes Mitglied einen eigenen, angefangen mit sich selbst. Es können Einträge hinzugefügt, gelöscht, in den eigenen oder in den allgemeinen Bereich verschoben und als eingepackt markiert werden.

Restliche Screens

Es soll auch noch weitere Screens bzw. Tabs geben, die beispielsweise einen Kostenrechner oder gemeinsame Notizen beinhalten. Im Zuge der 82 h wurden diese aber nicht umgesetzt.

Technologien

Backend

• NestJS
• Prisma
• Zod und zod-prisma-type für Type Generation
• Swagger
• Docker

Frontend

• React Native mit Expo
• Native Wind (Tailwind für React Native)
• Zustand für State Management
• OpenAPI Generator
• Libraries: react-native-bottom-sheet, react-native-elements, react-native-bouncy-checkbox etc.

Challenges und Learnings

Backend

Im Backend interessierte mich die Verwendung von Prisma. Dabei hat man ein zentrales Schema-File und kann sich die Types generieren lassen. Zusätzlich zu den generierten Types brauchte ich jedoch eigene DTOs, die ich mittels zod Schemas und Helper Methods umsetze. Ich habe auch auf eine ordentliche Swagger Dokumentation geachtet, sodass ich dann im Stande war, OpenAPI Generator für das Frontend zu verwenden. Es war einerseits sehr praktisch sich darum nicht kümmern zu müssen, andererseits wurde es mühsam, wenn man beispielsweise den Typ eines Objekts brauchte, welches nur innerhalb eines Arrays vorkommt. Diese stehen einem zwar auch zur Verfügung, doch die Namen werden immer länger und unleserlicher. Ich habe dann in solchen Fällen begonnen, eigene Types zu erstellen, die dann auf die generierten verweisen.

Es war anfangs eine Challenge herauszufinden, wie man bei zod Schemas Beispielwerte für Swagger mitgibt. Die Library @anatine/zod-openapi bietet hierbei mittels Methoden wie extendApi die Lösung.

Nachdem wir dieses Semester einen Docker-Workshop hatten, entschied ich mich dafür Docker auch für dieses Projekt zu verwenden und setzte erstmals alles selbst auf.

Frontend

Im Frontend musste ich mich erstmal zurechtfinden, da ich zwar bereits React verwendet hatte, aber nicht React Native. Anfangs war für mich klar, dass ich auch Native Wind einbaue, da ich sehr oft Tailwind CSS nutze. Bei Komponenten aus Libraries ist jedoch das Problem, dass viele (noch) kein Native Wind unterstützen, und somit musste ich oftmals auf gutes altes CSS zurückgreifen. Allgemein hatte ich das Gefühl, dass man bei React Native sehr oft auf Libraries der Community angewiesen ist, da React Native selbst nicht viele vorgestylte Komponenten bietet. Das ist ein Unterschied zu Ionic, den ich bemerkt habe.

Unter anderem verwendete ich das UI-Toolkit React Native Elements. Dieses kommt mit der Option, ein Theme zu erstellen, wobei neben Farben auch die default Styles der Komponenten festgelegt werden können, was sehr hilfreich war. React Native selbst bietet auch ein Color Theme, wodurch ich im Endeffekt beide nutze. Man müsste sich hier noch besser einlesen, was hierbei die Best Practice Lösung ist.

An der Kombination React Native mit Expo war sehr praktisch, dass man Änderungen mittels der Expo Go App schnell auf seinem Handy testen konnte. Das war auch sehr nötig, denn schnell wurde klar, es ist nicht so einfach die App bzw. die externen Komponenten auf jeder Plattform zum Laufen zu bringen, ohne dass unerwartete Verhaltensweisen auftreten. Manchmal gibt es auch Libraries, die nur Komponenten für iOS und Android zur Verfügung stellen, wodurch das Testen im Web schwierig wird.

Neben React Native habe ich mich im Rahmen des Projekts intensiv mit Zustand beschäftigt. Im Vergleich zu Redux ist es eine einfachere State Management Lösung, welche aber trotzdem eine Vielzahl nützlicher Features bietet. Um Logik zu trennen, habe ich meinen Store in Slices unterteilt. Zustand bietet außerdem die Funktion, den Store zu persistieren, wodurch ich manche Daten, wie z.B. den bzw. die User*in, den aktuellen Urlaub etc., zusätzlich lokal speichern konnte.

Fazit

Das Projekt hat mir vor allem einen Einblick in React Native mit Expo gegeben. Das Framework ist einerseits sehr mächtig, auf der anderen Seite können die vielen externen Komponenten mühsam werden. Ich habe aber auch viel Neues in Bezug auf Zustand und Prisma in Kombination mit zod gelernt. Auch die gesehenen Vor- und Nachteile von OpenAPI Generator werden hilfreich für weitere Projekte sein.

The post Projekt | TripSync 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.

Was sind Microinteractions?

Microinteractions sind kleine, intuitive Reaktionen einer Anwendung auf Nutzeraktionen. Sie informieren den Anwender in Echtzeit darüber, was gerade passiert, und tragen dazu bei, dass er sich immer gut abgeholt fühlt. Zu den klassischen Beispielen gehören:

• Animierte Buttons: Die visuelle Rückmeldung beim Hover oder Klick, die dem Nutzer signalisiert, dass eine Aktion registriert wurde.

• Slider: Dynamische Übergänge und Anpassungen, die eine flüssige Bedienung ermöglichen.

• Feedback-Animationen: Kurze visuelle Effekte, die beispielsweise den erfolgreichen Abschluss einer Aktion bestätigen.

• Haptische und auditive Signale: Vibrationseffekte oder dezente Soundeffekte, die das Feedback multisensorisch verstärken.

Warum sind Microinteractions wichtig?

Studien, etwa von der Nielsen Norman Group, haben gezeigt, dass durchdachte Microinteractions das emotionale Erleben und die Zufriedenheit der Nutzer maßgeblich beeinflussen können. Die Bedeutung von Microinteractions lässt sich an mehreren Punkten festmachen:

• Verbesserung der Usability: Durch kontinuierliche, intuitive Rückmeldungen fühlt sich der Nutzer sicher und gut betreut.

• Erhöhung des User-Engagements: Kleine Animationen und Effekte machen die Interaktion lebendiger und motivieren den Anwender, sich intensiver mit der Anwendung auseinanderzusetzen.

• Stärkung des Nutzervertrauens: Wenn Nutzer sofort visuelles, haptisches oder auditives Feedback erhalten, steigt das Vertrauen in die Funktionsweise der Anwendung – ein entscheidender Faktor für den Erfolg moderner Softwarelösungen.

Umsetzungsmöglichkeiten

Für die Implementierung von Microinteractions stehen zahlreiche Techniken und Bibliotheken zur Verfügung:

1. CSS-Animationen

CSS bietet mit transition und @keyframes eine niedrigschwellige Möglichkeit für viele Standard-Effekte. Diese Technik ist leichtgewichtig und läuft in allen modernen Browsern sehr performant. Beispielsweise kann ein Button durch leichte Veränderungen beim Hover sofort ins Auge fallen:

.button {
  transition: transform 0.2s ease, background-color 0.3s;
}
.button:hover {
  transform: scale(1.05);
  background-color: #007bff;
}
@keyframes pulse {
  0% { transform: scale(1); }
  50% { transform: scale(1.1); }
  100% { transform: scale(1); }
}
.button.active {
  animation: pulse 1s infinite;
}

Diese Methode ist besonders effektiv für schnelle Prototypen und statische Webseiten.

2. Framer Motion (React) https://motion.dev

Für React-basierte Projekte bietet Framer Motion eine deklarative API, die das Erstellen flüssiger und komplexer Animationen ermöglicht. Mit wenigen Codezeilen lassen sich reaktive und interaktive Elemente gestalten.

Im folgenden Beispiel wird ein React-Button animiert, der beim Hover und Tap skaliert:

import { motion } from "framer-motion";

function AnimatedButton() {
  return (
    <motion.button
      whileHover={{ scale: 1.1 }}
      whileTap={{ scale: 0.9 }}
    >
      Klick mich
    </motion.button>
  );
}

Mit Framer Motion kannst du Variants definieren, um verschiedene Zustände zu modellieren, und Transitionskonfigurieren, um Dauer, Verzögerung und Typ (Spring vs. Tween) zu steuern. Dank Tree-shaking bleiben deine Bundles klein. Außerdem funktioniert Framer Motion sowohl client- als auch serverseitig (SSR) und verfügt über eine aktive Community und zahlreiche Beispiele.

3. GSAP (GreenSock Animation Platform) https://gsap.com

GSAP ist eine leistungsstarke JavaScript-Animation-Bibliothek, die besonders für komplexe und präzise gesteuerte Animationen geeignet ist. Sie unterstützt TimeLines, Plugins wie ScrollTrigger für Scroll-basierte Animationen und kann mit DOM-, Canvas- oder SVG-Elementen arbeiten.

Folgendes Beispiel demonstriert eine Hover-Animation auf einem Element mit der Klasse .box:

import { gsap } from 'gsap';

document.querySelector('.box').addEventListener('mouseenter', () => {
  gsap.to('.box', { duration: 0.3, scale: 1.1, ease: 'power2.out' });
});
document.querySelector('.box').addEventListener('mouseleave', () => {
  gsap.to('.box', { duration: 0.3, scale: 1, ease: 'power2.in' });
});

Erklärung:

1. document.querySelector('.box') wählt das Element mit der Klasse box aus.
2. Bei mouseenter wird gsap.to(...) ausgeführt und skaliert das Element mit einer weichen Beschleunigung.
3. Bei mouseleave wird es wieder auf scale: 1 zurückgesetzt.

Brauche ich GSAP dafür?

Für diesen einfachen Effekt genügt auch eine CSS-Lösung ohne zusätzliche Bibliothek:

.box {
  transition: transform 0.3s ease-in-out;
}
.box:hover {
  transform: scale(1.1);
}

Mit CSS erhältst du oft ausreichend Performance und musst keine externe Abhängigkeit einbinden. GSAP ist besonders dann sinnvoll, wenn du detaillierte Kontrolle über Sequenzen brauchst oder Animationen orchestrieren willst, die auf Scroll-, Audio- oder anderen externen Events basieren. Die Performance bleibt dabei dank optimierter Rendering-Loops hoch, auch bei vielen gleichzeitig laufenden Animationen.

4. Haptisches Feedback 

Haptisches Feedback schafft ein taktiles Erlebnis und verstärkt die Wahrnehmung von Interaktionen. Auf mobilen Geräten kann die Vibration API genutzt werden, um kurze Vibrationseffekte zu erzeugen.

So fügst du bei einem Button-Klick auf unterstützten Geräten eine Vibration hinzu:

Browser (Web Vibration API):

if ('vibrate' in navigator) {
  navigator.vibrate(200); // Vibrationsdauer in Millisekunden
}

Native Android (Kotlin):

val vibrator = getSystemService(Context.VIBRATOR_SERVICE) as Vibrator
vibrator.vibrate(VibrationEffect.createOneShot(200, VibrationEffect.DEFAULT_AMPLITUDE))

Native iOS (Swift):

let generator = UIImpactFeedbackGenerator(style: .medium)
generator.impactOccurred()

Zu beachten wäre dabei, dass haptisches Feedback in den Systemeinstellungen deaktiviert sein kann. Daher sollte vor dem Auslösen solcher Effekte geprüft werden, ob sie gewünscht sind. Haptische Effekte sollten sparsam und nur bei zentralen Interaktionen eingesetzt werden.

4. Auditive Rückmeldungen

Dezente Soundeffekte, beispielsweise bei Bestätigungen, können über HTML5-Audio-Elemente oder spezialisierte JavaScript-Plugins eingebunden werden.

<audio id="clickSound" src="click.mp3"></audio>
<button onclick="document.getElementById('clickSound').play()">Click me</button>

Für komplexere Szenarien bietet die Web Audio API oder Bibliotheken wie Howler.js  fortgeschrittene Features:

• Audio-Sprites: Laden mehrerer kurzer Sounds in eine Datei, um Ladezeiten zu reduzieren.
• Dynamische Steuerung: Lautstärke, Panning und Effekte in Echtzeit anpassen.

Auch hier wäre zu beachten, dass Nutzer nicht mit dauerhaftem Audiofeedback überflutet werden. Empfehlenswert ist es, in den Einstellungen eine Option zur Deaktivierung oder Abschwächung von Tönen bereitzustellen.

Fazit

Microinteractions sind ein mächtiges Mittel, um Nutzererlebnisse zu verfeinern und den Eindruck einer reaktionsschnellen, konsistenten Anwendung zu vermitteln. Durch den Einsatz von visuellen, haptischen und auditiven Feedback-Mechanismen wird die Interaktion intuitiver und ansprechender. Ganz gleich, ob man einfache CSS-Animationen, spezialisierte Bibliotheken wie Framer Motion oder GSAP oder plattformspezifische APIs nutzt — gut gestaltete Microinteractions können mit relativ geringem Entwicklungsaufwand eine große Wirkung erzielen und die User Experience signifikant verbessern.

The post Blog | Microinteractions: Kleine Details mit großer Wirkung appeared first on Mobile USTP MKL.

Was ist NativeWind?

NativeWind ist eine Tailwind-inspirierte Bibliothek für React Native. Sie bringt das bewährte Utility-First-Designprinzip von Tailwind CSS in die mobile App-Entwicklung. Während Tailwind CSS das Front-End-Web-Design revolutioniert hat, bietet NativeWind eine vergleichbare Lösung für die mobile Entwicklung, die es dir ermöglicht, das Styling direkt in deinem JSX mit Tailwind-ähnlichen Utility-Klassen vorzunehmen. Dies bedeutet, dass du keine komplexen Style-Objekte oder separaten Stylesheets mehr benötigst, um deine mobile App zu stylen.

Mit NativeWind kannst du deine React Native-App so schnell und effizient stylen, wie du es von Tailwind auf der Webseite gewohnt bist. Es ist speziell für Expo und React Native entwickelt und ermöglicht eine saubere und wartbare Codebasis.

Warum NativeWind für Expo und React Native?

React Native ermöglicht es Entwicklern, plattformübergreifende Apps mit JavaScript und React zu erstellen. Allerdings gestaltet sich das Styling in React Native oft als weniger intuitiv und kann schnell unübersichtlich werden, insbesondere wenn man zwischen verschiedenen Plattformen (iOS und Android) und verschiedenen Styling-Methoden wechselt.

Mit NativeWind kannst du das gleiche Utility-First-Styling anwenden, das in der Webentwicklung so erfolgreich ist. Es eliminiert den Bedarf an komplizierten und umfangreichen Style-Objekten und ermöglicht es dir, das Styling direkt im JSX zu definieren – ähnlich wie bei der Verwendung von Tailwind CSS für Webanwendungen. Diese Flexibilität und Benutzerfreundlichkeit machen NativeWind zu einer ausgezeichneten Wahl für Expo React Native Apps.

Vorteile von NativeWind

1. Utility-First-Styling

Der größte Vorteil von NativeWind ist der Utility-First-Ansatz, der direkt in den JSX-Komponenten zum Einsatz kommt. Anstatt separate Stylesheets zu erstellen oder Inline-Styles zu verwenden, kannst du die gleichen Tailwind-ähnlichen Klassen wie bg-blue-500, text-white oder flex-1 direkt in deinem JSX-Code einfügen. Dies spart nicht nur Zeit, sondern macht deinen Code auch kürzer und übersichtlicher.

Beispiel:

import { View, Text } from 'react-native';

export default function App() {
  return (
    <View className="flex-1 justify-center items-center bg-blue-500">
      <Text className="text-white text-lg font-bold">Hello World</Text>
    </View>
  );
}

2. Weniger Boilerplate-Code

Traditionelles React Native-Styling kann manchmal viel Boilerplate-Code erfordern. Man muss häufig Style-Objekte erstellen und sie dann in den Komponenten anwenden. Mit NativeWind entfällt diese Notwendigkeit. Du kannst das Styling direkt im JSX definieren und so eine sehr klare, lesbare Struktur behalten.

3. Bessere Lesbarkeit und Wartbarkeit

Durch die Verwendung von Utility-Klassen wird der Code in NativeWind übersichtlicher. Statt komplexe Style-Objekte und lange CSS-Regeln zu schreiben, kannst du durch die einfache Kombination von Utility-Klassen dein Layout definieren. Dies macht den Code nicht nur leichter verständlich, sondern auch einfacher zu warten.

4. Optimierung und Tree-Shaking

Ein weiterer Vorteil von NativeWind ist die Möglichkeit der Tree-Shaking. Genau wie bei Web-Tailwind wird im Hintergrund überprüft, welche Klassen tatsächlich verwendet werden. Unbenutzte Klassen werden aus dem endgültigen Bundle entfernt, was deine App schlanker macht und die Performance optimiert.

5. Nahtlose Integration in Expo

Da Expo eine Sammlung von Tools und Services bietet, die den Entwicklungsprozess von React Native Apps vereinfachen, ist die Integration von NativeWind besonders vorteilhaft. Du kannst eine Expo-App schnell aufsetzen und dabei gleichzeitig von den Vorteilen des Utility-First-Ansatzes profitieren. NativeWind funktioniert nahtlos innerhalb des Expo-Ökosystems und sorgt für eine schnelle Entwicklung und einfache Wartung.

Wie installierst du NativeWind in einem Expo-Projekt?

Die Installation von NativeWind in einem Expo-Projekt ist einfach und schnell. Hier ist eine Schritt-für-Schritt-Anleitung:

1. Expo-Projekt erstellen

Falls du noch kein Expo-Projekt erstellt hast, kannst du ein neues Projekt mit folgendem Befehl erstellen:

npx create-expo-app my-nativewind-app
cd my-nativewind-app

2. NativeWind installieren

Um NativeWind in deinem Expo-Projekt zu verwenden, installiere es mit folgendem Befehl:

npm install nativewind

3. Tailwind-Konfiguration einrichten

Erstelle eine tailwind.config.js-Datei, um NativeWind zu konfigurieren:

npx tailwindcss init

Passe die Konfiguration so an, dass sie mit deiner App funktioniert:

module.exports = {
  content: [
    './App.js',  // Haupt-Dateipfad
    './src/**/*.{js,jsx,ts,tsx}'  // Alle Verzeichnisse, die React Native-Komponenten enthalten
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

4. NativeWind in deiner App verwenden

Jetzt kannst du NativeWind in deinem JSX verwenden, um deine App zu stylen. Hier ist ein einfaches Beispiel:

import { View, Text } from 'react-native';

export default function App() {
  return (
    <View className="flex-1 justify-center items-center bg-red-500">
      <Text className="text-white text-3xl font-bold">Hello from NativeWind!</Text>
    </View>
  );
}

Fazit

NativeWind ist eine fantastische Möglichkeit, den beliebten Tailwind CSS Utility-First-Ansatz auf React Native-Apps anzuwenden. Es ermöglicht dir, dein Styling direkt im JSX zu definieren, wodurch dein Code kürzer, lesbarer und wartbarer wird. In Kombination mit Expo bietet NativeWind eine schnelle und effiziente Möglichkeit, mobile Apps zu entwickeln und zu stylen, ohne sich mit traditionellen Style-Objekten oder externen Stylesheets auseinandersetzen zu müssen.

Wenn du bereits mit Tailwind CSS auf der Webplattform gearbeitet hast, wird dir NativeWind den Übergang zu React Native erheblich erleichtern. Es beschleunigt deinen Entwicklungsprozess und verbessert gleichzeitig die Performance deiner App.

The post Blog | NativeWind: Tailwind für Expo React Native Apps appeared first on Mobile USTP MKL.