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.

My idea was to create a virtual museum that can be accessed via QR codes printed on ads displayed directly in the stations. This way, people can learn about the station’s history while waiting for the train, riding it, or exploring the station. The aim is to make the project appealing not only to tourists but also to locals.

For my poster and prototype, I chose Karlsplatz Station as an example because it has a fascinating history and is notoriously difficult to navigate due to its many levels and countless exits.

The slogan on the poster plays with the phrase “finding out”, which not only refers to literally finding a way out of the complex passages and levels of Karlsplatz, but also to discovering the station’s history. The language is English because many tourists pass through Karlsplatz every day. When the campaign is implemented for other stations, such as Seestadt, which is mainly used by locals, a German version of the poster would make more sense. This particular poster could be displayed not only on the platforms but also near the exits, as the advertisement directly references that scenario.

After scanning the QR code, the content page for Karlsplatz opens. It contains four paragraphs focusing on the history, construction, and current role of Karlsplatz, supported by relevant images. There is also an option to listen to the content, the audio version should not exceed five minutes to keep the information concise and engaging. The language can be changed as well.

If you’re interested in the history of other stations, you can visit the station overview and search for them. There is also a map where you can check out your surroundings and nearby stations. In the “More” section, there could be items such as the imprint, data policies, contact information, or links to other services and apps provided by the City of Vienna.

This Project is just a concept and not affiliated with Wiener Linien in any way. It is a purely academic student project, created for educational purposes only. No financial support, sponsorship, or compensation has been received from Wiener Linien or any other company. Any use of names or logos is solely for demonstration purposes within the prototype.

Sources:

• Person auf dem Poster: Foto von Nathan Dumlao auf Unsplash
• Karlsplatzbild: Foto von Shery Arturova auf Unsplash
• Karte von https://www.openstreetmap.org/#map=15/48.18031/16.36414
• Baustelle Karlsplatz Bild: https://newsv2.orf.at/stories/2424487/2425558/
• United kingdom icons created by Freepik – Flaticon: https://www.flaticon.com/free-icons/united-kingdom

The post Print2Mobile | TrackBack Vienna – Get to know Viennas Subway System (Print2Mobile Project) appeared first on Mobile USTP MKL.

We’ve all been there, standing in front of the fridge or in the supermarket aisle not knowing what to cook. Meanwhile, tons of perfectly good food end up in the trash every day.

Dishcovery not only inspires creativity in the kitchen — it makes sustainability simple, digital, and rewarding.

This project is not affiliated with BILLA or the REWE Group in any way. It is a purely academic student project, created for educational purposes only. No financial support, sponsorship, or compensation has been received from BILLA or any other company. Any use of names or logos is solely for demonstration purposes within the prototype.

iPhone design by Luis Orea
Icons designed by Kryston Schwarze https://coolicons.cool/
Illustrations/Icons designed by Freepick www.freepik.com

The post Print2Mobile | Dishcovery appeared first on Mobile USTP MKL.

Nativescript – eine kurze Vorstellung

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

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

Von einer Web-App zu einer nativen App

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

Optimierter Suchalgorithmus

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

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

Die “Signature”-Drinks

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

Weitere Features/Verbesserungen

Redesign

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

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

Zutaten Suchfunktion

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

Herausforderungen im Entwicklungsprozess

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

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

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

Resümee mit Ausblick

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

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

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

Beitragsbild: dieses wurde mittels Einsatz von KI erzeugt

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

In diesem Beitrag möchte ich den Aufbau der Anwendung, die verwendeten Technologien sowie einige Herausforderungen und Learnings während der Umsetzung vorstellen.

Technologie-Stack

Das Club Dashboard wurde als moderne Webanwendung mit Fokus auf Skalierbarkeit, Sicherheit und einfache Erweiterbarkeit entwickelt.
Hier ein Überblick über die zentralen Technologien:

Framework: Next.js (App Router)

Für das Frontend kam Next.js mit dem neuen App Router zum Einsatz. Diese Architektur erlaubt serverseitiges Rendering (SSR), API-Routen und eine saubere Trennung von Client- und Server-Komponenten. Dadurch konnte ich sowohl UI-Logik als auch Backend-Funktionalität innerhalb eines Frameworks umsetzen.

Vorteile:

• Serverseitiges Rendering für bessere Performance und SEO
• Integrierte API-Routen für serverseitige Logik (z. B. Payment Handling)
• Moderne Struktur durch den App Router

Data Layer: Convex

Anstatt einer klassischen REST- oder GraphQL-API habe ich mich für Convex entschieden – eine innovative Backend-as-a-Service-Lösung, die reaktive Datenabfragen, serverseitige Funktionen und Auth-Integration out of the box bietet.

Convex ermöglicht es, Daten- und Serverlogik in TypeScript zu schreiben und nahtlos mit dem Frontend zu verbinden. Dadurch entfällt ein Großteil der sonst notwendigen API- und Datenbankkonfiguration.

Styling & UI: TailwindCSS & shadcn

Für das Styling habe ich auf TailwindCSS gesetzt – ein Utility-First-CSS-Framework, das schnelles Prototyping und einheitliches Design ermöglicht.
Zusätzlich kam shadcn zum Einsatz, eine leichtgewichtige Component Library mit Fokus auf Barrierefreiheit, Dark Mode und Customizability.

Vorteile dieser Kombination:

• Konsistentes UI mit klarer Design-Sprache
• Wiederverwendbare Komponenten
• Effiziente Entwicklung durch Utility-Klassen
• Code Ownership: Components werden einfach ins Projekt kopiert

Authentifizierung: Clerk

Die Authentifizierung wird durch Clerk umgesetzt – denselben Anbieter, den ich bereits im ersten Semesterprojekt genutzt habe. Clerk bietet ein modernes User Management inklusive OAuth-Integration und JWT-Handling, was eine einfache Verbindung mit Convex und Next.js ermöglicht.

Durch Clerk konnte ich schnell eine sichere Login-, Logout- und Session-Logik aufsetzen, ohne selbst komplexe Authentifizierungssysteme implementieren zu müssen.

Payment Provider: Stripe

Ein zentrales Feature dieses Projekts war die Integration von Stripe als Payment Provider. Nutzer:innen können direkt über die Website eine Skiausfahrt buchen und bezahlen.
Dazu wurde das Stripe Checkout-System in die App eingebunden – inklusive Webhook-Handling, um Payment-Status-Änderungen serverseitig zu verarbeiten.

Beispielhafte Flows:

• User wählt eine Ausfahrt aus → Klick auf „Buchen“
• Stripe Checkout öffnet sich → Zahlung erfolgt
• Stripe sendet einen Webhook an das System → Buchung wird bestätigt und gespeichert

Diese End-to-End-Integration war der Kern des Projekts und erforderte ein gutes Zusammenspiel zwischen Frontend, Convex Backend und Stripe Webhooks.

Kommunikation & Webhooks

Ein spannender Teil des Projekts war die Kommunikation zwischen den verschiedenen Systemen.
Sowohl Stripe als auch Clerk arbeiten mit Webhooks, um Echtzeit-Informationen an das System zu senden (z. B. erfolgreiche Zahlungen oder neue Benutzer).
Die Webhooks werden über API-Routen in Next.js empfangen und anschließend in Convex weiterverarbeitet – beispielsweise um Buchungsdaten zu aktualisieren oder Rechnungen zu speichern.

Herausforderungen & Learnings

Während der Entwicklung gab es mehrere interessante Herausforderungen:

• Webhook-Handling: Das Zusammenspiel von Stripe, Clerk und Convex erfordert saubere Trennung von Sicherheits- und Logikschichten. Insbesondere das Validieren von Webhook-Signaturen war anfänglich fehleranfällig.
• Datenmodellierung in Convex: Da Convex ein eigenes Datenmodell nutzt, war es notwendig, sich in dessen Schema-System einzuarbeiten.
• SSR + Client-Komponenten: Der Wechsel zwischen Server- und Client-Komponenten im Next.js App Router war zunächst ungewohnt und erforderte ein gutes Verständnis des Rendering-Modells.

Trotz dieser Hürden war die Entwicklung äußerst lehrreich – vor allem im Hinblick auf Payment-Flows, Security und API-Kommunikation.

Fazit

Das Club Dashboard war ein spannendes Projekt, das mir erstmals die Umsetzung einer vollständigen End-to-End-Integration mit Stripe ermöglicht hat.
Durch den Einsatz moderner Tools wie Next.js, Convex, Clerk und Stripe konnte ich einen funktionalen MVP umsetzen, der reale Buchungsprozesse abbildet.

Besonders interessant war zu sehen, wie gut sich die verschiedenen Services über Webhooks und API-Routen integrieren lassen – und wie wichtig saubere Datenflüsse und Sicherheit in einem Payment-System sind.

Im nächsten Schritt plane ich, das Dashboard um weitere Funktionalitäten zu erweitern, um einem produktionsreifen Produkt näher zu kommen, das sich veröffentlichen und vertreiben lässt.

Screenshots

The post Projekt | Powda Club-Dashboard appeared first on Mobile USTP MKL.

This tool makes it easy to convert photos of your recipes into a machine-readable format.

The output format is a subset of the schema.org Recipe and can be expanded (merge request are welcome).

How it works

The Recipe Scanner is a web application built with the Nuxt framework. Through its user interface, you can upload photos of recipes, which are stored on the server. The server then sends the images, along with a prompt, to a vision Large Language Model (LLM). The LLM extracts the relevant recipe information and formats it as specified. Finally, the server validates the structure of the returned data and sends it back to the client.

Technical considerations

This application was created for personal use (I wanted to digitize many old and messy recipes from my school days) and for experimentation so it is not designed to be fully “production-ready.” This influenced some of my technical choices.

For instance, I wanted to try out running a vision LLM on my own machine instead of using a hosted service. I tried out Ollama and LM Studio and opted for the latter because its interface made managing connections easier. In principle, Ollama should also work.

I also tried out several models. I began with the smalles vision-enabled Gemma 3 model (4B parameters, 3.3 GB). Unfortunately, it made many errors when extracting recipe data. Hosted models such as ChatGPT-5 and Mistral (Large?) performed much better, proving the task was feasible for LLMs. Among open-weight models, Mistral Small 3.2 (24B parameters, 15 GB) was the first that consistently produced accurate results. It’s possible that bigger Gemma 3 models (e.g., 12B) or specialized models like LLaVA, could also perform well or even better. If you test them, I’d be interested in hearing your results.

Another unusual design choice is how persistence is handled. Since this is a personal project, I opted for simplicity. The server does not use a database. There are no user accounts and images and parsed recipe data are saved directly to the server’s file system. To simulate a multi-user experience, each user only sees their own recipes. This is managed on the client side by storing image IDs in the browser’s IndexedDB. IndexedDB is not the ideal tool for this, but I wanted to experiment with it.

Next steps

My immediate goal is to digitize my collection of printed and handwritten recipes. Once that data is gathered, I plan to use both the images and extracted recipe information to fine-tune a smaller, more efficient model specifically optimized for this task.

Link to the repository: https://github.com/realJanWeiss/recipe-scanner

The post Projekt | Recipe Scanner appeared first on Mobile USTP MKL.

Features

• Scan QR codes using your MacBook’s built-in camera
• Keep a searchable history of scanned codes
• Enhanced support for:
  • Website links (open directly in your browser)
  • Contact data in vCard format

Future versions may include more data types — contributions are welcome!

How It Works

Simply launch the app, point your MacBook’s camera at a QR code, and the app will recognize it instantly. Your scans are stored in your history so you can revisit them at any time.

Contributing

If you’d like to add support for additional QR code data types:

1. Implement a new HistoryItemData
2. Add it to QRCodeUtils.historyItemDataFromQRCode
3. Create a view that extends HistoryItemViewBase
4. Integrate your view into HistoryItemView

We welcome pull requests and improvements from the community.

Development

The application is written in Swift and uses SwiftUI and only native packages. To run the project locally:

1. Clone the repository
2. Open the project in Xcode
3. Build and run

That’s it — you’re ready to go!

Other thoughts

A long time ago, I learned a bit of JavaFX and Swing. Since then, I have been working on web projects and mainly developing user interfaces with the frontend framework Vue, though I am also familiar with Angular and React. With this background, I was excited to write my first native macOS application.

What surprised me immediately was how easy it was to create and style UI components. With very little code, I was able to build attractive layouts, apply colors (also supporting dark mode!), add shadows, and even implement subtle animations. Coming from a web-development background, I had mixed feelings about the lack of separation between templates and styles that I observed in the code examples online. The code I saw (and wrote) was essentially equivalent to defining CSS rules directly in an element’s style attribute. I’m sure there are cleaner approaches that I have yet to discover.

Another interesting aspect of the macOS development ecosystem is the simplicity and richness of the system APIs. Want to save a contact to the OS’s contact book or detect a QR code? There is a native package that can be imported with a single line, usually just two words (e.g., import Vision). In general, importing code is very straightforward, and code inside a module is automatically available everywhere. This simplicity does have a downside: it can make it less clear where a piece of code comes from and how different units are related.

While developing data classes to represent various scanned QR code data formats, I encountered an unpleasant aspect of Swift. I needed classes to represent scanned QR codes containing plain data, contact information, or website links. All QR code entries share certain properties, such as the date they were scanned or had to implement a certain method. I initially wanted to capture this relationship with an abstract class, (e.g., HistoryItem being extended by a ContactHistoryItem).

The first thing I discovered was that Swift does not have abstract classes; instead, it uses protocols, which worked fine for my use case. However, I then found that I could not use my protocol as a type for collections. I also tried created a generic HistoryItem holding a ContactHistoryItemData implementing the HistoryItemData protocol. But this also didn’t work. The common Swift approach seems to be a wrapper class to erase the type. As a result, I ended up with a HistoryItem holding an AnyHistoryItemData that contains an object conforming to the HistoryItemData protocol. Having to implement type erasure instead of using generics felt somewhat unsatisfying and slightly clouded my impression of the language.

If I am missing any important details, please let me know! I am looking forward to your feedback and hope to learn some tricks for designing Swift code more effectively and elegantly.

Link to the repository: github.com/realJanWeiss/QR-reader-for-Mac

The post Projekt | QR Reader for Mac appeared first on Mobile USTP MKL.