DEV Community: Piotr Ładoński

Spotify Connect, Raspberry Pi, AirPlay & HomePod - because simple audio setups are boring

Piotr Ładoński — Sun, 14 Dec 2025 21:39:00 +0000

I could write a whole long introduction of why I needed to stream Spotify from my Raspberry Pi to HomePod Mini speaker, how I arrived at the final idea, how I was hitting constant problems with other solutions... but if you're reading this, I guess you are way more interested in the actual setup 🙂 So let's just put it very briefly:

My problem:

AirPlay drains phone battery fast, but it's the only option for playing Spotify on HomePod Mini. How can I AirPlay music to HomePod, but not from the phone... and still control it from the phone?

Solution:

Raspberry Pi & Spotify Connect to the rescue! Make the Raspberry Pi the playing device and control it from the phone via Spotify Connect

The tricky part... was the actual execution. It took me a significant amount of time, caused quite some frustration with solutions that didn't work, and, finally, I had to take bits from several of them to make things work. In the end, if you know what to do, it's not hard, but... you must know what to do 🙂 I'll do my best to explain the process as clearly as possible, so here we go!

General idea for Raspberry setup

Basics: I'm using Raspberry Pi 5 and the newest Raspbian based on Debian 13 (Trixie).

There are two main things that RPi must do

become a Spotify Connect device and
stream audio via AirPlay to the HomePod

Luckily, it's nothing innovative, and there are already plenty of existing solutions for both things. However, there are actually so many that you can spend a lot of time trying to combine them and get nowhere. My silver bullets turned out to be

Raspotify - turning RPi into a Spotify Connect device
Owntone - AirPlay-ing to the speaker

And, one secret ingredient that glues them together - Linux named pipes.

Oh, and a very important detail - Spotify Premium. Raspotify doesn't work with free accounts.

Installing things

That's probably optional, but I'd start with a good old package upgrade:

sudo apt update && sudo apt upgrade

Why probably? Because I've run it and haven't checked if things would work without the system-wide package upgrade 🙂

Raspotify

That's super easy. As the docs mention, just run

sudo apt-get -y install curl && curl -sL https://dtcooper.github.io/raspotify/install.sh | sh

and that's it. Raspotify will be installed & started. You can verify it with

systemctl status raspotify

It should also already appear as a Spotify Connect device.
Remember, your phone, Raspberry, and HomePod need to be on the same network!

Owntone

You can follow the steps from the forum post, or just trust me that I copied everything correctly and run

wget -q -O - https://raw.githubusercontent.com/owntone/owntone-apt/refs/heads/master/repo/rpi/owntone.gpg | sudo gpg --dearmor --output /usr/share/keyrings/owntone-archive-keyring.gpg && sudo wget -q -O /etc/apt/sources.list.d/owntone.list https://raw.githubusercontent.com/owntone/owntone-apt/refs/heads/master/repo/rpi/owntone-trixie.list && sudo apt update && sudo apt install owntone -y

After that, go to http://owntone.local:3689 (or http://localhost:3689) and check if the web UI loads correctly.

Pipes

Long story short, we'll create pipe files to enable communication between Raspotify and Owntune. Raspotify will be writing to them, OwnTune reading and playing that via AirPlay.
Just run

sudo mkdir /srv/music && sudo mkfifo /srv/music/raspotify-pipe && sudo mkfifo /srv/music/raspotify-pipe.metadata

to create two pipes. You can use different names without any issue, but if you want to put them in a different directory, you'll need to update library.directories option in Owntone configuration.
Also, .metadata pipe won't be actually used, as Raspotify is not currently able to process metadata. We created it simply to have one less error from Owntone - it just needs the file to exist.

Configuration

Raspotify

All the Raspotify options are listed on the wiki. We'll need to change only 2 of them.
Let's open the configuration file with nano to edit it:

sudo nano /etc/raspotify/conf

and set LIBRESPOT_BACKEND and LIBRESPOT_DEVICE as follows:

LIBRESPOT_BACKEND=pipe
LIBRESPOT_DEVICE=/srv/music/raspotify-pipe

Remember to uncomment them!
The LIBRESPOT_DEVICE path must match the one used for the pipes. If you decide to put pipes somewhere else (for example, /var/run/raspotify-pipe), make sure that LIBRESPOT_DEVICE path is the same.

If you want, you can also change the name under which Raspberry will appear on Spotify Connect devices list. To do this, modify LIBRESPOT_NAME, for example

LIBRESPOT_NAME="Raspotify"

Save and close the file (Ctrl + X, Y, Enter).

Owntone

In the bottom right of the web UI, you should see an arrow to expand the simplified output control panel. One of the devices there should be the AirPlay speaker (HomePod) that you want to use - click its icon to enable it.

You can also adjust the volume here. It's quite important - at the end, I had everything working correctly, but the slider here was too low, and I thought something was still broken 🙃 The "final volume" on the HomePod is a product of the volume you set in Owntone and the value picked for the Spotify Connect device on the phone. Keep that in mind when things are too quiet/loud.

To make sure all the config changes in both Raspotify and Owntune are applied, restart the services:

sudo systemctl restart raspotify && sudo systemctl restart owntone

Running everything

We're basically there. Now get your phone, open Spotify, and you should be able to select Raspberry as the Spotify Connect device 🎶
Remember that Raspberry and your phone must be on the same Wi-Fi network!
Here are also some details about Spotify Connect on the Spotify support page if you're not familiar with the feature itself: https://support.spotify.com/article/spotify-connect/

General troubleshooting

If things are not working, journalctl is your best friend in debugging. Simply open a terminal and run

journalctl -u owntone -f

(or raspotify instead of owntone)
and you'll see some system logs from the services. Hopefully, you'll see some "error" lines that will help you fix the problem.

Summary

As I've written at the beginning, if you know the steps, the setup should be straightforward. It's just about running two services and connecting them. Knowing the Raspberry/Linux ecosystem, the above steps will become outdated sooner than later, but I hope they will be useful for at least a moment 😄

If you hit any problems, write a comment. While my Linux-fu is not high, I'll do my best to help.

Happy streaming! 🎵

Chrome extension 101 - implementing an extension

Piotr Ładoński — Mon, 06 Jan 2025 14:27:25 +0000

In the previous post, I showed you how to set up a Chromium extension project, so it supports TypeScript, autocompletion wherever possible and just works nicely as a starter. Now, I'll briefly show the implementation of my simple Page Audio extension.

Intro

Idea

What I wanted from my extension was very simple - when I go to a specific website, it should start playing predefined audio. Hard-coded website name and audio are completely fine.

In a bit more detail, the audio should start playing when I open www.example.com, stop when I switch to a different tab, and resume when I go back to www.example.com. Also, if I have two (or more) tabs with www.example.com opened and I switch between them, the audio should keep playing without restarting. In other words, audio should be played on the whole extension level, not individual tabs.

General technical approach

In short, we need to create HTMLAudioElement somewhere and play/pause it depending on the website in the current tab.

It is doable with service worker and content scripts - we could have a content script creating an HTMLAudioElement element on every page and use a service worker to coordinate the playback. When the tab loses focus, it passes the current media time frame to the service worker and when another tab with a matching URL gains focus, it asks the service worker for the time frame and resumes the playback from there.

However, I think this approach is a bit convoluted and might be prone to errors. It would be much nicer if we could have only one HTMLAudioElement element and play/pause it globally, not from individual tabs. Luckily, there's an interesting API that will greatly help us - offscreen API.

Offscreen API lets the extension create one invisible HTML document. Using it, we'll have a place to keep our HTMLAudioElement and just play/pause it when needed. Bear in mind that service worker still can't do any DOM operations, so we'll need some helper script on our offscreen document to receive service worker messages and adequately control the player.

Implementation

Needed permissions in `manifest.json`

My extension needs two entries in the permissions array:

tabs - it needs to know when the user is switching and/or updating tabs
offscreen - it needs ability to create offscreen document to play the audio from there

If you open extension details in the browser, you'll see permissions described as:

Read your browsing history

It might look a bit scary, but that's what adding tabs permission causes. Unfortunately, I wasn't able to figure out a different approach with less concerning permissions. The other ideas I had were resulting in even scarier permission sets 😅 In this thread you can read why tabs permission causes that entry.

Managing offscreen documents

As I've mentioned, I would like to have only one HTMLAudioElement and play the audio from it. To make it tab-independent, I'll use offscreen API to create a document where it will be kept and controlled by messages from the service worker.

I feel like object-oriented programming, so here's OffscreenDoc class helping with offscreen document management. In essence, it just creates the offscreen document if it's not created yet.

// ts/offscreen-doc.ts
/**
 * Static class to manage the offscreen document
 */
export class OffscreenDoc {
    private static isCreating: Promise<boolean | void> | null;
    private constructor() {
        // private constructor to prevent instantiation
    }

    /**
     * Sets up the offscreen document if it doesn't exist
     * @param path - path to the offscreen document
     */
    static async setup(path: string) {
        if (!(await this.isDocumentCreated(path))) {
            await this.createOffscreenDocument(path);
        }
    }

    private static async createOffscreenDocument(path: string) {
        if (OffscreenDoc.isCreating) {
            await OffscreenDoc.isCreating;
        } else {
            OffscreenDoc.isCreating = chrome.offscreen.createDocument({
                url: path,
                reasons: ['AUDIO_PLAYBACK'],
                justification:
                    'Used to play audio independently from the opened tabs',
            });
            await OffscreenDoc.isCreating;
            OffscreenDoc.isCreating = null;
        }
    }

    private static async isDocumentCreated(path: string) {
        // Check all windows controlled by the service worker to see if one
        // of them is the offscreen document with the given path
        const offscreenUrl = chrome.runtime.getURL(path);
        const existingContexts = await chrome.runtime.getContexts({
            contextTypes: ['OFFSCREEN_DOCUMENT'],
            documentUrls: [offscreenUrl],
        });
        return existingContexts.length > 0;
    }
}

As you can see, the only public method is setup and it needs some path when called. That's a path to an HTML document template that will be used to create our offscreen document. It's gonna be super simple in our case:

<!-- offscreen.html -->
<script src="dist/offscreen.js" type="module"></script>

Literally, just one script tag. This script will be used to receive service worker messages, create HTMLAudioElement, and play/pause the music. It also has type="module" as I will import something there.

But to receive messages, we should probably send them first.

Message interface

There isn't any strict interface for messages. We just need to make sure they are JSON-serializable. However, I would like to be as type-safe as possible, so I defined a simple interface for messages passed in my extension:

// ts/audio-message.ts
export interface AudioMessage {
    /**
     * Command to be executed on the audio element.
     */
    command: 'play' | 'pause';
    /**
     * Source of the audio file.
     */
    source?: string;
}

You'll see in a moment that the sendMessage method isn't that great fit for typing, but there's an easy workaround to still benefit from type safety there.

Sending messages from the service worker

The service worker is the "brain" of our extension, knows what and when is happening, and should send appropriate messages as needed. But when is it exactly?

We should change the playback state in three situations:

when a new tab is activated, so user simply changes from tab A to tab B,
when the current tab is updated, so its URL has changed, or
when a tab is closed - that's a bit tricky case, as it might happen without invoking any of the two above cases when the user closes the last incognito window while the audio is playing.

All situations mean we might be on the website where we want the audio to play or that we've just closed/left it.

Without further ado, here's the updated ts/background.ts script reacting to the two events:

// ts/background.ts
import { AudioMessage } from './audio-message.js';
import { OffscreenDoc } from './offscreen-doc.js';

const affectedPage = 'https://example.com/';
const defaultAudio = 'assets/audio.mp3';

// Play audio when the tab with affectedPage is active
chrome.tabs.onActivated.addListener((activeInfo) => {
    chrome.tabs.get(activeInfo.tabId, async (tab) => {
        await toggleAudio(tab.url);
    });
});
chrome.tabs.onUpdated.addListener(async (tabId, changeInfo, tab) => {
    await toggleAudio(tab.url);
});
chrome.tabs.onRemoved.addListener(async (tabId) => {
    const tabs = await chrome.tabs.query({});
    const activeTab = tabs.find((tab) => tab.active);
    await toggleAudio(activeTab?.url);
});

async function toggleAudio(tabUrl?: string) {
    await OffscreenDoc.setup('offscreen.html');
    const command = tabUrl?.includes(affectedPage) ? 'play' : 'pause';
    chrome.runtime.sendMessage({
        command,
        source: defaultAudio,
    } satisfies AudioMessage);
}

As you can see, the toggleAudio function is the most important here. First of all, it sets up the offscreen document. It's safe to call it multiple times, as it just does nothing if the document is already created. Then it decides if it should send "play" or "pause" command, depending on the URL of the current tab. Finally, it sends the message. As I've mentioned, sendMessage doesn't have a generic variant (sendMessage<T>) so it's non-trivial to specify the message type, but TS satisfies helps with making sure that the object we are sending is of AudioMessage type.

Notice also the two constants at the top - here you specify what audio you want to play and at which website.

Receiving the messages by offscreen document

Finally, we are sending the messages, so now it's time to receive them and play some music 🎶

To do this, we need to implement the script used by offscreen.html. It's dist/offscreen.js, so that's how corresponding ts/offscreen.ts looks:

// ts/offscreen.ts
import { AudioMessage } from './audio-message.js';

let audio: HTMLAudioElement | null = null;
// Listen for messages from the extension
chrome.runtime.onMessage.addListener((msg: AudioMessage) => {
    audio ??= new Audio(msg.source);
    audio?.[msg.command]();
    return undefined;
});

In short, if we haven't created HTMLAudioElement we're doing that using the provided source and then we're playing/pausing it. Returning undefined is needed for typing purposes. If you're interested in the meaning of the different return values, check the docs

Summary

Try it out! Go to www.example.com (or whatever website you've set) and see if the audio is playing. Try switching tabs back and forth and verify if it correctly stops and resumes.

Take into account that if you pause music for more than 30 seconds, it will be restarted, as the service worker will be terminated by the browser! Here are some docs about that.

To summarize what we did:

we updated our manifest.json with the required permissions to create an offscreen document and monitor activity on tabs
we made the service worker observe activity on tabs and send adequate commands to the script living in the offscreen document
we started playing audio via a script that receives messages from the service worker and controls the DOM of the offscreen document

I hope it was clear and easy to follow! There's quite a natural progression of this extension - letting the user specify different websites and assign different audio to each of them. Hopefully, I'll add that when I have some time and write another post describing my approach.

For now, thanks for reading!

Chrome extension 101 - environment setup

Piotr Ładoński — Tue, 31 Dec 2024 15:52:36 +0000

I want some goofy functionality in my browser. Maybe I can add it with a simple extension? It doesn't exist, but writing it myself should be easy, right?

That's what I thought a couple of days ago. While I wasn't completely wrong, some parts of the development process were a bit more time-consuming than I expected. I won't say difficult, but rather hard to figure out using available documentation. While API documentation, core concepts, etc. are described quite nicely on developer.chrome.com, I wanted a specific developer experience:

TypeScript with proper typing of chrome namespace
Splitting the code into multiple files and import/export what was necessary
Debugging my code with simple console.log and/or debugger
Autocompletion in my manifest.json
Simple setup, without any bundlers and half of the Internet in my node_modules
Simple way of updating and testing the extension in the browser

In a better or worse way, I managed to set things up as I wanted. In this post, I'll briefly explain general extension concepts and show you how I've set up my development environment. In the next post or two I'll focus on the implementation details of my simple page-audio extension.

TLDR:
If you just want the code, here's the boilerplate repo:

Voodu / chromium-extension-boilerplate

Chromium extension boilerplate

This repository aims at being a starting point for developing a chromium extension.

It's as minimalistic as possible, but comes with pre-configured:

autocompletion for manifest.json
TypeScript transpilation from ts folder to dist directory
types for chrome namespace
properly working exporting and importing (with VS Code workspace setting for correct auto import format)
example manifest.json

Happy coding!

View on GitHub

ℹ️ I use Windows 11, MS Edge, VS Code, and npm everywhere below ℹ️

Brief intro to extensions

Let's start with a crash course on general extension concepts.

Every extension has a manifest.json file that defines its name, version, required permissions, and used files. Extensions can provide functionality in several different ways:

via popup - extension popup is this small window that opens when you click the extension icon in the extension bar,
via content scripts - scripts that are injected directly into websites and have DOM access,
via background (service worker) scripts - scripts run in a separate context, independent from opened websites

There are other ways, but I'll stick to these three in this guide.

Another important concept is messaging. Usually, we need to combine the above methods, as all of them have different limitations. For example, background scripts don't depend on opened tabs and can be more useful for persisting state, but can't access the DOM of any website. Therefore, we might need to get some extension-wide data from the background script, pass it using a message to a content script, and modify the website from there.

It can also be useful to understand some basics about permissions. In short, some APIs won't work as expected if manifest.json doesn't specify the correct permissions. For example, if we don't specify "tabs" permission, objects returned from the tabs API won't have a url field. On the other hand, we shouldn't ask for too many permissions - if the extension is going to be public, users might be concerned about giving access to too many things.

Creating a simple extension

Inspired by https://developer.chrome.com/docs/extensions/get-started/tutorial/hello-world

Let's start with understanding the core concepts of our development workflow using an extremely simple extension that just displays some text in a popup.

Files

First of all, we need a manifest.json file:

// manifest.json
{
  "name": "Hello World",
  "description": "Shows Hello World text",
  "version": "1.0",
  "manifest_version": 3,
  "action": {
    "default_popup": "hello.html",
    "default_icon": "icon.png"
  }
}

name, description, version, and manifest_version are probably self-explanatory. action.default_popup is a path to an HTML file that will be rendered upon clicking the extension icon. default_icon is a path to extension icon. Both paths are relative to manifest.json location.

Now, add icon.png (for example, this one) and hello.html files in the same directory as manifest.json.
hello.html can look like that:

<!-- hello.html -->
<p>Hello world</p>

And your whole directory should look like that:

.
├── hello.html
├── icon.png
└── manifest.json

Activating the extension

To activate your extension:

Go to edge://extensions/
In the left sidebar, enable "Developer mode"
- "Allow extensions from other stores" might also be needed
Above the extension list click "Load unpacked"
Select the folder with your extension files
Your extension should appear on the list and its icon in the extensions toolbar 🥳

Now, after clicking the icon it will show a small popup with "Hello world" text.

That covers the most important basics. Let's move to something more interesting.

Page-Audio extension environment setup

Autocomplete in `manifest.json`

We'll start again with the manifest.json and empty directory.

It would be awesome to have autocomplete when writing the manifest.json file, wouldn't it? Fortunately, it's a well-defined standard and has a JSON schema at https://json.schemastore.org/chrome-manifest. We just need it under the "$schema" key at the beginning of manifest.json:

// manifest.json
{
    "$schema": "https://json.schemastore.org/chrome-manifest"
}

and VS Code instantly starts helping us by suggesting field names and showing warnings if mandatory fields are missing. Awesome!🔥

To have something working for testing our setup, use manifest.json looking this way:

// manifest.json
{
    "$schema": "https://json.schemastore.org/chrome-manifest",
    "name": "Page Audio",
    "version": "0.0.0.1",
    "manifest_version": 3,
    "icons": {
        "16": "icons/logo16x16.png",
        "32": "icons/logo32x32.png",
        "48": "icons/logo48x48.png",
        "128": "icons/logo128x128.png"
    },
    "background": {
        "service_worker": "dist/background.js",
        "type": "module"
    }
}

icons - it's just a different way of specifying extension icons
background section - specifies the path with the service worker JS file and its type; it's module as the code will use export and import later on

TypeScript

Using TypeScript... well, requires TypeScript. If you don't have it installed, start with

npm install -g typescript

Basic config

To have things organized, but not too complicated, I'll keep .ts source files in the ts directory. They will be taken from there by the transpiler and put in the dist directory as .js files.

This is described by the following .tsconfig:

// .tsconfig
{
    "compilerOptions": {
        "target": "ES6",
        "module": "ES6",
        "outDir": "./dist",
        "rootDir": "./ts",
        "strict": true,
    }
}

The most important bits are compiler.rootDir and compiler.outDir. The other fields can have different values or be completely removed (at least some of them).

That's the basic configuration - placing some files in the ts directory and running tsc in the root directory will create a corresponding .js file in dist. However, we're missing one important part - types for the chrome namespace that we'll be using. The simplest solution is to add them via npm.

Adding `chrome` types

Create an empty package.json, just with the brackets:

// package.json
{
}

and in the command line run:

npm i -D chrome-types

You can also add scripts to run tsc build and in the watch mode. Final package.json should look like this:

// package.json
{
    "scripts": {
        "build": "tsc",
        "watch": "tsc -w"
    },
    "devDependencies": {
        "chrome-types": "^0.1.327"
    }
}

ℹ️ chrome-types version might be higher in your case. ℹ️

After adding the types, we need to let TypeScript know about them. To do this, simply update .tsconfig.json:

// .tsconfig.json
{
    "compilerOptions": {
        "target": "ES6",
        "module": "ES6",
        "outDir": "./dist",
        "rootDir": "./ts",
        "strict": true,
        "types": ["chrome-types"] // Add this line!
    }
}

To test if our setup works correctly:

In the ts folder, create background.ts file with the following content

// ts/background.ts
chrome.runtime.onInstalled.addListener(() => {
    console.log('Service Worker Installed');
});

In the command line, run
```
npm run watch
```
Verify if the dist directory was created and background.js file appeared there
Change something in the console.log string in ts/background.ts file and save it
Check if it automatically updated dist/background.js.

If that works, awesome! We have nearly everything set up 🎉

You can also verify if your directory structure looks similar to that:

.
├── dist
│   └── background.js
├── icons
│   ├── logo128x128.png
│   ├── logo16x16.png
│   ├── logo32x32.png
│   └── logo48x48.png
├── manifest.json
├── node_modules
│   └── chrome-types
│       └── ... some stuff inside ...
├── package-lock.json
├── package.json
├── ts
│   └── background.ts
└── tsconfig.json

`import` and `export`

As I've mentioned, I would like to split the code into smaller files. To do this, exporting and importing must work correctly.

One step in that direction was specifying our service_worker in manifest.json as "type": "module". However, there's one difference between TypeScript and JavaScript when working with modules - while TypeScript doesn't need file extensions when importing, JavaScript does. So, for example, this import:

import { something } from "./fileWithFunctions";

will work in TS, but JS needs

import { something } from "./fileWithFunctions.js";

It's also important to understand, that TS transpiler does nothing to the import paths. And it's "smart" enough to understand that when importing from file.js it should also look for file.ts.

Combining all of that, TS will also be happy with JS-style import and will use the corresponding TS file when importing from file.js. What we need to do is make sure that all imports in TS files have a .js extension. To automate it in VS Code:

Press CTRL + , to open settings
Switch to "Workspace" tab
Search for typescript.preferences.importModuleSpecifierEnding
Set it to ".js / .ts" option

Now, whenever you auto import using VS Code, it will add .js to the filename 🧠

To test if things work correctly:

Create ts/hello.ts file with the following content

// ts/hello.ts
export function hello() {
    console.log('Hello');
}

In ts/background.ts remove the current console.log line and start typing "hello"
VS Code should autocomplete it and add the correct import after you accept the suggestion with Tab

In the end, the file should look like this:

// ts/background.ts
import { hello } from "./hello.js";

chrome.runtime.onInstalled.addListener(() => {
    hello();
});

Note that import ends with the .js extension. If you check dist/background.js the extension is there as well and that's what makes everything work correctly.

To make sure we are at the same stage, you can compare the directory structure:

.
├── .vscode
│   └── settings.json
├── dist
│   ├── background.js
│   └── hello.js
├── icons
│   └── ... icons ...
├── manifest.json
├── node_modules
│   └── chrome-types
│       └── ... some stuff inside ...
├── package-lock.json
├── package.json
├── ts
│   ├── background.ts
│   └── hello.ts
└── tsconfig.json

Dev Tools for service worker

Okay, we have a decent development experience. We've also added some console.log calls... but where to find them now?

If you add console.log inside a content script, you can simply open Dev Tools and they will be there, as content scripts work in the same context as the page they are injected into. However, console.logs from background scripts are hidden a bit more.

Open edge://extensions/ and load your extension if you haven't done that yet
Find your extension on the list
Click "service worker" link in "Inspect views" line:
A new Dev Tools window should open and you'll see logs from the service worker there
- if you don't see the logs, click "Reload" below the "Inspect views"

The three links at the bottom of the tile are also very important

"Reload" - refreshes the whole extension, including changes to manifest.json; checkout this table to understand when reloading might be needed
"Remove" - deletes the extension
"Details" - shows more information about the extension, for example, its permissions
(optional) "Errors" - if there are errors when installing the service worker, this link will appear and take you to the list of errors

Phew. That took a moment, but, finally, our environment is set up nicely. From now on, we'll just have to

Run npm run watch (if you stopped it)
Write our code in ts directory
(Optionally) Reload the extension from the extensions tab

And our extension will be automatically updated! ⚙️

If you have an idea how to also "Reload" automatically (w/o elaborate hacking), let me know in the comments

Summary

We have our environment ready!

Autocomplete works in manifest.json, so we don't have to guess what are the correct values
TypeScript helps us with using chrome API correctly
Code can be split into smaller, logical files
The code we write in the ts folder is updated automatically
We know where to find Dev Tools for the service worker and content scripts

In the next part, I'll describe the implementation details of my small "Page audio" extension.

Thanks for reading!

Blazor, dotnet CLI, VS Code & Tailwind - how to set that up?

Piotr Ładoński — Thu, 22 Aug 2024 18:33:45 +0000

I'm a big fan of VS Code and love using it to write all types of apps I can. Also, I like working with C# and wanted to play a bit with Blazor recently. Combining both of these interests, I decided to write a small project in Blazor, but using VS Code instead of typical Visual Studio approach. It also forced me to learn dotnet CLI a bit more (not as much as I thought at the beginning, though 😄). In this post, I'll describe general project configuration which includes:

Creating a new Blazor Web App solution & project
Adding a custom, "Shared", project to the solution
VS Code setup
Debugging in VS Code (including Hot Reload)
Adding Bootstrap and Tailwind to the project

Maybe, one day, I'll dive a bit more into the project implementation, but for now, it's gonna be just the environment setup 😉

Creating the project

As mentioned, I wanted to learn a bit of dotnet CLI, so we'll create the solution and add needed projects using command line.

The goal is to have a solution with the default Blazor Web App projects + additional "Shared" project that can contain, for example, business logic, classes common for backend and frontend, etc.

Empty solution and Blazor Web App project

To create an empty solution, run

dotnet new sln -o MyCoolProject

And then run

dotnet new blazor -int Auto --empty -n MyCoolProject

to create a Blazor Web App project.

Quick explanation of the arguments:

blazor - creates a Blazor Web App
-int Auto - sets interactivity mode of the Blazor project to Auto which allows the project to automatically switch between server-side and client-side rendering based on the context
--empty - project will be empty, without any predefined pages/components
-n MyCoolProject - sets the name of the project

"Shared" class library

The "Shared" project is a simple class library, so it can be created by running

dotnet new classlib -o MyCoolProject.Shared

Connecting things - adding to solution and referencing

We have all the projects, but not linked to the solution. Let's fix that with

dotnet sln add .\MyCoolProject\MyCoolProject.csproj .\MyCoolProject.Client\MyCoolProject.Client.csproj .\MyCoolProject.Shared\MyCoolProject.Shared.csproj

And then reference "Shared" project in both other projects with

dotnet add .\MyCoolProject\MyCoolProject.csproj reference .\MyCoolProject.Shared\MyCoolProject.Shared.csproj
dotnet add .\MyCoolProject.Client\MyCoolProject.Client.csproj reference .\MyCoolProject.Shared\MyCoolProject.Shared.csproj

It's nearly done. However, to make the Shared code actually visible in the other ones, we also need to update global imports. To do that, add

@using MyCoolProject.Shared

at the end of

MyCoolProject\Components\_Imports.razor
MyCoolProject.Client\_Imports.razor

Done? Try

dotnet run

and see if things work.

VS Code setup

For the previous steps we didn't even have to open VS Code. Time to change that.

First - extensions. Probably the most important one is C# Dev Kit. You can read its description yourself, but, in essence, it makes VS Code more IDE-like for C# compared to being just a text editor. You might also look into IntelliCode for C# DevKit if you feel like normal code completion might be not enough.

As we're already playing with the editor configuration, let's do one more thing - enable Hot Reload. As it's an experimental feature, it's not enabled by default. Simply, open VS Code settings (CTRL + ,), search for "hot-reload" and check this setting:

Debugging

At that point, we should be able to run and debug the code from VS Code - ideally, just press F5 and it should work. If not, click "Run and debug", select C#, and then something with "default configuration". At worst, restart VS Code (to be sure, really close and open it again, not just reload the window via the command palette).

Now let's try actual debugging with a breakpoint. Due to the project config with Auto, remember about @rendermode InteractiveAuto at the top of the Home.razor file:

@page "/"
@rendermode InteractiveAuto

<h3>Simple Counter</h3>

<p>Current value: <strong>@counterValue</strong></p>

<button @onclick="IncrementCounter">Increment</button>

@code {
    private int counterValue = 0;

    private void IncrementCounter()
    {
        counterValue++;
    }
}

Place a breakpoint in the IncrementCounter method, run the app in debug mode, and, hopefully, it will be hit when you press the button to increase the counter.

❗ If the counter doesn't work and you see an error in the DevTools console about the Home component not being found, move it from the MyCoolProject/Components/Pages directory to MyCoolProject.Client/Components ❗Here are some docs about it.

Hot Reload

There's not much to say about Hot Reload - after enabling the setting in VS Code, it should work.

To test it, run the app, change something in the source file, save it, and refresh the page. Changes should be visible instantly.

CSS library

We are nearly done with the config! Let's sprinkle our project with some CSS library and we're good to go.

I usually use Bootstrap and I started with setting up the project to use it. Then, I recalled I wanted to give Tailwind CSS a shot at some point, so that's the CSS library of choice here. As I, however, set up Bootstrap, here's a quick guide for it.

Bootstrap

Managing simple libraries in Blazor projects is the easiest when using LibMan. As this series is focused on doing stuff manually, I'll do the same with LibMan. Luckily, there's a nice CLI tool for it.

Docs are super clear and to the point, so I won't write everything again here, but in short:

install LibMan globally with

dotnet tool install -g Microsoft.Web.LibraryManager.Cli

initialize it in the current project with
```
libman init -p unpkg
```
in .Client project folder (why unpkg?)
add Boostrap 5 with
```
libman install bootstrap -d wwwroot/lib/bootstrap
```
If you're wondering why we didn't give any default destination - unfortunately, LibMan doesn't put a new library in the dedicated folder anyway 🤷
you'll probably need Popper for some scripts to work, so add it with
```
libman install "@popperjs/core" -d wwwroot/lib/popper
```

link CSS/HTML in MyCoolProject/Components/Pages/App.razor:

<head>
    ...
    <link rel="stylesheet" href="lib/bootstrap/dist/css/bootstrap.min.css" />
    ...
</head>

<body>
    ...
    <script src="lib/popper/dist/umd/popper.min.js"></script>
    <script src="lib/bootstrap/dist/js/bootstrap.min.js"></script>
</body>

that should make most of the Bootstrap stuff work. You will still have problems with, for example, tooltips, though. Then check this SO answer
I haven't checked the whole integration thoroughly, so treat the above steps just as a starter 😊

Tailwind

Tailwind can be summarized as a set of utility CSS classes you can use to style your HTML. They are similar to Bootstrap p-4, mb-3, d-flex etc. but way more powerful. Another point worth noting from a configuration point of view is its build process - there is a Tailwind tool that scans your source files, looks for Tailwind CSS class names, and includes them in the final CSS file you link to your main HTML. That's it in terms of theory - let's actually add Tailwind to our Blazor project. I've followed Chris Sainty's blog post on that.

First things first, we'll need the mentioned Tailwind tool for creating the output CSS. Install it globally with

npm install -g tailwindcss

Then we need a main config file for Tailwind. To create it, go to the root directory of the project and run

npx tailwindcss init

And then, adjust content field in the created tailwind.config.js to be:

content: [
    './MyCoolProject/**/*.{razor,html}',
    './MyCoolProject.Client/**/*.{razor,html}',
],

It tells Tailwind which files to watch for the CSS classes.

Then we need the main CSS files to be processed by Tailwind. We'll also include default Tailwind classes and styles there. We can use the existing MyCoolProject\wwwroot\app.css file for that. Just add:

@tailwind base;
@tailwind components;
@tailwind utilities;

at the top and that should do the trick.

Using CLI, we should now tell Tailwind which file to process and where to put the final CSS that we'll link in the HTML. Our input will be the mentioned app.css file, and we'll output the final CSS to MyCoolProject\wwwroot\app-compiled.css. The command is:

npx tailwindcss -i .\MyCoolProject\wwwroot\app.css -o .\MyCoolProject\wwwroot\app-compiled.css --watch

Due to the --watch switch it also automatically rebuilds the output after any changes in the input file are detected.

To finish linking Tailwind to out app, go to MyCoolProject\Components\App.razor and update one of the <link> tags which contains reference to app.css and change it to app-compiled.css, i.e.:

<link rel="stylesheet" href="app-compiled.css" />

To test if things work, you can open MyCoolProject.Client\Components\Home.razor and add somewhere

<h1 class="text-3xl font-bold underline">
    Hello world!
</h1>

Then launch the app (F5).

Summary

In the post, I've very briefly described how to set up a dev environment for developing Blazor Web App using VS Code. We created solution, projects and linked them properly using dotnet CLI. Then we added the most important extensions to VS Code and updated it settings to enable Hot Reload. To finish the configuration, we added CSS library (Tailwind).

It's very much not in-depth post, but I hope it gives a general idea of how to do things 😊 Blazor is quite a new thing for me, so comments and questions are more than welcome.

Thanks for reading! ❤️

PS
I've been writing this post over quite some time (motivation, time & stuff), so if something doesn't work anymore, let me know!

Handling theme change in MS Teams app with Blazor

Piotr Ładoński — Tue, 06 Dec 2022 22:49:31 +0000

Recently, I've been playing a bit with Blazor and Microsoft Teams apps. I had hard time finding clear explanation how to handle theme changes in MS Teams. As, after spending some time, I figured out the way, I'll share my approach.

The problem

The problem is very simple - when user changes their theme settings in Microsoft Teams, we want to react to that instantly; without app reload. In my case, I want to change BaseLayerLuminance of FluentDesignSystemProvider in App.razor, so all the Fluent UI components have their look updated automatically.

The tricky part is that we want to do that using Blazor.

JavaScript approach

Solution with JavaScript is incredibly simple, found at the bottom of the docs:

// You can register your app to be informed if the theme changes by calling
microsoftTeams.app.registerOnThemeChangeHandler(function(theme) { /* ... */ }).

In Blazor we also have something similar to microsoftTeams object when we inject @inject MicrosoftTeams MicrosoftTeams in the component, so that should be pretty simple, right?

No.

Blazor approach

Turns out, Interop.TeamsSDK.MicrosoftTeams class doesn't expose any app or registerOnThemeChangeHandler. After searching a bit it gets even better - there doesn't seem to be any C# SDK doing that. This means we are stuck with JavaScript and JS Interop.

Conceptually, it's rather simple:

Create .js file which has a function calling microsoftTeams.app.registerOnThemeChangeHandler
Import and call the function from App.razor
On theme change, the JS function calls C# code
Update the variable bound to BaseLayerLuminance and rerender the component

However, there are some technicalities which make it a bit more complicated than it looks.

Starting code

Code at the beginning looks like that.

_luminance field is used to set BaseLayerLuminance
after the first render, the theme is grabbed from the context and used to determine _luminance
UpdateLuminance has this weird async implementation as it's required later by the JS interop

// App.razor

@inject MicrosoftTeams MicrosoftTeams

<FluentDesignSystemProvider AccentBaseColor="#6264A7" BaseLayerLuminance="_luminance">
    <Router AppAssembly="@typeof(Program).Assembly" PreferExactMatches="@true">
        <Found Context="routeData">
            <RouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" />
        </Found>
        <NotFound>
            <LayoutView Layout="@typeof(MainLayout)">
                <p>Sorry, there's nothing at this address.</p>
            </LayoutView>
        </NotFound>
    </Router>
</FluentDesignSystemProvider>

@code
{
    private float _luminance = 1.0f;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        await base.OnAfterRenderAsync(firstRender);

        if(firstRender)
        {
            await MicrosoftTeams.InitializeAsync();
            var context = await MicrosoftTeams.GetTeamsContextAsync();
            await UpdateLuminance(context.Theme);
        }
    }

    public async Task UpdateLuminance(string theme = "default")
    {
        await Task.Run(() =>
        {
            _luminance = theme switch
            {
                "default" => 1.0f,
                "dark" => 0.0f,
                "contrast" => 0.5f, // it doesn't make sense, but let's pretend it does
                _ => 1.0f
            };
        });
        StateHasChanged();
    }
}

Calling JS from Blazor component

That is described pretty accurately in the docs. The examples usually show the functions attached to the window object. I just prefer to have them exported from the .js file. Thus, that's my ThemeChange.js:

// ./wwwroot/js/ThemeChange.js

export function onTeamsThemeChange() {
    microsoftTeams.app.registerOnThemeChangeHandler(function (theme) {
        console.log('Theme changed to:', theme);
    });
}

As I want to update the theme of the whole app, I'll be modifying App.razor.

First of all, it needs IJSRuntime to be injected:

@inject IJSRuntime JS
// Rest of the HTML/Code

Then, in the @code block, we declare IJSObjectReference field to hold the loaded module and call the function inside it. We load all of that after the first render:

private float _luminance = 1.0f;
private IJSObjectReference? _module;

protected override async Task OnAfterRenderAsync(bool firstRender)
{
    await base.OnAfterRenderAsync(firstRender);

    if(firstRender)
    {
        await MicrosoftTeams.InitializeAsync();
        var context = await MicrosoftTeams.GetTeamsContextAsync();
        await UpdateLuminance(context.Theme);
        _module = await JS.InvokeAsync<IJSObjectReference>("import", "./js/ThemeChange.js");
        await _module.InvokeVoidAsync("onTeamsThemeChange");
    }
}

Now, after changing the theme in Teams settings, console should log which theme is currently selected.

Calling C# from JS

At this point, we just want to call UpdateLuminance from inside the callback of our JS function. Details are described in the docs. We have to follow the instance method way, as we are calling non-static StatusHasChanged method, so it can't be called from a static context.

Let's start with updating JS:

// ./wwwroot/js/ThemeChange.js

export function onTeamsThemeChange(dotNetHelper) {
    microsoftTeams.app.registerOnThemeChangeHandler(function (theme) {
        dotNetHelper.invokeMethodAsync('UpdateLuminance', theme);
    });
}

Details are described in the docs, but in short, Blazor is going to pass some object which will be used to call the C# method. The second argument to invokeMethodAsync is just an argument to UpdateLuminance.

Code in App.razor will require a bit more changes:

Starting a bit bacwards, but we will have to clean up after all the JS Interop fun, so declare that the component is disposable:
```
@implements IDisposable
@inject IJSRuntime JS
@inject MicrosoftTeams MicrosoftTeams
```

Then, we have to declare a field to hold reference to the App in JavaScript:

private float _luminance = 1.0f;
private IJSObjectReference? _module;
private DotNetObjectReference<App>? _objRef;

This reference is created in overriden OnInitialized method:

protected override void OnInitialized()
{
    _objRef = DotNetObjectReference.Create(this);
}

As our JS function has a parameter now, we need to pass it:

if(firstRender)
{
    await MicrosoftTeams.InitializeAsync();
    var context = await MicrosoftTeams.GetTeamsContextAsync();
    await UpdateLuminance(context.Theme);
    _module = await JS.InvokeAsync<IJSObjectReference>("import", "./js/ThemeChange.js");
    await _module.InvokeVoidAsync("onTeamsThemeChange", _objRef);
}

Minor but important thing - our UpdateLuminance method has to be decorated with JSInvokable attribute:
```
[JSInvokable]
public async Task UpdateLuminance(string theme = "default")
```

To finish up, don't forget about disposing:

public void Dispose()
{
    _objRef?.Dispose();
}

Et voilà! Now theme of your Fluent UI controls should change instantly after user changes their settings 🙂

Full code:

// App.razor
@implements IDisposable
@inject IJSRuntime JS
@inject MicrosoftTeams MicrosoftTeams

<FluentDesignSystemProvider AccentBaseColor="#6264A7" BaseLayerLuminance="_luminance">
    <Router AppAssembly="@typeof(Program).Assembly" PreferExactMatches="@true">
        <Found Context="routeData">
            <RouteView RouteData="@routeData" DefaultLayout="@typeof(MainLayout)" />
        </Found>
        <NotFound>
            <LayoutView Layout="@typeof(MainLayout)">
                <p>Sorry, there's nothing at this address.</p>
            </LayoutView>
        </NotFound>
    </Router>
</FluentDesignSystemProvider>

@code{
    private float _luminance = 1.0f;

    private IJSObjectReference? _module;
    private DotNetObjectReference<App>? _objRef;

    protected override void OnInitialized()
    {
        _objRef = DotNetObjectReference.Create(this);
    }

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        await base.OnAfterRenderAsync(firstRender);

        if(firstRender)
        {
            await MicrosoftTeams.InitializeAsync();
            var context = await MicrosoftTeams.GetTeamsContextAsync();
            await UpdateLuminance(context.Theme);
            _module = await JS.InvokeAsync<IJSObjectReference>("import", "./js/ThemeChange.js");
            await _module.InvokeVoidAsync("onTeamsThemeChange", _objRef);
        }
    }

    [JSInvokable]
    public async Task UpdateLuminance(string theme = "default")
    {
        await Task.Run(() =>
        {
            _luminance = theme switch
            {
                "default" => 1.0f,
                "dark" => 0.0f,
                "contrast" => 0.5f,
                _ => 1.0f
            };
        });
        StateHasChanged();
    }

    public void Dispose()
    {
        _objRef?.Dispose();
    }
}

// ./wwwroot/js/ThemeChange.js

export function onTeamsThemeChange(dotNetHelper) {
    microsoftTeams.app.registerOnThemeChangeHandler(function (theme) {
        dotNetHelper.invokeMethodAsync('UpdateLuminance', theme);
    });
}

Windows 11 - making taskbar like Win10

Piotr Ładoński — Thu, 20 Oct 2022 20:45:25 +0000

...or even like WinXP (at least in terms of functioning 😉)

Looking at Feedback Hub and Tech Community shows how incredibly users hate Windows 11... or at least its taskbar. Among several issues with it, I definitely miss combining buttons the most. Although seems like Microsoft is doing something with the taskbar, combining buttons is still not possible. Unless we know the proper tool. Let's see, how easily can we transform this

into that

Explorer Patcher

As Windows 11 doesn't natively give any option to extensively modify the taskbar, we have to use a third-party tool - Explorer Patcher. To get it, just go to its GitHub repository releases, expand Assets of the newest version and download ep_setup.exe. Then just install using defaults, it doesn't have many options to choose from. Your screen should blink and File Explorer should restart.

Proper settings

To customize your taskbar using Explorer Patcher, right-click the taskbar and open Properties. At the top of the right panel you want to choose Taskbar style*: Windows 10. Then, at the bottom make sure that Combine taskbar icons on primary/secondary taskbar is set to Never combine (default).

After that, in the bottom left click Restart File Explorer. Again, screen will blink and you should see a completely different taskbar; the one you know from Windows 10.

Taskbar like Windows XP

Personally, I really liked the behaviour of the taskbar in Windows XP - icons to launch the applications on the left, tabs with currently open windows on their right. Let's do it in Windows 11.

Before anything, as we're about to move things around, make sure your taskbar is unlocked. Right-click on it and check if Lock all taskbars doesn't have a checkmark next to it. If it does, select it to "untick".

Start with some cleanup and unpin all the current icon shortucts from the taskbar. It should be empty. Something like this on the screnshot

Toolbar with custom shortcuts

Then, we will need a folder with shortcuts which should appear as the app launcher icons on the taskbar. Create the folder wherever you want and put some shortcuts in it. I called mine... Taskbar (sic!) and placed 5 shortcuts in there.

Now, we'll connect the folder with the taskbar. To do this, right-click on the taskbar, expand Toolbars and click New toolbar at the bottom. Now just select the folder with your shortcuts. Tadaaa!

Tadaaa...? Not yet. Things are not where they should be. Also, this "Taskbar" name is not really necessary. And if you drag the handle to the left, you'll see that icons don't look as you probably want.

Customizing the toolbar

Let's solve those problems one by one:

Title

To remove the title, simply right-click it and uncheck Show title

Shortcut names

Similarly, to hide those long names, right click somewhere on the toolbar and uncheck Show Text

Icon size

To make things aesthetically fine, icons on tabs with open apps should have the same (or at least similar) size as the launcher icons on the toolbar. To adjust the first, use Taskbar icon size option in Explorer Patcher properties and set it to Large (it should be fine by default). To adjust toolbar icon size, right-click on it, expand View (at the top of the context menu) and select Large icons

Position

That's the most complex thing and will require advanced programming skills combined with the extensive knowledge of the registry.
Ok, just kidding 🙂 It's not that hard, but probably the least intuitive. To move the toolbar to the left, so it appears on the left side of the open apps, you just have to brute-force it 😉 Grab the handle and pull it to the left as much as possible, until the app icons "jump" to the right:

To finish up, just adjust width of the toolbar and lock all the taskbars.

Bonus - shortcut to File Explorer

There must be some simple way to create a shortcut to File Explorer, but I couldn't find it at all. If you also need it, just

Right-click anywhere on the desktop and select New > Shortcut
As the location type C:\Windows\explorer.exe
Name it as "File Explorer"
Voila, after double clicking the shortcut it should open the File Explorer

I hope you found it useful and everything worked as it should. If not, let me know 🙂
To be honest, this whole process is way more cumbersome than it should be. Also, I'd prefer to have the small icons in the toolbar, but I couldn't find a way to make the icons of the open apps the same size. If you know any way of achieving that, I'd be happy to hear about it 🙂
Thank you for reading! ❤️

Vue 3, PWA & service worker

Piotr Ładoński — Sun, 03 Jan 2021 17:07:45 +0000

Recently I started playing with Vue. Of course, starting with "hello world" calculator with well-documented Vue 2 was not an option, so I decided to go with simple PWA in Vue 3. Setting up a project wasn't as easy as it may appear, so I'll describe it here for anyone interested (and future reference for myself).

I'll describe everything from (nearly) scratch, so hopefully it'll be of use for complete beginners. I will not explain philosophy of Vue, PWA or service workers - it will be just about setting those things up.

I'm using Win10, so I'll describe the process from this PoV (however, it matters only for Node installation).

Node, npm and Vue

As with all JS projects, it's simpler to do it with Node & npm.

If you don't already have them, I recommend installing Node with nvm. Probably the easiest way is just going here, downloading latest nvm-setup.zip, extracting and running the installer. After that, you should be able to use nvm in your command prompt. If you want to install latest stable version just go with:

nvm install latest

For some particular version you can execute

nvm install 15.4.0

Then, remember to use it!

nvm use 15.4.0

With Node, npm should be automatically installed as well. For me, Node version is 15.4.0 and npm is 7.3.0.

To make our lives easier, there's also Vue CLI which helps with setting up the project. Install it with:

npm install -g @vue/cli

It will allow you to use vue command from your terminal. For me, vue --version returns @vue/cli 4.5.9.

Now, we can start with our mini-project.

Creating project

Creating a new project with Vue CLI is extremely simple. Just go with:

vue create our-app-name

Then using arrows just select the options. I picked:

Manually select features

and then selected with spacebar Progressive Web App (PWA) support. Press Enter to continue, then choose Vue version to 3.x, ESLint with error prevention only, Lint on save, In dedicated config files, type n and press Enter to generate the project (it will take 1-2 minutes).

Of course you can choose different options. Only PWA support is necessary

Running it

Generated project is runnable out of the box. First of all, remember to navigate to the created project folder, then run development server:

cd our-app-name
npm run serve

Output should give you addresses where you can access your generated app. For me it's http://localhost:8080/ (if you want to stop it, just CTRL+C it)

Note that currently service worker is not working - if you go to Application > Service worker in DevTools you won't see it. Generated project makes service worker active only in production build. Let's check it.

To create a production build, run

npm run build

Give it some time and it will create dist directory in your project folder. Now you need to host it somewhere. I'd recommend Web Server for Chrome, as it's very easy to use and works fine (I tried also Python simple http server, but it didn't work correctly for me, so watch out for that). Just select your dist folder in the server and run it. At http://127.0.0.1:8000 you should be able to access your site. Now you can find information about service worker in the Application tab of DevTools and see some console logs about it.

Taming service worker

That's great! Everything works! So what's the problem? Problem appears, when you want to control caching with service worker by yourself and check it during development without constantly creating production builds.

I'll show 3 things now:

How to run service worker in development server
How to control cache behavior
How to use external modules in production build

SW in dev server

Quick warning - SW is disabled in development by default, because it may cache some newly edited scripts/assets and you won't be able to see your changes. Keep that in mind and disable SW in dev if you don't need it to avoid "Why it doesn't change?!" problems.

Another warning - it's probably not the best, most optimal way to do that... but it's simple and works :)

Case: we want to have service worker active in development mode and be able to control its caching policy.

Not diving into details, let's make it happen.

First of all, you need to install serviceworkerW-webpack-plugin in your project:

 npm install -D serviceworker-webpack-plugin

Then in root of your project (next to src folder) add new file vue.config.js with that content:

// vue.config.js

const path = require("path");
const ServiceWorkerWebpackPlugin = require("serviceworker-webpack-plugin");

module.exports = {
  configureWebpack: {
    plugins: [
      new ServiceWorkerWebpackPlugin({
        entry: path.join(__dirname, "./src/service-worker.js")
      })
    ]
  }
};

and modify src/main.js to include those lines (before createApp):

// src/main.js

// other imports...
import runtime from "serviceworker-webpack-plugin/lib/runtime";

if ("serviceWorker" in navigator) {
  runtime.register();
}

// createApp...

Finally, add service-worker.js in src with some "Hello world" content:

// src/service-worker.js

console.log("Hello world from our SW!");

and run the dev server

npm run serve

When you navigate to your app in a browser you should see the message from service-worker in the console. Success!

Controlling caching - Workbox

Writing SW from scratch may be interesting... but let's make it simple and use Workbox for that. It's already installed, so you just need to import it in the SW script. I'm not going to explain everything from the below snippet, because it's done very clearly on Getting started page of Workbox. It's just example of setting specific rules for data matching some RegEx (images in that case).

// src/service-worker.js

import { registerRoute } from 'workbox-routing';
import { StaleWhileRevalidate } from 'workbox-strategies';
import { Plugin } from 'workbox-expiration';
import { precacheAndRoute } from 'workbox-precaching';

precacheAndRoute(self.serviceWorkerOption.assets);

registerRoute(
    /\.(?:png|gif|jpg|jpeg|svg)$/,
    new StaleWhileRevalidate({
        cacheName: 'images',
        plugins: [
            new Plugin({
                maxEntries: 60,
                maxAgeSeconds: 30 * 24 * 60 * 60, // 30 Days
            }),
        ],
    })
);

Just brief comment about that precacheAndRoute line - self.serviceWorkerOption.assets comes from that serviceworker-webpack-plugin we installed before and contains all the statics assets in our app.

Now, even if you are in development mode, you should see some workbox logs in the console. On the first page load it will be

and on subsequent something like that

If you go to Network tab in DevTools and simulate offline mode, the app should still load properly.

Great! Two problems solved - we have granular control over our service worker and it works in development mode.

Fixing SW on prod

In the meantime, unfortunately we messed up the production version of the app. If you run npm run build and look at it, it may seem fine at the beginning, but it's not. First of all, on subsequent refreshes you can see

New content is available; please refresh.

log all the time, although you don't change anything. Also, if you check Application tab, you will see two service workers all the time - one active, the second one waiting to activate. Even if you force the update, there will be another waiting after the refresh.

Issue comes from double registration - one SW is registered in main.js, the second one comes from generated registerServiceWorker.js. That's the problem I wasn't able to overcome in good way, but I came up with two acceptable solutions:

If you don't care about that logging coming from registerServiceWorker.js, just don't import it in src/main.js and problem will be gone.
If you want to keep those console logs, but are fine with having SW working only on prod (but keep the control of caching rules) and with a bit more complex way of importing modules in SW, it requires a bit more effort: Firstly, change vue.config.js contents to:

module.exports = {
  pwa: {
    workboxPluginMode: "InjectManifest",
    workboxOptions: {
      swSrc: "src/service-worker.js"
    }
  }
};

then revert changes you made in src/main.js (i.e. remove anything related to serviceworker-webpack-plugin). Finally, you need to change src/service-worker.js to NOT use import and use precaching with different argument. If you want to use some external modules, use importScripts with CDN link (momentjs below for example; usage is stupid but demonstrates way of doing that). Note how workbox names are expanded now:

importScripts('https://momentjs.com/downloads/moment.min.js');

workbox.precaching.precacheAndRoute(self.__precacheManifest);

const cacheExpTime = moment().add(1, 'day');
const cacheTimeLeft = moment.duration(cacheExpTime.diff(moment())).asSeconds();

workbox.routing.registerRoute(
    /\.(?:png|ico|gif|jpg|jpeg|svg)$/,
    new workbox.strategies.StaleWhileRevalidate({
        cacheName: 'images',
        plugins: [
            new workbox.expiration.Plugin({
                maxEntries: 60,
                maxAgeSeconds: cacheTimeLeft, // 1 day
            }),
        ],
    })
);

Surely there's some 3rd option, which lets you keep logging and everything else, but I don't know, how to configure Webpack properly. If you have any simple solution, I'll be more than happy to read about it in the comments :)

Conclusion

If you want very simple caching technique and keeping handling only static assets by service worker is fine, the generated project is definitely enough. However, if you want more control over your service worker to cache ex. API calls, you need to tweak it somehow. I hope that above tips, how to do that and how to handle the development mode will be useful.

As said, it's definitely not the best and only solution. It's just a starter option for some Vue newbies (like me) to deal with service workers in a reasonable way.

Windows Terminal conda

Piotr Ładoński — Tue, 26 May 2020 00:27:15 +0000

What's the problem?

If you code in Python you've probably encountered the problem of different dependencies required in different projects. Not to search very far, some projects still require Python 2.X to run, while the other work only with Python 3.X.

Probably on of the first solutions which comes to mind is having some sort of 'environments' for different modules/interpreters. With such an approach you can just switch between different 'environments' when you need it. For example you can have an "Convolutional Neural Networks Environment" with a Tensorflow + OpenCV and "Data Analysis Environment" with Pandas + Matplotlib. Then you can just switch/activate one of them when you need it. Sounds nice, isn't it?

conda to the rescue!

Fortunately, you don't have to create some fancy bash/PowerShell scripts by hand to do this. Creators of conda have already solved the problem! It enables you to do the exact things described above - create individual, isolated environments with different packages or even whole different Python interpreters. What makes it even better is its popularity and community support.

conda vs Miniconda vs Anaconda

When you'll start looking for some "conda installation guide" you'll immediately face the problem of those 3... things above. What is it all about? To keep it short:

conda is just a package management system. Something like apt-get, chocolatey or brand new winget. It facilitates installation & management of different packages

miniconda is already pre-built and pre-configured collection of the packages. To make it as small as possible, it contains only conda + its dependencies. If you want to have other packages, you'll need to download them individually with conda

anaconda is similar to miniconda, but the collection of the pre-installed packages is much bigger. You can still download some packages using conda, but probably you won't have to if you are just starting and using some common ones.

Here's a super-short miniconda quickstart

Download proper installer and install miniconda (when in doubt, choose the recommended options).
Run Anaconda Prompt from Start menu. A terminal window should appear with something like (base) D:\Desktop>. That (base) prefix indicates that you're currently using base (default) conda environment.
To check, what packages are installed in that environment: conda list
To create a new "superNewEnv" environment: conda create --name superNewEnv
To install SciPy in this environement: conda install --name superNewEnv scipy
To activate an environment: conda activate superNewEnv. You can always see your active environment at the beginning of the prompt (like that base at the beginning).
Now, if you run Python inside the superNewEnv environment you'll be able to use SciPy. What's even better, it can be used only there, the base environment is not cluttered.
Check out the docs or cheatsheet to dive deeper.

But I want my terminal!

The minor issue with conda is its interoperability with your typical command line or PowerShell. conda commands won't work there, only in its special prompt. However, it can be partially solved with the new Windows Terminal. I won't describe all its features here, but you should definitely check it out. The thing which is interesting for us right now is its concept of profiles. In short, they are preconfigured different ways of launching command line, terminal or whatever you call it.

After installing and launching the terminal, go to its settings by clicking an arrow on the tab bar:

The settings don't have any GUI yet, it's just a JSON file you can modify. Therefore they'll open in some default JSON editor (VS Code in my case).

In the file look for profiles property. It has a list of different profiles created by Windows Terminal automatically. We'll just one more to that list.

What's special about miniconda prompt?

If you examine a bit the thing you're launching from the start menu, you'll discover that the shortcut just runs a cmd/PowerShell with some arguments:

%windir%\System32\cmd.exe "/K" C:\Users\%USERNAME%\miniconda3\Scripts\activate.bat C:\Users\%USERNAME%\miniconda3

(to find it out yourself, search for Anaconda prompt, click it with right mouse button, "Open File location" and check the properties of the shortcut).

Now let's have that prompt in our Windows Terminal! It boils down to adding another profile which will launch the cmd/PowerShell as shown above. Just add another element to the list in profiles:



{
    "guid": "{2337f50b-bd5c-4877-b127-d643395b8fe2}",
    "hidden": false,
    "name": "Miniconda",
    "commandline": "powershell.exe -ExecutionPolicy ByPass -NoExit -Command \"& 'C:\\Users\\%USERNAME%\\miniconda3\\shell\\condabin\\conda-hook.ps1' ; conda activate 'C:\\Users\\%USERNAME%\\miniconda3' \""
}

There are 3 things wort mentioning here:

Value of GUID does not matter. Just make sure it's unique among all the profiles
Value for commandline differs a bit from the one above, as I decided to use PowerShell instead of cmd
Watch out for backslashes and escape all of them + quotemarks properly!

Final touches

The new profile "Miniconda" should be available in the terminal dropdown. Just to make it a bit prettier

Let's add the conda icon!

First find some version of it you like (ex. that one). Save it somewhere on your machine and add icon field to the Miniconda profile:
"icon": "path\\to\\your\\icon.png"
Always display "Miniconda" in the tab name.

Add "suppressApplicationTitle": true to the profile.

Final result:

Final profile settings:



{
    "guid": "{2337f50b-bd5c-4877-b127-d643395b8fe2}",
    "hidden": false,
    "name": "Miniconda",
    "suppressApplicationTitle": true,
    "commandline": "powershell.exe -ExecutionPolicy ByPass -NoExit -Command \"& 'C:\\Users\\%USERNAME%\\miniconda3\\shell\\condabin\\conda-hook.ps1' ; conda activate 'C:\\Users\\%USERNAME%\\miniconda3' \"",
    "icon": "%OneDrive%\\Pictures\\Saved Pictures\\conda.png"
},

PS.
To make your terminal look prettier check out that blog post by Scott Hanselman

Starting with DevOps on minigame project

Piotr Ładoński — Wed, 20 May 2020 12:42:52 +0000

DotFall

DotFall is a super simple game inspired by an older mobile game, Rapid Roll (remake can be found here). You just fall down and try to reach the highest score you can! Watch out, because the longer you play, the faster you fall!

I did it as a part of Faculty Open Day at my University. The game was a small competition. Its participants were supposed to get the highest score, take a snapshot of it and win some small prizes.

Should work well on desktop browser as well as mobile.

Demo Link

Go to the website and play by clicking/tapping left or right side of the screen to move the ball.

Link to Code

Voodu / dot-fall

Simple 2D game in Typescript using Phaser.io

DotFall

Simple game written using Phaser 3 and Typescript Main aim is to fall with the ball as long as you can.

To build the game, run npm install in project root and then

gulp for one-time production build with minifying and obfuscating
gulp watch for continuous watching for changes (useful for development)

To launch the game, open created dist/index.html
Build process is poorly configured, so after adding new file to src your need to restart gulp.

Gulp tasks

bundle - creates uglified and obfuscated bundle.js file in dist directory from all .ts files in src
copy-html - copies all .html files from src to dist
copy-css - copies all .css files from src to dist
copy-assets - copies assets folder from src to dist
copy-other - copies .png,.xml,.ico,.svg,.webmanifest files from src to dist (favicon files)
copy-all - runs copy-html…

View on GitHub

How I built it

The idea for DotFall is super simple so I decided to learn some basic DevOps¹, CD and other auto-magic stuff with that. I also wanted to make it bug-free and really playable by the users (not some I-will-fix-that-later project).

The game itself is written in Phaser framework. Natively it's written in pure JavaScript and personally I prefer using TypeScript. So that's my small success #1 - with help from our uncle and cousin I made Phaser work with TypeScript.

The second thing I was quite satisfied with was configuration of gulp - I've never used it before, but after some messing around with it I managed to successfully use it in the project to automate all the building, bundling etc.

After everything was coded and worked more or less okay, it was time for publishing. I wanted to make it as smooth as possible. First of all I'd set up an App Service on Microsoft Azure to host the content of my game. The best part of it was the ease of usage - I could just publish the changes directly from my VS Code and it worked!

The last step was to have some sort of CD. As I'd used Azure for hosting, I've decided to use Azure Pipelines for easier integrations. After some struggle, playing with YAML files and other weird configuration it finally worked! After pushing changes to the master branch, code was processed by the pipelines (gulp bundling included), then automagically detected by Azure and reflected on the live page. Full success! 😁

To complete the tech stack topic - I'm not that console-freak type, so I've used GitKraken to help me with "gitting around" 🙂

Additional Thoughts

I have a small challenge for you - try to break the game and set the high score by hand! The game has no backend (I promise!) so the score is somehow stored on your machine. I tried the manual modification to be as hard as possible (to prevent cheating in the competition), but, obviously, it can't be prevented completely by client side-only application.

Currently, if you want to build something similar (static website with CD from GitHub), I'd definitely recommend checking out 🆕 Azure Static Website 🆕. It does most of the things I did above out of the box.

DevOps only. The code itself is a mess 😅 ↩

DEV Community: Piotr Ładoński

Spotify Connect, Raspberry Pi, AirPlay & HomePod - because simple audio setups are boring

General idea for Raspberry setup

Installing things

Raspotify

Owntone

Pipes

Configuration

Raspotify

Owntone

Running everything

General troubleshooting

Summary

Chrome extension 101 - implementing an extension

Intro

Idea

General technical approach

Implementation

Needed permissions in manifest.json

Managing offscreen documents

Message interface

Sending messages from the service worker

Receiving the messages by offscreen document

Summary

Chrome extension 101 - environment setup

Voodu / chromium-extension-boilerplate

Chromium extension boilerplate

Brief intro to extensions

Creating a simple extension

Files

Activating the extension

Page-Audio extension environment setup

Autocomplete in manifest.json

TypeScript

Basic config

Adding chrome types

import and export

Dev Tools for service worker

Summary

Blazor, dotnet CLI, VS Code & Tailwind - how to set that up?

Creating the project

Empty solution and Blazor Web App project

"Shared" class library

Connecting things - adding to solution and referencing

VS Code setup

Debugging

Hot Reload

CSS library

Bootstrap

Tailwind

Summary

Handling theme change in MS Teams app with Blazor

The problem

JavaScript approach

Blazor approach

Starting code

Calling JS from Blazor component

Calling C# from JS

Windows 11 - making taskbar like Win10

Explorer Patcher

Proper settings

Taskbar like Windows XP

Toolbar with custom shortcuts

Customizing the toolbar

Title

Shortcut names

Icon size

Position

Bonus - shortcut to File Explorer

Vue 3, PWA & service worker

Node, npm and Vue

Creating project

Running it

Taming service worker

SW in dev server

Controlling caching - Workbox

Fixing SW on prod

Conclusion

Windows Terminal conda

What's the problem?

Needed permissions in `manifest.json`

Autocomplete in `manifest.json`

Adding `chrome` types

`import` and `export`