For Swiva, we decided to keep some of these tasks out of our main backend and move them closer to the user, to the edge. In our case, this means using Cloudflare Workers. A Worker is a small serverless function that runs on Cloudflare’s global network, close to the user. It can handle a request, run a bit of JavaScript or TypeScript and return a response without needing our main backend at all.

That makes Workers a good fit for small features that need to be fast, but do not need a full backend route, database connection or heavy infrastructure.

The problem with app store redirects

A simple example is our app download link. When someone scans a QR code on a poster, sticker or social media post, they should end up in the right place. iPhone users should go to the Apple App Store, Android users should go to Google Play and desktop users should go to our website.

The normal solution would be to send everyone to a page on our website. The page loads, JavaScript runs in the browser, checks the device and then redirects the user. That works, but it is not ideal. The user may see a blank page or a short loading screen before the store opens. For an app download link, every small delay matters.

A smart redirect at the edge

Instead of loading a full page, we use a Cloudflare Worker. The Worker runs before the request even reaches our main server. It checks the user agent from the HTTP request, decides if the user is on iOS, Android or desktop and immediately returns a 302 redirect. So the QR code does not point to a heavy website. It points to a tiny edge function.

A simplified version can look like this:

export default {
  async fetch(request, env, ctx) {
    const userAgent = request.headers.get("user-agent") || "";

    const isIOS = /iPhone|iPad|iPod/i.test(userAgent);
    const isAndroid = /Android/i.test(userAgent);

    const targets = {
      ios: "https://apps.apple.com/at/app/swiva/id6769160022",
      android: "https://play.google.com/store/apps/details?id=app.swiva",
      desktop: "https://swiva.app",
      fallback: "https://swiva.app",
    };

    let platform = "fallback";

    if (isIOS) {
      platform = "ios";
    } else if (isAndroid) {
      platform = "android";
    } else {
      platform = "desktop";
    }

    return Response.redirect(targets[platform], 302);
  },
};

This is not a huge feature. But it solves a real problem in a very clean way.

Tracking without a heavy analytics script

We also want to know where our downloads come from. A QR code on a poster, a link in a story and a link on a website should not all look the same. Instead of loading a full analytics script, the Worker can read a source parameter from the URL, add UTM parameters to the final link and count the redirect in Cloudflare KV. The important part is that this should not slow down the redirect. For that, we use ctx.waitUntil().

const source =
  url.searchParams.get("src") ||
  url.searchParams.get("source") ||
  "direct";

targetUrl.searchParams.set("utm_source", source);
targetUrl.searchParams.set("utm_medium", "smart_redirect");
targetUrl.searchParams.set("utm_campaign", "app_download");

if (env.DOWNLOAD_LINK_REDIRECT_STATS) {
  const today = new Date().toISOString().split("T")[0];
  const key = `${today}:${source}:${platform}`;

  ctx.waitUntil(
    (async () => {
      const currentCount =
        (await env.DOWNLOAD_LINK_REDIRECT_STATS.get(key)) || "0";

      await env.DOWNLOAD_LINK_REDIRECT_STATS.put(
        key,
        (parseInt(currentCount) + 1).toString()
      );
    })()
  );
}

The redirect is sent back immediately. The statistic update happens in the background. That is exactly the kind of small task where edge functions feel perfect.

Why this works well for Swiva

This setup works well because each Cloudflare product has a clear job. Our marketing website runs on Cloudflare Pages, which is made for hosting static websites and frontend projects. This is enough for a lightweight app landing page like swiva.app and keeps the website separate from the redirect logic.

The redirect itself runs as a Cloudflare Worker, because it needs to be fast and should happen before a full website loads. For simple tracking, we use Cloudflare KV. KV is a key value store, so we can save small pieces of data with a key, for example how often a specific QR code source was used on a specific day.

This gives us lightweight redirect tracking without setting up a full database or adding a big analytics tool. For this kind of use case, the free limits are more than enough. Cloudflare Workers currently include 100,000 requests per day on the Free plan, which is a lot for a smart redirect service.

Try it yourself

You can test the redirect yourself using this link or by scanning the QR code.

If you scan it with an iPhone, it should open the Apple App Store. If you scan it with an Android device, it should open Google Play. If you click the same link on a desktop device, it should redirect you to the Swiva landing page.

That is the nice part about this setup: one QR code can work for every platform, without loading a full website first.

Open the Swiva smart redirect

The post Microservices at the Edge: Why We Use Cloudflare Workers for swiva.app appeared first on Mobile USTP MKL.

This project was especially interesting for me because my father works at the company, which gave me a closer connection to both the business and its challenges.

Why This Project?

You might be wondering why I suddenly included this project among my master’s projects.

The answer is quite simple. The company had received very few customer inquiries in recent months. During trade fairs and exhibitions, potential customers often mentioned that they could not find the company online. After taking a closer look, it became clear why.

The existing website had several issues. It suffered from poor performance, weak SEO, and limited accessibility. Important legal pages such as the imprint and privacy policy were also incomplete and contained errors. Overall, the website did not represent the quality of the company and its products.

Because of this, I offered my support and took on the challenge of creating a new website from scratch.

Project Scope

One of the biggest problems with the old website was that it had been developed entirely in React. While this worked from a technical perspective, it made content management almost impossible for non-technical employees.

The company wanted a website that they could update themselves. They wanted to be able to change texts, upload images, and maintain content without needing programming knowledge every time.

This became one of the main goals of the project.

Core Features

Before starting the design and development process, I spoke with the client to understand what they needed from their new website.

Of course, the products had to be presented clearly. Beyond that, they wanted customer reviews, information about partners, a contact form, and an overall more modern appearance.

My personal focus was on creating a website that performs well in areas that are essential today: responsive design, SEO, and accessibility. A website should not only look good, it should also be easy to find and easy to use on all devices.

Since the company had almost no digital presence beyond its website, I also created a Google Business Profile and set up Google Analytics to help them understand and improve their online visibility in the future.

Design, Tools, and Technologies

The design process started in Figma. The client requested a visual style inspired by water and waves to reflect the company’s connection to flood protection.

At the same time, I wanted to keep the design clean and professional. The target audience is mostly businesses and homeowners looking for reliable protection solutions, so the website needed to maintain a strong industrial and trustworthy feel.

To make content management easier for the company, I decided to build the website with WordPress instead of creating another fully custom solution. This allows employees to manage content themselves without needing technical knowledge.

To customize the website and provide all required functionality, I researched, installed, and configured several WordPress plugins that support performance, SEO, security, forms, and content management.

What I Learned

This was the first time I created an entire website completely from scratch.

I was involved in every step of the process, from researching hosting options and planning the structure to designing the interface, setting up WordPress, configuring plugins, creating the Google Business Profile, and integrating Google Analytics.

On top of that, I made sure the website worked well on different screen sizes and followed SEO and accessibility best practices.

The project was definitely time-consuming, but it taught me a lot. I gained a much better understanding of how many different areas come together when building a professional website. It was not only about design or development, but also about planning, communication, marketing, and long-term maintainability.

Conclusion and Future Steps

At the moment, the project is not completely finished yet. I am currently waiting for feedback from the company, and some final content such as photos and text material is still missing.

Once these assets are available, I will make the final adjustments, complete the remaining content, and submit the website for indexing so it can be found through search engines.

After that, the company will finally have a modern web presence that better reflects its expertise and helps potential customers find its services online.

Check It Out Soon

The new website will soon be available at:

https://www.rkz-design.gmbh

Feel free to take a look once it goes live.

The post PROJECT | Building a New Website for RKZ Metall Design GmbH appeared first on Mobile USTP MKL.

One feature we had planned for a longer time was sharing links directly into the app. For example, a user sees a recipe on Instagram, a restaurant on Google Maps or an activity on TikTok and shares the link to Swiva. The app should then create a useful activity from that link, with a title and a short description.

At first, I thought the main challenge would be the AI part. But during the project I realized that a much bigger part was actually getting good information from the shared links.

The real problem: getting the content

Before the AI can generate a good activity, the app needs useful input. For that, I used two general strategies and one special case.

The first strategy is Open Graph metadata. This is the information many websites use for link previews, for example when a link is shared in WhatsApp. It often contains a title, description and image, which can already be enough to understand the basic content of a post or website.

The second strategy is oEmbed. This is used by platforms like TikTok to provide information for embedded content. In some cases, this gives better structured data than normal page metadata.

Google Maps was more difficult. The official APIs are based on place IDs and structured requests, not just random shared Maps links. Also, Google has strict rules around scraping. Because of that, I did not scrape the page directly. Instead, I tried to resolve the link and extract the place name from the final URL when possible.

I also decided to send these metadata requests from the app instead of my backend. If the app scales, I do not want my server to send too many requests to platforms like Instagram or TikTok and risk rate limits or IP bans. Sending them from the app distributes this better and keeps the backend simpler.

On-device AI and fallback

For iOS, I used the Callstack React Native AI package with Apple’s on-device AI capabilities. This worked well and was quite easy to use, because the API is based on the Vercel AI SDK.

My original plan was to also use Google ML Kit GenAI for Android. But the support I wanted in the React Native AI package was not available yet, and I did not want to build a custom Expo module just for this. Since I had already proven the on-device concept with Apple, I used a cloud fallback for Android and unsupported devices.

The fallback sends a request to my backend, which uses a Gemini Flash-Lite model to generate the activity. At first I used Gemini 2.5 Flash-Lite, where the results were comparable to Apple’s on-device model. Later I tested Gemini 3.1 Flash-Lite, and I was much happier with the generated titles and descriptions.

What I learned

My original goal was to compare on-device AI and cloud AI and see if the quality could be similar. I did not fully reach that goal, because the newer cloud model gave better results for my use case.

Still, the project was a useful experiment. I learned how to use Apple on-device AI in a React Native app, how to build a fallback strategy and how important link metadata is for this feature.

For Swiva, I currently think that one cloud strategy is probably the easiest solution to maintain. Gemini Flash-Lite is cheap enough for this use case, the results are more consistent across devices, and the architecture is simpler than maintaining separate strategies for iOS, Android and fallback.

On-device AI is still very interesting, especially for privacy, offline usage and reducing server costs. But in this case, the simplest and most stable solution might be the best one

Check out the feature by downloading Swiva here: https://swiva.app/download

Sources

• Callstack React Native AI: https://github.com/callstackincubator/ai
• Google ML Kit GenAI APIs: https://developers.google.com/ml-kit/genai
• Open Graph Protocol: https://ogp.me/
• TikTok oEmbed / Embed Documentation: https://developers.tiktok.com/doc/embed-videos/
• Google Maps Place Details API: https://developers.google.com/maps/documentation/places/web-service/place-details
• Gemini API Pricing: https://ai.google.dev/gemini-api/docs/pricing

The post Smart Import Feature for my app “Swiva” appeared first on Mobile USTP MKL.

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

What is Agent Device?

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

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

Why performance testing?

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

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

My setup

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

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

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

Why this is useful

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

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

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

What I learned

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

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

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

Final thoughts

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

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

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

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.