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.

Obwohl ich bereits unzählige Stunden in IDEs wie VS Code verbracht habe, um Apps und mehr zu entwickeln, hatte ich mich bisher nie damit beschäftigt, wie sich die Entwicklungsumgebung selbst erweitern lässt.

Da ich die Idee hatte, in meiner Masterarbeit eine VS Code Extension zu entwickeln, wollte ich das Einzelprojekt im 3. Semester der Masterklasse Mobile nutzen, um erste praktische Erfahrungen mit der Entwicklung von VS Code Extensions zu sammeln, bevor ich mich an die separate Entwicklung des Masterarbeitsprojekts mache.

Das Ergebnis dieses explorativen Projekts ist “Cute Cat”: eine süße VS Code Extension, die unterschiedliche Möglichkeiten von VS Code Extensions kombiniert.

Features

Commands

Die Extension stellt mehrere Commands zur Verfügung, die direkt über die Command Palette in VS Code aufgerufen werden können:

• “Meow!” zeigt eine kurze Informationsnachricht.
• “Show me the cat“ öffnet ein Informations-Popup, in welchem auch mehrzeiliger Text verwendet werden kann.
• “Wake up cat“ aktiviert die WebView im Side Panel (falls sie nicht schon angezeigt wird) und zeigt eine überraschte Katze für ein paar Sekunden. Die WebView wird weiter unten im Detail beschrieben.
• “Wrap selection in try catch block“ erweitert den ausgewählten Code automatisch um einen try-catch-Block oder gibt eine Warnung aus, falls keine Auswahl getroffen wurde.

Themes

Neben funktionalen Features wurden auch eigene Designkomponenten umgesetzt:

• “Cute Cat Pastel Dark” Colour Theme
• “Cute Cat Pastel Icons” Icon Theme

Dabei lag der Fokus auf einer konsistenten visuellen Identität. Die Kombination aus sanften Pastelltönen und angepassten Icons verleiht der Extension einen klaren Wiedererkennungswert.

WebView Side Panel

Ein zentrales Element der Extension ist die WebView im Side Panel. Dort wird ein animiertes Katzen-GIF angezeigt, das dynamisch auf Kontextinformationen reagiert:

• Anpassung an die Tageszeit (z. B. „Good Morning“)
• Reaktion auf lange Coding-Sessions (z. B. schlägt die Katze dem*der User*in nach 4 Stunden vor, eine Kaffeepause einzulegen)
• Anzeige der aktuellen Session-Dauer
• Anzeige, wie lange die Extension insgesamt schon aktiv ist (“Did you know we have been friends for 19h 58min?“)

Zusätzlich kann innerhalb der WebView über ein Settings-Icon ein Modal geöffnet werden, in dem User*innen mit einem Klick die bereitgestellte Colour bzw. Icon Theme (de)aktivieren können.

Text Decorations

Ein weiteres Feature der Extension sind dynamische Text Decorations. In den geöffneten Texteditoren werden Schlüsselwörter wie “cat” und “cute” mit kleinen dekorativen Elementen versehen.

Projektaufbau

Vereinfacht dargestellt ist das Projekt wie folgt aufgebaut:

- media/
  - webViewScript.js
  - webViewStyles.css
  - [...Bilder]
- src/
  - extension.ts (Einstiegspunkt)
  - [...]
- themes/
  - color-theme.json
  - icon-theme.json
- [...]
- package.json (Manifest)

Wichtig sind hierbei die package.json Datei, in welcher die Commands, WebView und Themes deklariert werden, und die src/extension.ts Datei, welche den Einstiegspunkt der Extension darstellt:

import * as vscode from 'vscode';

export function activate(context: vscode.ExtensionContext) {
    // ...
}

export function deactivate() {}

Challenges und Learnings

API-Dokumentation

VS Code bietet einen “Your First Extension” Guide und stellt viele Beispielprojekte zu unterschiedlichen Extension-Funktionalitäten für Entwickler*innen zur Verfügung. Trotzdem ist es manchmal nicht so leicht, das genaue Beispielprojekt, welches man sucht, zu finden. Ich würde zukünftigen Extension-Developer*innen empfehlen, direkt auf GitHub zu schauen (https://github.com/microsoft/vscode-extension-samples), anstatt nur in der VS Code Extension API zu suchen.

Falls man etwas Bestimmtes zur VS Code API nachschauen will, ist diese recht gut dokumentiert. Leider funktionieren einige Links auf der Website allerdings nicht, weshalb ich mich hauptsächlich mit der Suchfunktion (STRG+F) durch die API-Dokumentation arbeiten musste.

Von der Community gibt es eher weniger Tutorials und Online-Beiträge. Um die VS Code Extension zu entwickeln, kombinierte ich daher Informationen aus der API-Dokumentation, aus Beispielprojekten und Tutorials und erarbeitete mir die fehlenden Details eigenständig durch “Learning by Doing”.

Text Decoration Icons

Man würde denken, ein Bild als Text Decoration zu setzen, wäre trivial. Doch hat es mich einige Zeit gekostet, bis ich Folgendes realisiert habe: Wenn man ein SVG Icon verwenden will, darf dieses nicht selbst “width” und “height” angeben. Obwohl man der Text Decoration sowohl width, als auch height, mitgeben kann, werden diese Angaben ignoriert, wenn das SVG seine eigene Größe vorgibt.

Weiters werden die Icons nicht mitting in der Zeile positioniert (siehe das Bild der Text Decorations: die Icons sind etwas weiter oben positioniert als der Text). Man kann der Decoration zwar auch einen Margin mitgeben, allerdings würde z. B. ein Top-Margin (um den extra Platz unterhalb des Icons auszugleichen) nicht nur das Icon, sondern die ganze Zeile nach unten schieben.

Kommunikation zwischen Extension und WebView

Eine weitere Challenge war die Kommunikation zwischen der Extension und der WebView, um insbesondere bei den “Theme Toggles” beide Seiten am gleichen Stand zu halten (wenn das Theme (extern) aktiviert wurde, sollte auch der Toggle in der WebView automatisch aktiviert werden). Dank der VS Code API können aber Nachrichten recht einfach zwischen der Extension und der WebView ausgetauscht werden.

Debugging

Ich fand es sehr spannend, insbesondere die WebView zu debuggen. Über die Command Palette in VS Code lässt sich der Web Inspector öffnen (“Toggle Developer Tools”), mit welcher sowohl der Console-Output, als auch die HTML-Elemente der ganzen IDE inspiziert werden können. Innerhalb von den Sourcefiles (abgesehen von webViewScript.js) lassen sich allerdings auch Breakpoints setzen.

Obwohl der sogenannte “Extension Development Host” (das separate VS Code Fenster, in welchem die Extension während der Entwicklung läuft) viel zu bieten hat, konnte ich nicht die komplette Funktionalität meiner Extension darin testen. Das Icon Theme lässt sich innerhalb des Extension Hosts zum Beispiel nicht programmatisch für den Workspace setzen (innerhalb von .vscode/settings.json), weshalb ich die Extension mit dem “vsce package” Command zuerst builden und installieren musste, um den “Icon Theme Toggle” innerhalb der WebView zu testen.

Conclusion

Mit dem Projekt “Cute Cat” konnte ich einen intensiven Einblick in die Möglichkeiten und Herausforderungen von VS Code Extensions gewinnen. Besonders wertvoll war für mich dabei der explorative Charakter des Projekts: Ich konnte vieles ausprobieren und dadurch ein tiefes Verständnis für die Entwicklung von VS Code Extensions aufbauen.

Ich bin stolz auf das, was ich erreicht habe, und fühle mich nun bestens vorbereitet, das nächste Projekt anzugehen: die Entwicklung meiner eigenen VS Code Extension im Rahmen der Masterarbeit.

The post Projekt | VS Code Extension appeared first on Mobile USTP MKL.

Worum es in der App geht

Im Kern funktioniert Timelapse wie ein visuelles Tagebuch:

• Nutzer:innen legen Projekte an (z. B. „Daily Selfie“ oder „Zimmerpflanze“).
• Die App erinnert regelmäßig daran, neue Fotos aufzunehmen.
• Alle Bilder werden zeitlich geordnet, mit Datum und optionalen Kommentaren gespeichert.
• Auf einer kompakten Übersicht sieht man, wann man etwas aufgenommen hat, welche Tage besonders wichtig waren und wie sich das Projekt über Wochen und Monate entwickelt.
• Aus dieser Sammlung erzeugt Timelapse auf Knopfdruck ein Zeitraffervideo, das die Geschichte des Projekts in wenigen Sekunden erzählt.

Zentrale Funktionen in Kürze

• Projektorganisation: Mehrere parallele Timelapse-Projekte mit Titel, Beschreibung und individuellen Einstellungen.
• Visuelle Timeline: Eine kombinierte Wochen- und Listenansicht zeigt, welche Tage schon dokumentiert sind und welche Lücken es noch gibt.
• Erinnerungen: Konfigurierbare Benachrichtigungen, damit die tägliche Aufnahme zur Routine wird und die Timeline nicht abreißt.
• Favoriten & Notizen: Einzelne Tage können hervorgehoben und mit kurzen Kommentaren versehen werden – etwa um Meilensteine oder besondere Momente zu markieren.
• Automatische Video-Montage: Die App erstellt aus den Bildern ein Video, berücksichtigt Ausrichtung, Datum, optionales Wasserzeichen und Kommentare und bietet Konfigurationsmöglichkeiten für Qualität oder Textstil.

Technologie-Stack

Die App ist als native Android-Anwendung mit Jetpack Compose umgesetzt und nutzt moderne Android-APIs sowie eine klare Schichtung zwischen UI, Logik und Medienverarbeitung.

• UI: Jetpack Compose + Material 3
  • Alle Screens (Projektliste, Details, Dialoge, Konfiguration) sind vollständig in Compose realisiert.
  • Material-3-Komponenten wie LargeFlexibleTopAppBar, Listen, Cards und Dialoge sorgen für ein konsistentes Look & Feel.
  • Ein zentrales TimelapseTheme verwaltet App-Theme (Light/Dark), Seed-Farbe und den Palette-Stil.
• Material 3 Expressive & Material You
  • Die App nutzt Material 3 Expressive, um eine lebendige, charakterstarke Farb- und Typografie-Sprache umzusetzen – passend zu einer App, die persönliche Veränderungen dokumentiert.
  • Über einen integrierten Color Picker wählen Nutzer:innen eine eigene Akzentfarbe.
  • Aus dieser Seed-Farbe wird mit Material You ein komplettes Farbschema generiert, das sich konsistent über die gesamte App zieht.
  • Dadurch wirkt Timelapse auf jedem Gerät persönlich, bleibt aber immer klar strukturiert und gut lesbar – unabhängig davon, ob Light- oder Dark-Mode aktiv ist.
• Video-Montage & Bildverarbeitung
  • Die Montage-Logik läuft in einem eigenen Modul:
  • Bilder werden anhand ihrer EXIF-Daten korrekt ausgerichtet.
  • Ein Canvas setzt die Frames zusammen, ergänzt Texte (Datum, Kommentare, Wasserzeichen) und kümmert sich um Hintergrundfarbe und Zensurflächen.
  • Ein Muxer erzeugt daraus ein MP4-Video, gesteuert über Kotlin Flows, die den Fortschritt an die UI melden.
  • So entsteht aus einer losen Sammlung von Bildern ein stimmiges Timelapse-Video, ohne dass externe Tools nötig sind.

Material 3 Expressive & Material You im Einsatz

Ein großer Fokus des Projekts lag auf einer modernen, adaptiven UI, die sich nach den Nutzer:innen richtet:

• Dynamische Farbwelten
  • Durch den Seed-Color-Ansatz wirkt die App nicht wie ein statisch durchgestyltes Produkt, sondern wie ein Rahmen, der sich der jeweiligen Geschichte anpasst.
  • Projekte mit emotionalem Kontext (z. B. Schwangerschaft, Beziehungen, erste Wohnung) profitieren von den kräftigen, expressiven Paletten, die Material 3 bereitstellt.
• Einheitliche, weiche Formsprache
  • Großzügige Rundungen (z. B. extra große Card-Shapes in Dialogen), expressive Typografie und bewusst eingesetzte Icons unterstützen den Tagebuch-Charakter der App.
  • Die App verzichtet auf überladene UI-Elemente und setzt auf Ruhe, Klarheit und Fokus – wichtig, wenn man sich über Monate immer wieder mit derselben Oberfläche beschäftigt.
• Konsistentes Theming
  • Alle Bausteine – von Erfassungsdialogs über Erinnerungs-Settings bis hin zu Fortschrittsanzeigen bei Scans und Montage – hängen am gleichen Theme.
  • Änderungen an Theme, Palette oder Seed-Farbe greifen sofort durch, ohne dass einzelne Screens speziell angepasst werden müssen.

Herausforderungen & Learnings

• Balance zwischen Einfachheit und Kontrolle
  • Nutzer:innen sollen einerseits „einfach nur“ ein Timelapse-Video erstellen können, andererseits genug Einstellmöglichkeiten für Qualität, Text, Stabilisierung und Privatsphäre haben.
  • Ein wichtiger Lernpunkt war, die Komplexität hinter klaren Dialogen und wenigen, gut erklärten Optionen zu verstecken.
• Stabile, angenehme Timelapse-Videos
  • Kleine Fehler bei Skalierung oder Matrix-Transformation führen schnell zu Sprüngen oder abgeschnittenen Bereichen – hier war viel Feintuning nötig.
• Durchgängiges Theming mit Material 3 / Material You
  • Seed-Farben, dynamische Paletten und unterschiedliche Palettenstile (z. B. Expressive) lassen sich mächtig kombinieren – aber nur, wenn das Theming-Konzept von Anfang an klar definiert ist.
  • Die wichtigste Erkenntnis: Ein zentrales Theme-Objekt vereinfacht langfristig alle Entscheidungen rund um Farben, Typografie und Component-Styling.

Fazit

Timelapse war für mich ein Projekt, in dem sich User Experience, modernes Android-Design und Medienverarbeitung sehr gut ergänzt haben. Die App zeigt, wie sich mit Jetpack Compose, Material 3 Expressive und Material You eine Oberfläche bauen lässt, die technisch anspruchsvolle Abläufe (zB. Videomontage) hinter einem einfachen, persönlichen Nutzungserlebnis versteckt. Besonders spannend war zu sehen, wie stark sich die Wahrnehmung der App ändert, wenn man eine eigene Farbwelt definieren kann und diese sich konsequent durch alle Screens zieht. In zukünftigen Schritten möchte ich die App um Themen wie Musik, Export-Presets und umfangreichere Sharing-Optionen erweitern – immer mit dem Ziel, den Kern beizubehalten: Veränderung sichtbar machen, ohne dass sich der Aufwand danach anfühlt.

The post Projekt | Timelapse Android App 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.

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.

Abstract

This paper examines the use of edge computing to enhance modern web applications that require low latency and high interactivity. Traditional cloud architectures struggle with increasing traffic and long network distances, which can lead to congestion and reduce the quality of the user experience. Content Delivery Networks (CDNs) were an early step towards decentralisation because they cache content on servers closer to users, thereby shortening round-trip times. Edge computing builds on this concept by not only moving data, but also parts of the application logic, to nearby edge servers. This paper explains how serverless edge platforms execute eventdriven functions at the network edge to enable faster, more dynamic page rendering and reduce latency, bandwidth requirements and energy usage on mobile devices. It also identifies open challenges for edge-based web applications, including limited resources on edge nodes, managing distributed application state and ensuring security and reliability across diverse infrastructures

1 Introduction

Edge computing has become a key technology for handling growing demands in low-latency data processing and real-time responsiveness. Unlike centralized cloud models, edge computing brings data processing and computation closer to end devices. This is particularly important for applications in the Internet of Things (IoT) and web environments, where responsiveness and localized control are essential. (Gupta et al., 2025, p. 94) (Batool and Kanwal, 2025, p. 1) In theory, the fastest way is always to skip the data transportation over the internet and compute tasks directly on the device (Varghese et al., 2016, p. 21). However, for smaller devices like phones or Internet-of-Things devices the computational power may be too small and has to be sourced out to servers. But real-time applications may have preferred response times under 100 ms, where classic cloud infrastructure cannot provide responses fast enough. (Varghese et al., 2016, p. 21) Web applications benefit from edge computing by reducing access time to distant cloud servers. Placing computing tasks at the network edge enables faster content delivery, dynamic page rendering and low-latency interactions. These benefits are crucial for modern, interactive web services. (Varghese et al., 2016, p. 21) Bringing some of the computation physically closer to the user is part of a greater concept called the Content Delivery Network (CDN). It not only focuses on edge computing but has evolved over time into using AI techniques to predict traffic and optimize routes, 5G technologies and also serverless architectures. (Tyagi, 2025, p. 402) This paper provides a state-of-the-art overview of edge computing for web applications, focusing on latency, CDN evolution and serverless edge platforms.

2 Background: Web applications and Latency

Today, Web-based Information Systems (WBIS) play a crucial role in many sectors such as healthcare, smart cities and industrial automation. However, traditional centralized cloud computing often struggles to meet the high performance requirements of these modern applications. The main problems are bandwidth limitations and long physical distance between a device and the cloud servers. To solve this, data processing must move closer to the source to improve responsiveness and efficiency. (Fazil et al., 2025, p. 1)

2.1 The Necessity of Low Latency

Using a centralized cloud introduces unavoidable delays because data has to travel a long distance. This is a major issue because mobile data traffic is exploding, with things like video streaming accounting for a huge portion of network load (Zhao et al., 2021, p. 1). Sending all this heavy traffic to central clouds causes congestion and wastes bandwidth (Varghese et al., 2016, p. 21). Furthermore, mobile devices often suffer from limited battery life. By processing tasks at the network edge instead of sending them deep into the cloud, we can not only reduce response time but also increase battery life (Javed et al., 2021, p. 16) (Zhao et al., 2021, p. 10). Ultimately, high latency hurts the Quality of Experience (QoE), which is often more important to users than simple technical metrics (Zhao et al., 2021, p. 2).

2.2 Real-Time Interaction and Dynamic Content

The architecture of web applications has evolved significantly. Historically, websites relied on Server-Side-Rendering (SSR), where the server builds the complete page for every request (Vepsäläinen et al., 2023, p. 2). Later, developers shifted towards Client-SideRendering (CSR) and Single Page Applications (SPAs) to create more interactive experiences that feel like desktop applications without reloading the whole page (Vepsäläinen et al., 2023, p. 2). However, mobile devices often have limited computing power and may not handle some complex tasks on their own (Varghese et al., 2016, p. 21). Offloading these tasks to a distant cloud is often too slow. Edge computing helps by allowing dynamic content generation at the network edge, supporting new hybrid techniques like Incremental Static Regeneration (ISR) or the “Islands Architecture”, which allow dynamic content to be loaded efficiently without rebuilding the whole site (Vepsäläinen et al., 2023, p. 3).

2.3 Latency Thresholds and Requirements

Real-time applications have strict limits on response times. Research shows that interactive applications, such as visual guiding systems, work best with a response time between 25ms and 50ms (Varghese et al., 2016, p. 20-21). Traditional cloud infrastructures are often too slow, with round-trip times reaching around 175ms (e.g. between Canberra and Berkeley) (Varghese et al., 2016, p. 21). In industrial or medical scenarios, such delays can cause fatal errors (Zhao et al., 2021, p. 2). To consistently achieve response times fast enough, computing tasks could be moved from the centralized cloud to edge nodes (Cao et al., 2020, p. 85716).

3 Content Delivery Network as a Precursor

Before understanding edge computing, the greater concept to grasp is the Content Delivery Network (CDN) and the necessity to provide content more efficiently (Vepsäläinen et al., 2023, p. 1,4). CDNs represent a significant technological precursor in this evolution, establishing the fundamental concept of decentralizing data to reduce latency and increase reliability (Vepsäläinen et al., 2023, p. 1,3-4).

3.1 Basic Idea and Historical Context

For a long time, websites were hosted on a central web server that served static content (Vepsäläinen et al., 2023, p. 1). In the early 1990s, when the internet and websites were an emerging technology, bandwidth-intensive content such as images and web pages were causing bandwidth congestion and brought up the use of basic web caching (Zhao et al., 2021, p. 4). With the explosion of multimedia traffic in the 21st century, especially videos, centralized server architectures became insufficient due to high latency when transmitting data over long geographical distances (Zhao et al., 2021, p. 4) (Gupta, 2024, p. 2). The fundamental concept of a Content Delivery Network is to lower the physical distance by distributing content across a global network of servers located closer to the end user (Siidorow, 2024, p. 9-10). Instead of routing every request to a central origin server, CDNs deliver static assets, such as HTML documents or media files, from multiple geographically distributed points (Siidorow, 2024, p. 9-10). This architecture significantly reduces the RoundTrip Time (RTT) and reduces the load on the central servers as well as other parts of the network’s infrastructure by minimizing redundant data transmission (Gupta, 2024, p. 2) (Siidorow, 2024, p. 9-10).

3.2 Cache Hierarchies and Infrastructure

The architecture of a CDN is based on the strategic deployment of surrogate servers, or edge nodes at the network’s border (Vepsäläinen et al., 2023, p. 3-4) (Varghese et al., 2016, p. 20-21). These nodes function as proxy caches that replicate and store copies of popular content to maximize availability and access speed and minimize requests to far away central servers (Gupta, 2024, p. 5). The distributed infrastructure represents a distinct shift from the traditional cloud computing model. While cloud computing relies on centralized data centers to gather resources and perform long-term, heavy data analysis, this centralization often introduces latency due to the physical distance to the data source. (Dong et al., 2020, p. 314, 316) (Cao et al., 2020, p. 85715) In contrast, the edge layer decentralizes operations by acting as an executor for real-time, small-scale data processing, while the cloud remains the global coordinator for tasks where high speeds are not a requirement (Dong et al., 2020, p. 318) (Cao et al., 2020, p. 85716). Therefore, edge computing and CDNs do not replace the cloud but supplement it and work together to form a “Cloud-Edge”, where depending on latency and processing power requirements the tasks are either handled locally or forwarded to the central cloud (Dong et al., 2020, p. 315-316) (Fazil et al., 2025, p. 5) (Cao et al., 2020, p. 85717). To manage the limited storage at these edge nodes efficiently, CDNs use sophisticated caching concepts like “Least recently used” (LRU), “Least frequently used” (LFU) and “First in first out” (FIFO) (Zhao et al., 2021, p. 12). In mobile network environments, these caching strategies can extend to caching directly at base stations to further reduce backhaul traffic and response time to improve the user’s Quality of Experience (Zhao et al., 2021, p. 5,9).

3.3 Typical Request Flow

The typical flow of a request in an architecture that uses Content Delivery Networks differs significantly from the traditional communication between client and server. In a typical mobile edge caching model, content requests coming in from the user are first received by edge nodes located in the physically close environment of the user, rather than traveling directly to a far away central data center (Zhao et al., 2021, p. 8-9). To manage this traffic efficiently, CDNs use global load balancing mechanisms that assign each request to the closest available cache server (Dong et al., 2020, p. 318). In this process, the Domain Name System (DNS) redirects the request toward the nearest and most responsive cache node, based on the user’s current network location (Zhao et al., 2021, p. 9). A typical request flow could look like this:

• Routing and Identification:
  When a user requests content, the network identifies the optimal edge node for this request. This selection is handled by load-balancing algorithms that assign the request to the geographically nearest edge nodes (Zhao et al., 2021, p. 9) (Dong et al., 2020, p. 318)
• Content Exploration and Cache Lookup:
  The edge node checks its local storage for the requested asset. If the content is not immediately available on the specific node, the system must search the network to determine the best way to retrieve it at the lowest cost. This is defined as the “content query problem” and may involve forwarding queries to neighboring user equipment or base stations before traveling the whole distance to the central network. (Zhao et al., 2021, p. 10-11)
• Retrieval and Delivery:
  • Cache Hit: If the file is available, it is delivered immediately to the user.
  • Cache Miss: If the content is not available on the node, it is retrieved from higher-level servers, or in the worst case, from the central cloud. The file is then stored locally using replacement policies such as Least Recently Used (LRU) to manage limited storage, and finally served to the user. (Zhao et al., 2021, p. 10-12)
  
  This mechanism not only minimizes latency but also significantly reduces the load on backhaul links by minimizing redundant data traffic to the core network. (Cao et al., 2020, p. 85720)

3.4 Advanced CDN Architectures

As the demand for real-time interactivity and dynamic content grows, the traditional model of simple caching servers has proven to be insufficient in some cases. CDN infrastructures have evolved into complex architectures that build the base for smart edge computing. This is shown by emerging strategies like Distributed, Hybrid and Multi-CDN which are designed to enhance scalability, reliability and performance under varying network conditions.

• Distributed Architectures:
  In modern CDNs, the goal is a highly distributed architecture where numerous edge servers are deployed across multiple Points of Presence (PoPs). This approach focuses on minimizing the physical path between the user and the content and significantly reducing latency and ensuring that high traffic volumes are handled locally rather than overwhelming central data centers. (Tyagi, 2025, 406-407,414)
• Hybrid Architectures:
  Hybrid architectures combine traditional on-premise edge servers with cloud-based CDN services. This approach helps organizations adjust their resources based on real-time demand. During peak traffic, additional workloads can be offloaded to the cloud, while normal operations continue on local infrastructure. This idea is based on the Cloud-Edge where both edge nodes and cloud systems work together. (Tyagi, 2025, 406-407)
• Retrieval and Delivery:
  To ensure high availability and reduce the risk of vendor-specific outages, big enterprises increasingly use Multi-CDN strategies. In this model, the traffic is distributed across CDN services from multiple vendors based on real-time performance metrics, geographical location and cost. If a certain CDN encounters problems like congestion or latency in particular regions or globally, an AIdriven traffic management system can automatically reroute the users to better-performing providers. This hopes to ensure that big platforms like Amazon or Netflix won’t encounter big outages and interrupted service. (Tyagi, 2025, 406-407,414)

These advanced architectures show the significance of transitioning from CDNs as passive content repositories to active intelligent delivery platforms.

4 Edge Computing for Web Applications

While Content Delivery Networks have successfully decentralized the storage of static assets, the modern web requires the decentralization of application logic. Edge computing addresses this by shifting computational tasks from centralized cloud data centers to the edge of the network, closer to the end-user.

4.1 Definition and Operational Principle

Edge computing is defined as a distributed computing structure that brings computation and data storage closer to the location where it is needed, and therefore improves response times and saves bandwidth (Fazil et al., 2025, p. 1). Contrary to traditional cloud computing, where data is transmitted to distant data centers for processing, edge computing uses resources at the edge of the network, e.g. base stations, routers or micro data centers to execute application logic (Cao et al., 2020, p. 85715) (Varghese et al., 2016, p. 20). In the specific context of web applications, it is often defined as Serverless Edge Computing. Here, developers deploy event-driven functions (Function-as-a-Service or FaaS) that run on edge nodes (Batool and Kanwal, 2025, p. 1). Platforms like AWS Lambda@Edge or Cloudflare Workers enable the execution of these functions in response to events (e.g. HTTPS requests) directly at edge nodes (Javed et al., 2021, p. 7-8) (Siidorow, 2024, p. 16,19-20). The serverless model on the edge is especially helpful for web applications, because it reduces the need for always-on servers, instead starting up containers only when requests occur, which optimizes resource usage and costs (Javed et al., 2021, p. 2)

4.2 Key Benefits: Latency, Bandwidth and Real-Time Processing

As already stated, the primary advantage of using edge computing in web development is the necessity to overcome the physical limitations of centralized cloud architecture.

• Latency Reduction:
  By processing requests at the edge, the round-trip time (RTT) to the origin server is significantly reduced (Fazil et al., 2025, p. 1) (Varghese et al., 2016, p. 21). Research shows that in real-time applications such as gaming or augmented reality using a distant cloud poses serious latency problems due to geographical location (Varghese et al., 2016, p. 21).
• Bandwidth Efficiency:
  Edge computing takes a lot of load off the central server infrastructure by processing data locally. Instead of transmitting lots of raw data to the cloud, edge nodes can filter, aggregate, or compress data and forward only relevant data to the central infrastructure (Varghese et al., 2016, p. 21). This is especially critical for bandwidthheavy content like video streaming or Augmented and Virtual Reality applications where a lot of congestion can be prevented by processing on the edge of the network (Gupta, 2024, p. 3).
• Real-Time Capabilities:
  Because edge computing is close to the data source, it can process information with much lower delay. This reduced transmission time enables realtime responses for the user and supports fast, context-aware decisions in web applications. (Fazil et al., 2025, p. 1-2)

4.3 Beyond the CDN: From Caching to Computing

Traditionally, Content Delivery Networks focused on caching static assets to reduce latency and origin server load (Vepsäläinen et al., 2023, p. 1) (Tyagi, 2025, p. 401-402). Edge computing evolves this model by transforming edge nodes from passive caches into active execution environments used to process dynamic content (Vepsäläinen et al., 2023, p. 4) (Tyagi, 2025, p. 411). This shift enables programmable capabilities where data analysis, security filtering and content generation happen at the edge of the network (Tyagi, 2025, p. 411) (Cao et al., 2020, p. 85715). Therefore, web applications can implement dynamic rendering strategies like server-side rendering (SSR) or incremental static generation (ISR), directly at the edge to optimize the Quality of Experience (QoE) for the end-user (Vepsäläinen et al., 2023, p. 1,3,5).

4.4 Edge Functions and Runtimes

Edge logic is primarily implemented via Serverless Edge Computing or Function-as-a-Service (FaaS), which allows developers to deploy stateless functions without infrastructure management (Batool and Kanwal, 2025, p. 1-2). The runtimes used generally fall into two categories:

• MicroVM-based:
  Architectures like AWS Lambda@Edge utilize lightweight virtualization (e.g. Firecracker) to provide isolation and broad language support, though they can struggle with “cold start” latencies when initialized (Siidorow, 2024, p. 16-17).
• Isolate-based:
  Platforms like Cloudflare Workers or Deno Deploy use V8 isolates to run multiple functions within a single process. In this approach “cold starts” are eliminated and it reduces memory usage, but it is typically restricted to JavaScript and WebAssembly environments (Siidorow, 2024, p. 22-23,27-28)

These runtimes enable developers to execute custom code directly at the network periphery, allowing them to shape client requests and server responses, providing faster response times and new possibilities (Vepsäläinen et al., 2023, p. 1).

1. Dynamic Request Manipulation:
   Functions can dynamically assemble web pages or tailor content in real-time based on the user’s location or device type, rather than serving generic static resources (Gupta, 2024, p. 8).
2. Media Optimization:
   Edge functions can perform on-thefly transformations of media assets, such as resizing, cropping or formatting images and videos to match the capabilities of the requesting device (Gupta, 2024, p. 8).
3. Security and Access Control:
   Complex access control logic can be implemented directly at the edge to allow the system to validate requests without long round trips to the origin server (Gupta, 2024, p. 8).
4. Real-Time AI Inference:
   Edge nodes are capable of running lightweight AI models to perform tasks such as realtime content analysis, automated content moderation, or media analytics closer to the end-user. (Gupta, 2024, p. 5)

4.5 Challenges and Limitations

Deploying web applications at the edge of the network can introduce challenges compared to using a centralized cloud.

1. Resource Constraints:
   Edge nodes often possess limited computational power and memory compared to cloud data centers. Therefore, highly efficient algorithms and effective resource scheduling are needed (Batool and Kanwal, 2025, p. 14).
2. State Management:
   Connecting to centralized databases from the edge can reintroduce latency due to the round-trip time required for queries. While data replication to the edge may be a solution, it introduces risks regarding data consistency and “replication lag”, making it difficult to maintain a synchronized state across all nodes for real-time applications. (Siidorow, 2024, p. 29)
3. Security:
   Since Edge Functions are usually limited to a small scope and need fewer privileges, they often have a significantly reduced attack surface compared to full applications in containerized or virtual environments (Siidorow, 2024, p. 28)
4. Cold Starts:
   Cold starts may occur when a certain edge function is not used for a longer time. Depending on the runtime, cold starts can present a significant problem by causing delays during complex workloads such as AI functions, which negate the latency benefit of edge functions if they take longer than the original round trip time to the data center (Siidorow, 2024, p. 27)

5 Conclusion

This work demonstrates how edge computing builds upon the concepts of traditional content delivery networks (CDNs) to overcome the latency and bandwidth limitations of centralized cloud architectures. Modern web-based systems depend on real-time interaction, rich media, and personalization. In such scenarios, long network paths to distant data centers can quickly slow down applications. CDNs reduce this issue by caching static content at the edge; meanwhile, edge computing builds on this model by running parts of the application logic on servers close to the user. For web applications, this shift enables faster handling of requests, more responsive dynamic content and an improved quality of experience, particularly on mobile devices or in scenarios that require a lot of bandwidth. However, serverless edge platforms also introduce new challenges. Edge nodes have limited computing and memory resources, and coordinating distributed state is more challenging. Cold starts and heterogeneous runtimes can further reduce performance if not managed effectively. Overall, current research indicates that the cloud and the edge should be used together. Content Delivery Networks (CDNs) and serverless edge platforms handle latency-sensitive tasks near the user, while centralized cloud systems remain important for computationintensive workloads and long-term data storage. In the future, CDN and edge strategies will become increasingly prominent, as realtime services, IoT deployments, and rich media applications continue to grow and push performance requirements beyond what centralized cloud architectures can reliably provide.

Acknowledgments

Parts of the wording of this manuscript were supported by generative AI tools for language editing. All scientific content, structure
and conclusions were created and verified by the author.

References

1. Iqra Batool and Sania Kanwal. 2025. Serverless Edge Computing: A Taxonomy, Systematic Literature Review, Current Trends and Research Challenges.
   arXiv:2502.15775 [cs.NI] https://arxiv.org/abs/2502.15775
2. Keyan Cao, Yefan Liu, Gongjie Meng, and Qimeng Sun. 2020. An Overview on Edge
   Computing Research. IEEE Access 8 (2020), 85714–85728. doi:10.1109/ACCESS.2020.
   2991734
3. Yunqi Dong, Jiujun Bai, and Xuebo Chen. 2020. A Review of Edge Computing Nodes Based on the Internet of Things. In Proceedings of the 5th International Conference on Internet of Things, Big Data and Security (IoTBDS). 313–320.
   doi:10.5220/0009407003130320
4. A. W. Fazil, A. Ghairat, and A. J. Kohistani. 2025. Advancing Web-Based Information
   Systems Performance via Edge Computing: A Comprehensive Systematic Review.
   GAME 2, 4 (2025), 1–20. doi:10.29103/game.v2i4.24189
5. Ragini Gupta, Claudiu Danilov, Josh Eckhardt, Keyshla Bernard, and Klara Nahrstedt.
   2025. Characterizing Container Performance in Edge Computing. In Proceedings of
   the ACM SIGCOMM 2025 Posters and Demos (Coimbra, Portugal) (ACM SIGCOMM
   Posters and Demos ’25). Association for Computing Machinery, New York, NY, USA,
   94–96. doi:10.1145/3744969.3748438
6. Sachin Gupta. 2024. Enhancing Content Delivery with Edge Computing in Media and
   Entertainment. Zenodo. doi:10.5281/zenodo.13933556
7. Hamza Javed, Adel N. Toosi, and Mohammad S. Aslanpour. 2021. Serverless Platforms
   on the Edge: A Performance Analysis. arXiv:2111.06563 [cs.DC] https://arxiv.org/
   abs/2111.06563
8. Mikael Siidorow. 2024. Survey of Serverless Edge Computing for Web Applications.
   doi:10.13140/RG.2.2.13600.39680
9. Anuj Tyagi. 2025. Optimizing digital experiences with content delivery networks:
   Architectures, performance strategies, and future trends. World Journal of Advanced
   Research and Reviews 7, 2 (01 2025), 401–417. doi:10.30574/wjarr.2020.7.2.0230
10. Blesson Varghese, Nan Wang, Sakil Barbhuiya, Peter Kilpatrick, and Dimitrios
    Nikolopoulos. 2016. Challenges and Opportunities in Edge Computing. In
    2016 IEEE International Conference on Smart Cloud (SmartCloud). IEEE, 20–26.
    doi:10.1109/SmartCloud.2016.18
11. Juho Vepsäläinen, Arto Hellas, and Petri Vuorimaa. 2023. Implications of Edge Computing for Static Site Generation. arXiv:2309.05669 [cs.HC] https://arxiv.org/abs/
    2309.05669
12. Yuhan Zhao, Wei Zhang, Longquan Zhou, and Wenpeng Cao. 2021. A Survey on
    Caching in Mobile Edge Computing. Wireless Communications and Mobile Computing 2021 (2021), 1–21. doi:10.1155/2021/5565648

The post SOTA | Edge Computing for Web Applications appeared first on Mobile USTP MKL.

Working in event management and also as staff during some of Austria’s biggest festivals, you start noticing some problems when it comes to registration of your clients: The company I currently work with (Adrenalin Company) specialises in the renting and operation high-thrill event tools that have certain risks associated to them in the event of misuse. Therefore, participants are required to sign so called liability exclusion disclaimers before attending.

The problem

Solution

Clients can read the liability exclusion disclaimer and sign it easily using their smartphone. Not only does this reduce the need for printed forms, but it also allows all participants to sign simultaneously, reducing overall wait time. After filling out and submitting the form, the participants are given a personalised QR-code that contains all the relevant information for us organisers.

Future

In future versions of this tool, the website would display the information in the system-used language, making it more accessible. The submitted information would be stored securely on a dedicated server for the legally required duration. On the other hand, there is a need to develop a specialised QR-code scanner application, that can read the participants codes and cross check them with the database in order to check their validity.

All in all, a user would first scan the QR-code on the poster and read, sign and submit the disclaimer. Then they would go to the event booth, where a staff member would scan each participant’s personalised code to verify its validity before they can enjoy the attraction.

Disclaimer: This project is not associated with BAGJUMP in any way. It is a purely academic student project, created for educational purposes only.

Link to the website: https://karavam.github.io/QR-Code-Website/

The post Print2Mobile Event registration tool appeared first on Mobile USTP MKL.