Sverre

Code Wallet: My first published android app

2026-07-30T00:00:00+00:00

Short version: I built a simple and small Android app for storing barcodes and QR codes on my phone.

Google Playstore</a></li> </ul>
Long version</h2>
In January this year I started using a "dumber" Android phone as my main phone. A Duoqin F21 Pro, running DumberOS (A lineage fork based on Android 14). I still intend to write a blog post about it and my experiences, but I have procrastinated that for more than six months and see no reason to stop now. Most apps I used before work surprisingly well, but as the phone does not have a NFC chip, Google Wallet is a no-go. Which is completely fine, as I am very slowly trying to pull my life out of Big G's clammy hands. But a genuinely useful feature of Google Wallet is adding all your loyalty cards and similar in the app. I find it very convenient to have everything in one app instead of one per store.
I found myself wanting an alternative, but every app I tried either sucked, tried to do everything, was bloated with ads or just plainly unusable on my new phone. So I ended up making my own. I haven't touched Android development for over 13 years, but I have used Kotlin professionally, and after asking Claude to scaffold me an Android app with Gradle and all that faff I loathe, I was off to the races.
Small</h2>
One of my biggest gripes with the alternatives I surveyed was that they all were in the range of several megabytes in size, some up to 50 megabytes. My first and most important goal with this project was that the app would be less than one megabyte. Keeping the used dependencies to a minimum is an increasingly important factor in software development these days, so this would be a win in several ways. The only dependency is ZXing, for the actual barcode encoding and decoding, since reinventing that particular wheel was a bridge too far (although probably an interesting project in its own right...).
The finished app weighs in at 211 KB, and this pleases me quite a lot.
</div>
Fast</h2>
The other design goal of this project was making the app fast. The F21 Pro is very limited hardware-wise, and standing in the checkout and then having to wait for the blasted codes to load was something I wanted to avoid. Researching techniques to make apps fast was a rabbit hole, but since the feature scope was quite limited, and I also made it lightweight via the size goal, there was not a whole lot I could tune.
The Application</code> class does essentially nothing on startup: the repository (and the SQLite file behind it) is opened lazily, so the database isn't touched until the first screen actually queries it, after the first frame is already on screen. onCreate()</code> in the launcher activity just inflates the layout and wires up listeners, the actual data loading happens in onResume()</code>, so nothing blocks the first paint.
Testing hurdles</h2> Having used the app myself for a while, and feeling pretty good about it, I figured I might as well publish it on Google Play (and eventually F-Droid, I just have to figure out how.) Turns out that writing the app was the easy part. The song and dance of publishing wants a privacy policy (for an app with no internet permission where everything stays on your device...), screenshots in several shapes and sizes, a content rating questionnaire, and a closed testing period with a minimum of 12 active testers held for a minimum of 14 days before it lets you go public. The play console is a masterclass in poor UX design, and while not as horrible as the GCP console, it is a close second. Google seems to assume that developers do not need good UX. Google is also incredibly nebulous about the testing phase, as what constitutes an "active" tester is not explained anywhere. Word on the street is that the testers need to test the app for at least 15 seconds each day in order to qualify. And even if you do complete the testing, you still might be required to test the app further. As my app is very small in scope, testing it that much for two weeks feels utterly silly. The whole thing can be explored in two minutes. Add to this that I would be hard pressed to count 12 friends that are Android users AND would be willing to spend time every day to test my app AND are tech savvy enough to opt into the testing process, I ended up looking for alternatives.There is of course a subreddit</a> for this, but my post advertising for testers had very limited response. I did, however, come across an app called App Hive which aims to tackle this problem by grouping users into "hives" of 17 (there will be some dropouts) users where everyone is required to test the other users' apps each day for 14 days. While extremely tedious, this worked well enough and I was finally approved for production. Hooray 🎉 I get that some sort of filter is needed with the (probable) influx of low-effort AI generated apps and malware. But I feel the process should be a lot simpler to understand, and that it should be graded based on the size of the app, the permissions it require or other factors. I dread having to go through the hoops again, should another app idea pop up.

Rust (and Slint) on a jailbroken Kindle. 2026-05-26T00:00:00+00:00 I recently jailbroke my 7th generation Kindle Paperwhite. While my motivation probably should have been "breaking free from Amazon's clammy and tightening grip", the truth is I wanted a way to use it as a clock on my nightstand. I found this project</a> and figured I could just make some adjustments to the code. And that worked fine. But as I now had opened the door, I started thinking about if I could get Rust to work on the Kindle as well. Maybe I could do more useful stuff with it? As I have recently started to tinker with Home Assistant and smart devices again, the idea of a dashboard for some of the features could be a fun project. And while there are probably many perfectly fine projects out there, I haven't made any of those. Telling a programmer there's already a library to do X is like telling a songwriter there's already a song about love. -Pete Cordell </blockquote> Cross compiling Rust for the Kindle</h2> After some research I found out that I needed to target ARMv7 and musl libc. I have dabbled with Rust on ARM machines</a> before, and know from painful experience that getting the Rust compilation toolchain to work on such low-powered devices is a non-starter. Luckily there are great tools for cross compilation. My go-to for cross compiling Rust is, rather ironically, cargo-zigbuild</code>. The Zig compiler ships with musl libc sources and headers built in, for all supported architectures. It also has its own linker, so zig cc can act as a complete cross-compile toolchain for any musl target, on any host. Compiling for the Kindle becomes as easy as: * Installing Zig * Installing cargo-zigbuild * cargo zigbuild --release --target armv7-unknown-linux-musleabihf</code></pre>Getting shell access on the Kindle</h2> With my hello-world-app ready and built, I needed a way to get it on the kindle and run it. While I probably could have used KUAL which I installed during the jailbreaking process, I wanted to also be able to see stdout to verify my application actually works. After some digging I found the USBNetwork tool that allows for setting up SSH access to your device either via USB or Wifi. For convenience I added an entry in my sshconfig and copied over my public key. Note: ssh-copy-id did not work for me, I had to add my .pub file to /mnt/us/usbnet/etc/authorized_keys</code> on the Kindle. Hello, World! Now what?</h2> With shell access in order I was able to confirm that my cross compilation toolchain did indeed work, "Hello, World!" showed up as expected. But a program that prints to stdout readable over SSH is not much help on a Kindle. As Rust has matured, quite a few</a> GUI libraries have sprung up. Personally, I only have experience with Slint, so that is what I reached for. Could I get it to work on the Kindle? From my experience with getting Slint to run on a Raspberry Pi I knew the ARMv7 platform was supported out of the box. The missing links would be output to the e-ink screen and input from the touch panel. We have visual!</h2> Slint supports various renderers and backends, including a handy and lightweight software renderer that works on basically anything. By supplying a LineBufferProvider</code> that implements process_line()</code> we are able to take one by one line of rasterized visual output, convert it to grayscale and write it to the framebuffer, that on my Kindle is just a file at /dev/fb0</code> that we have memory mapped. I love the linux philosophy of "everything is a file" sometimes. Now the only thing left to do is to notify the driver to refresh the display, which is how e-ink works. This is done via the libc crate with ioctl()</code> (input/output control). We pass in the dirty region to be refreshed, handily provided by Slint internals. Touch me here, touch me there</h2> With pixels on the screen, the other half of the puzzle is getting the touch panel to talk to Slint. And again the "everything is a file" mantra comes to the rescue: the touch controller shows up as /dev/input/event1</code>, and we can just read()</code> from it. Each read gives us back a struct that the kernel has written directly into our buffer: a timestamp, an event type, a code, and a value. No parsing, no protocol, just a memory layout we have to match. The Kindle uses the Linux kernel's multi-touch protocol type B</a>, which means events arrive as a stream of "the X coordinate is now this", "the Y coordinate is now that", "the tracking ID is now this" and then a SYNC_REPORT event that says "okay, that batch is done, you can act on it now". So we accumulate the latest X, Y and tracking ID as events come in, and on each SYNC_REPORT we figure out what to dispatch to Slint. A tracking ID of -1</code> means the finger lifted, which becomes a PointerReleased</code>. Otherwise, the first sync after a touch-down becomes a PointerPressed</code>, and any subsequent ones become PointerMoved</code>. Slint handles the rest. It actually works!</h2> After a lot of debugging of no visible output, screen not refreshing, double refresh flashes, touch input not registering, touch input registering twice and lots of more bugs I had a counter and a increment button. With an seemingly working (at least for my specific device, it will probably need adjustments for other Kindle versions) kindle-backend for Slint, I extracted the relevant code into a separate crate and published it on crates.io</a>. With that in order, I just need to draw the rest of the owl (dashboard). That will be another time. Docxide-template: Type safe docx templates with code generation in Rust 2026-02-26T00:00:00+00:00 Short version: I built a Rust proc-macro library that generates type-safe structs from Word .docx templates, turning placeholders into compile-time checked fields. Github</a></li> Crates.io</a></li> </ul> Long version</h2> My previous job was as a software consultant, and at one of the places I was deployed they handled lots of legal documents. These documents would be generated by an in-house case management software written in Java. The templates for these documents were MS Word .docx files and were pulled in from a separate repo at build time. The separation here was for organizational purposes, but the legal people who managed the templates were trained in using git so they could deal with all template-related things. But the software that essentially filled out these templates needed to know about where to insert things like names, addresses and legal details. This was done via some XML-files containing information about the placeholders in the corresponding .docx, and whatever Java-details needed to link this together. This was tedious to work with, and error prone. An update to either file and not the other could result in errors, like runtime faults at best, or placeholders finding their way into a finished document at worst. It was also essentially "stringly typed", no type system guarantee that things would work at all. A case for Rust</h2> I enjoy Rust for many reasons, and the strong type system is one of them. The notion that "bugs shouldn't compile" resonates with me. And while the chances I could convert a Java shop in the public sector to Rust were slim, I figured that making a type-safe .docx templating library would be a fun project that someone out there might find useful. The ecosystem of a language is an important factor when choosing a technology stack. If I can move the needle a little bit on the "corporate friendly" scale that would be a small win for Rust adoption. My design goals were pretty straightforward: The library should be super easy to use. No manual wiring or glue code.</li> The .docx-files should essentially be a part of the source code.</li> Any addition or removal of the template placeholders would incur a compilation error.</li> </ul> Macros</h2> One of Rust's super powers is metaprogramming with macros. From the official book: Procedural macros allow you to run code at compile time that operates over Rust syntax, both consuming and producing Rust syntax. </blockquote> Not having worked with macros before, it felt a bit daunting, but I figured the best way to learn to swim is to jump in. After a few cold starts, some research into what other templating libraries do, a complete rewrite, and a long hiatus, I released version 1.0.0 of Docxide-template. So how does it work? The consumer places .docx template files in a folder, and points the macro to it. The macro is executed at compile time, and traverses the files. It generates structs where template placeholders become struct fields. The file name becomes the PascalCased struct name, and the placeholders become snake-cased field names. Like so, for a HelloWorld.docx template: use docxide_template::generate_templates; generate_templates!("path/to/templates"); fn main() { let doc = HelloWorld { first_name: "Alice".into(), company: "Acme Corp".into(), }; doc.save("output/greeting").unwrap(); // alternatively, output the filled template as bytes: doc.to_bytes() }</code></pre> The generated structs expose two methods, save()</code> that saves the filled out template as a .docx file, and to_bytes()</code> which outputs the raw bytes if the document is to be further processed before saving. Like converted to a PDF, or streamed to another service. Baked in bytes</h2> One way things can break with this setup is that the template files can be changed after compilation, like on the server or in whichever production environment it is deployed. Depending on how the build and distribution pipeline of a theoretical consumer of this library is set up, this may or may not be a problem. But the template files will have to be distributed with the compiled binary in order to work. My second goal was for the .docx-files to essentially be a part of the source code. So as an alternative feature that can be toggled, the processed templates can also be baked directly into the binary. This ensures that the templates can't be changed accidentally (or maliciously), and makes the built application more portable. The only reason I have this as opt-in rather than opt-out is that someone might have thousands of template files, and that can balloon the binary size quite fast. Firefox Extension: Recently Used Tabs Indicator 2026-01-17T00:00:00+00:00 I made a Firefox extension to make my life a tiny bit easier. I have dabbled in this before, but I have never published one. I have a problem with tabs. I often end up with too many open, and often several from the same site. So when I switch to a different tab to check something, and I want to go back, I am stuck scanning through a sea of tiny favicons trying to remember which one I just left, as the title becomes truncated. So I made a Firefox extension that tracks the 5 most recently used tabs and adds visual indicators to the start of the titles. The most recent tab gets a red circle 🔴, the next one an orange circle 🟠, and so on. This makes them stand out and easy to spot. The extension is available on the Firefox Add-ons store</a>, and the code is on GitHub</a>. And yes, I know that Firefox has an option to have ctrl</code>+tab</code> cycle through recently open tabs, but I have never gotten used to using that for some reason. That is probably the best solution, but it is nice to have options. How it works</h2> A background script tracks tab activation events per window and maintains a recency list. When you switch tabs, it sends messages to content scripts that modify the document titles by adding prefix indicators. Each browser window maintains its own independent tracking. There are several indicator styles to choose from: simple numbers, colored circles, colored squares, moon phases, or define your own custom indicators. Ideally I wanted to rather color the tabs with different hues, or add some other kind of styling, but this is currently not possible, and the issue</a> on this possible feature is nine years old... Permissions</h2> The extension requires access to all websites to modify tab titles, which looks scary in the permissions prompt. The code only reads document.title</code> and adds a prefix, nothing invasive. But browsers do not have a more granular permission for just modifying titles. Tabs that are already open when you install or reload the extension will not get indicators until you navigate somewhere. This is because content scripts are automatically injected only when pages load. Auox: A Terminal banking client 2025-12-27T00:00:00+00:00 Short version: I made a terminal banking client for my personal banking needs with Rust, Ratatui and the open and customer facing APIs of my bank. I call it Auox, short for Aurum Oxidatum, a pseudo-latin name for gold oxide</a>, or "gold rust". The code is on GitHub</a> if you want to take a look. The application looks like this: