Forem: David Rickard

Thread-safe async location fetching in Swift

David Rickard — Sun, 27 Oct 2024 16:03:22 +0000

The APIs to get the current location are a bit awkward. I've never liked callback APIs, so I wrap them in proper async calls whenever I find them.

Using a continuation is the first step, and it gives you an async method to call. However, this just hangs indefinitely if you have the misfortune of calling it on a non-UI thread.

To get a proper version, you have to ensure it's executed on the main thread. This is what I came up with:

import Foundation
import CoreLocation

@MainActor
class OneTimeGeoLocationUtil: NSObject {
    static func getLocation() async -> CLLocationCoordinate2D? {
        let oneTimeLocationService = GeolocServiceInternal()
        return await oneTimeLocationService.getLocation()
    }
}

private class GeolocServiceInternal: NSObject, CLLocationManagerDelegate {
    private let manager = CLLocationManager()

    private var continuation: CheckedContinuation<CLLocationCoordinate2D?, Never>?

    override init() {
        super.init()
        manager.delegate = self
    }

    func getLocation() async -> CLLocationCoordinate2D? {
        if !CLLocationManager.locationServicesEnabled() {
            return nil
        }

        return await withCheckedContinuation { continuation2 in
            continuation = continuation2
            manager.requestLocation()
        }
    }

    func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
        if let location = locations.first {
            continuation?.resume(returning: location.coordinate)
            continuation = nil
        }
    }

    func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) {
        // Log the error
        continuation?.resume(returning: nil)
        continuation = nil
    }
}

A one-time use class instance holds the continuation and hosts the callback functions, exposing the raw async API. Then a wrapper static function with @MainActor makes it easier to call and ensures requestLocation() is executed on the main thread.

Data-only FCM push messages on iOS SwiftUI

David Rickard — Tue, 22 Oct 2024 05:04:09 +0000

I was able to figure out how to send data-only FCM push messages to SwiftUI after assembling a bunch of scattered bits of information.

The FCM on iOS guide is a good place to start. Do everything there and come back here to fill in the cracks and finish the data notification implementation.

You'll notice that for SwiftUI it asks you to set FirebaseAppDelegateProxyEnabled to NO in Info.plist. In modern XCode projects this won't be an actual file called Info.plist, it will be the "Info" tab under the your target in the project settings. Also, uncomment all the "if disabling method swizzling" in the example code.

You won't need to call UNUserNotificationCenter.requestAuthorization() to get data messages, only to fire notifications if you decide to when acting on them.

Capabilities

Under Signing and Capabilities in your project you'll need Background Modes -> Remote notifications checked, and Push Notifications added.

Sending messages from the server

After sending your device's FCM token to the server, you can fire off the data messages by calling the FCM v1 HTTP endpoint:

POST https://fcm.googleapis.com/v1/projects/<project_id>/messages:send

{
    "message": {
        "data": {
            "your": "data"
        },
        "token": "abc_def",
        "apns": {
            "headers": {
                "apns-push-type": "background",
                "apns-priority": "5",
                "apns-topic": "com.example.MyApp"
            },
            "payload": {
                "aps": {
                    "content-available": 1
                }
            }
        }
    }
}

token: Your FCM token
apns-topic: Your app's bundle ID

This instructs FCM to create the appropriate request for APNs, as documented in Generating a remote notification.

The apns-push-type header tells it that it can arrive in the background. The apns-priority is 5 because that's required for background notifications. content-available in the payload tells it that it will not be accompanied by any notification, so we don't have any alert, sound or badge keys in the payload.

Handling the messages

I ended up getting the messages on the async method from the example:

func application(_ application: UIApplication,
                     didReceiveRemoteNotification userInfo: [AnyHashable: Any]) async
      -> UIBackgroundFetchResult

Running on Android BOOT_COMPLETED

David Rickard — Mon, 11 Dec 2023 03:59:06 +0000

Hooking into BOOT_COMPLETED is important in Android because that's the only way you can reliably schedule actions to run at certain times. On each boot, all of your actions registered with AlarmManager are cleared away and you need to set them back up again.

However an increasingly large number of Android OEMs block BOOT_COMPLETED by default (Samsung, OnePlus, Huawei, Xiaomi), to prolong battery life on the phone. That is, unless you are lucky enough one of a handful of apps on the default allowlist.

The worst part here is that it's a non-standard permission that the OEMs have stapled onto Android, so there's no standard way to figure out if auto-launch is enabled, and no standard way to request the permissions. There's not even a standard way to open the auto-launch settings activity.

Detection

What can we do? One thing is to be able to detect when BOOT_COMPLETED is being locked. To do this we need a few pieces of information.

1) When was the last time the system booted? SystemClock.elapsedRealtime() provides the answer there. System.currentTimeMillis() - SystemClock.elapsedRealtime() gives you the Unix timestamp in milliseconds.
2) When did the BOOT_COMPLETED receiver last run? You can put this in the receiver:

val sharedPrefs = PreferenceManager.getDefaultSharedPreferences(context)
with(sharedPrefs.edit()) {
    putLong("LastBootReceiverTimestamp", System.currentTimeMillis())
    apply()
}

3) When was the app installed? You can write a similar piece of code to write another timestamp to shared prefs.

You can combine these pieces on app start to figure it out:

val installTimeMs = sharedPrefs.getLong("InstallTimestamp", 0)
if (installTimeMs > 0) {
    val now = System.currentTimeMillis()
    val elapsedSinceBootMs = SystemClock.elapsedRealtime()
    val lastBootTimeMs = now - elapsedSinceBootMs
    val lastBootReceiverTimeMs = sharedPrefs.getLong("LastBootReceiverTimestamp", 0)

    val bootedSinceInstalled = lastBootTimeMs > installTimeMs
    val receiverFiredSinceLastBoot = lastBootReceiverTimeMs > lastBootTimeMs

    // If enough time has passed since device boot that we should have expected the
    // boot receiver to fire, but it hasn't, then we need to ask for auto-launch permission
    if (bootedSinceInstalled
        && !receiverFiredSinceLastBoot
        && elapsedSinceBootMs > Duration.ofMinutes(5).toMillis()) {
        // Auto-launch has been disabled, warn the user
    }
}

Solutions

AutoStarter is a valiant effort, providing an API to help link to the auto-launch settings, that is supposed to encapsulate all the vendor-specific screens that control auto-launch.

It did not work with my OnePlus 8, and even though I found the package and activity I would need to launch, I was denied with a SecurityException. And there are similar crash reports for other devices like Huawei that have locked down the direct opening of this screen. Sadly I don't think it's a good idea to use this, since there doesn't seem to be a great way to work around the security issues or prevent it from throwing exceptions on new phone releases.

I think the only somewhat reliable action you can take is to explain the situation and give a link to open your app's details page, which should hopefully have a way to enable auto-launch there:

val packageName = BuildConfig.APPLICATION_ID
val intent = Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS)
intent.data = Uri.parse("package:$packageName")
startActivity(intent)

The deeper issue

These phone makers are taking these aggressive measures to contain app activity to prolong battery life. I get where they're coming from, but a number of things really bug me about this:

If these measures didn't unreasonably affect app functionality, they wouldn't need to allowlist popular apps.
The allowlists further entrench already successful apps. Would you use a competitor to Whatsapp that often fails to tell you when you've gotten a text? They wouldn't get adoption, so they wouldn't get on the whitelist, so they'd never get adoption.
Having the OEMs all go their own separate way and not through the official Android app model means it's outright impossible to have a smooth permission-granting experience, and extremely difficult to make even a bumpy one.

This article about CTS-D chronicles some heroics to try to bring the OEMs in line and back to sanity. I think the ideal state here is to have good tools to tell you what's taking your battery, and have battery management handled in a central way by the Android app model. Crossing my fingers here; maybe it will be resolved someday.

Dynamic IPv6 DNS updates in Windows with dynv6

David Rickard — Sun, 05 Nov 2023 17:00:38 +0000

I recently spent way too much time trying to solve a basic problem: My IP address at home was no longer static, so all my links kept on breaking. I learned the answer was to use Dynamic DNS. There are a lot of hard and expensive ways to do this, but I found this was the most straightforward.

1) Sign up to dynv6. They will give you a <yourname>.dynv6.net domain name to point to your IP.
2) Go to https://dynv6.com/keys and find your HTTP token.
3) Install DDNS Updater. This is a simple service that can detect your IP and send it to update the IP for your domain name.
4) Under IPv6 update URL, put https://dynv6.com/api/update?zone=yourname.dynv6.net&token=yourtoken&ipv6=%IP% (Replacing yourname and yourtoken).

You can leave everything else blank. DDNS Updater will auto-pick a service to check your external IP. You can set up a CNAME alias if you don't want the domain under dynv6.net.

Using Auth0 with Tauri

David Rickard — Sat, 06 May 2023 21:18:31 +0000

When I first went to integrate Auth0 with my Tauri app, I followed the Electron Auth0 guide.

This approach tells you to create another Electron window and serve the authentication page in it. Then to intercept the callback redirect and extract the code from the URL. I was trying to adapt this to Tauri but running into a wall: You can't intercept navigations for external content in Tauri. 1.3 added an on_navigation handler for the WindowBuilder but that just did not work, and the AppHandle was not accessible from the registered closure.

At this point I just had to back up and figure out how to do this without trying to load the auth page in a WebView. The best practices for a while now have encouraged running authentication through a browser. Authenticating in the browser has a couple of key advantages:

It lets the user re-use signed in state for 3rd party authentication providers like Google/Facebook, potentially eliminating the need for them to type in any username or password
It provides better security for the user because they don't need to type in passwords in an app, which could potentially host a lookalike site that is just harvesting their Google password

Thankfully it turns out it's relatively straightforward to do it correctly here.

Send to the browser instead

The guide tells you how to generate a login URL. Instead of trying to load it ourselves, we need to hand it off to the default browser. From JS you'd use the open from the shell API. From the backend you can use the webbrowser crate.

In the meantime the app can display a message asking them to check their browser and complete the authentication there.

Return URL

You'll need to update the return URL to send you back to your app instead. This URI can be something like myapp:auth, where myapp is your app's registered protocol.

1) Change the return URL embedded in the auth URL, by changing the redirect_uri parameter.
2) Update the Application configuration in Auth0 to allow the new callback URI.

After the authentication succeeds in the browser, it will invoke myapp:auth?code=abc..., which can activate your waiting app.

You can also configure this to callback URL to your own web page, which can then redirect to your app protocol. This way would be the best user experience, as you have a message on this page: "You are authenticated, you may close this tab".

Build the auth URL

Here's a snippet that builds the URL to send to the browser:

pub fn get_auth_url() -> String {
    let audience: String = urlencoding::encode(API_IDENTIFIER).into_owned();
    let scope: String = urlencoding::encode("openid profile offline_access").into_owned();
    let redirect_uri_encoded: String = urlencoding::encode(REDIRECT_URI).into_owned();
    format!("https://{AUTH0_DOMAIN}/authorize?audience={audience}&scope={scope}&response_type=code&client_id={CLIENT_ID}&redirect_uri={redirect_uri_encoded}")
}

Protocol handler

You can use the tauri-plugin-deep-link crate to register your app as a protocol handler. After you get your code, you can exchange it for an auth token in the same manner as the Electron guide, but for Rust you can use reqwest for the HTTP call.

This example uses error_stack, but it should serve as a reference.

#[derive(Deserialize)]
struct TokenExchangeResponse {
    access_token: String,
    id_token: String,
    refresh_token: String,
}

#[derive(Debug)]
pub enum AuthError {
    RefreshTokenMissing,
    Http,
    InvalidUrl,
    InvalidJson,
}

pub async fn load_tokens(&mut self, callback_url: &str) -> Result<(), AuthError> {
    let parsed_url = Url::parse(callback_url).into_report().change_context(AuthError::InvalidUrl)?;
    let hash_query: HashMap<_, _> = parsed_url.query_pairs().into_owned().collect();
    let code = hash_query.get("code").ok_or(report!(AuthError::InvalidUrl))?;

    let token_exchange_body = json!({
        "grant_type": "authorization_code",
        "client_id": CLIENT_ID,
        "code": code,
        "redirect_uri": REDIRECT_URI
    })
    .to_string();

    let client = reqwest::Client::new();
    let response = client
        .post(format!("https://{AUTH0_DOMAIN}/oauth/token"))
        .header(reqwest::header::CONTENT_TYPE, "application/json")
        .body(token_exchange_body)
        .send()
        .await
        .into_report()
        .change_context(AuthError::Http)?;

    let response_text = response.text().await.into_report().change_context(AuthError::Http)?;
    let response_object: TokenExchangeResponse =
        serde_json::from_str(&response_text).into_report().change_context(AuthError::InvalidJson)?;

    // Tokens are in response_object. You can store them here.

    Ok(())
}

Store credentials with keyring

You can store the token with the keyring crate.

The token refresh works the same as in the official guide.

Virtualizing, colored log window in WPF

David Rickard — Fri, 14 Apr 2023 06:50:47 +0000

The problem

A user recently reported that VidCoder would hang in the middle of a long encode. After dusting off WinDbg and some !clrstack and !eestack I found a thread in garbage collection for FlowDocument. We use this in only one place, the log window.

VidCoder has had a colored log window for years, powered by a RichTextBox with a FlowDocument inside:

The document has a single paragraph and we add Runs to that paragraph that contain the actual log entries. At the time I wrote it, it worked great for the length of logs that were typically created. But after I added some optional extended debug logging for the interproc communication, long encodes would cause VidCoder to eat up progressively more memory and eventually lead to the hang inside a GC prompted by FlowDocument memory allocation.

Virtualization

After the log window was implicated, I knew exactly what was going on. UI elements are typically orders of magnitude more expensive than raw data, and the standard answer is virtualization: create the UI elements only for what's in the viewport, then add placeholder space for areas outside the viewport. As the user scrolls, create new UI elements on-demand and clean up the old ones.

The approach

Virtualizing list containers come standard with most UI frameworks, but we couldn't use one here. I also decided I didn't want to just load the entire file up into memory, as the log files could get to be 200MB pretty easily and it would double with .NET's UTF-16 string storage.

I decided I'd break the file up into "chunks", which have a certain number of lines. As you scroll around, read the chunks from the file and add them as Runs in the FlowDocument.

I made an outer ScrollViewer, then the RichTextDocument inside that, and modified the Margin on the RichTextDocument to adjust where it shows up. I used VerticalOffset, ViewportHeight and ExtentHeight on the ScrollViewer for all the viewport logic.

Problem #1: Where are these chunks, even?

Being able to read a chunk from the file means knowing what byte in the file to jump to in order to start reading, and how many bytes to read. But you can't just declare a fixed number of bytes for each chunk, because it might cut right between a line, which would complicate the layout logic. You need to know where the newlines are.

So I figured I'd do an initial pass through the file and read it line by line and note where the chunks are. Normally you do that with a StreamReader in .NET, but the trouble is the byte position in the underlying file is not exposed from it. The StreamReader is a buffered reader, which reads 1024 (usually) bytes at a time, then encodes it to a character array with the specified encoder. It's that character array that the StreamReader advances through. It tracks where it is in that character array, but doesn't expose that publicly.

An answer on StackOverflow provides a creative solution: Go in with reflection and find the current position in the character array. Then look at the remaining (unread) characters that are unread, find how many bytes they would be, according to the current encoder. Then subtract that from the underlying stream position to get the byte position for that base stream.

But relying on reflection is dangerous; refactoring can always break you. In fact, the switch to .NET Core broke that approach. I decided I didn't want to deal with that, so I made my own stripped-down TrackingStreamReader. Since I knew I would only be using UTF-8 with no BOM, I could strip out all the preamble and encoding detection logic. An added BytePosition property gives us the goods:

public long BytePosition
{
    get
    {
        return this.stream.Position - this.encoding.GetByteCount(charBuffer, charPos, charLen - charPos);
    }
}

Now we can compile a list of chunks with proper byte positions!

Problem #2: Variable height lines

Virtualization is much more straightforward when you have fixed height items. You always know exactly how much space you need to insert above and below your real UI items. But in this case, the lines could wrap if they were long enough or the window was small enough.

The answer: measure and guess.

Measure

But nodes inside a FlowDocument don't expose ActualHeight. You have to measure this way:

Rect start = firstRun.ElementStart.GetCharacterRect(LogicalDirection.Forward);
Rect end = lastRun.ElementEnd.GetCharacterRect(LogicalDirection.Forward);

In my case the "end" was always on the blank next line, so I just had to use end.Top - start.Top.

Usually, you can measure immediately after adding the Runs to the UI. That's ideal because you can immediately update the placeholder size and avoid having the UI jump around. But you don't always get it right away; sometimes you get Rect.Empty instead and you need to try again inside a Dispatcher call.

Guess

The chunk map tells you how many lines each chunk has, but you need to translate this to an expected height. That means you need data on what past chunks have actually measured to. We can store a double MeasuredHeight on each chunk to keep track of this, then you can look over all the chunks and get a pretty good guess of the average line height.

Then when calculating the placeholder heights, use MeasuredHeight if you have it, or guess using the average line height if you don't.

But what about resizing?

If the user resizes the window slightly, one potential way to handle this would be to just clear all the MeasuredHeight values and wait for them to be re-measured. But this might cause the content currently in the viewport to vanish as the user resizes. A chunk that might shrink or grow drastically as it reverts back to the estimated height, which could push the content out of the viewport. One approach might be to try and doctor the scroll value based on this shift, but I decided to add another chunk property: bool HeightIsDirty. When you resize, you mark all the chunks with HeightIsDirty. They still count for estimation purposes, but MeasuredHeight is re-calculated the next time the chunk is loaded. That way, scroll position naturally stays stable.

Problem #4: Unloading chunks

When a chunk is too far outside the viewport, we need to remove the Runs associated with it. For this, I added a List<Run> Runs property on the chunk. It also doubles as an indicator if the chunk is loaded or not. The chunk unload logic becomes simple and efficient with RemoveRange:

int firstRunIndex = this.logParagraph.Inlines.IndexOf(chunk.Runs[0]);
this.logParagraph.Inlines.RemoveRange(firstRunIndex, chunk.Runs.Count);

Problem #5: Adding log lines

The log window can naturally have lines added to it after being loaded. After a new message comes in, we actually don't need to do any file operations. The logger has already taken care of writing to the file, and it lets the log window know of the message through an event that it's only subscribed to when the window is open.

But we can't just get the log string here, because we need to update the chunk map in case the user scrolls back up there later. I switched the log writer from a StreamWriter to a FileStream. I'd encode the log entry to bytes manually and write those bytes to the FileStream. Then I could fire the event and include the size in bytes. That way we only need to do the encoding once, and we can keep our chunk map up to date.

When the user is scrolled at the bottom of the log, we keep them there, scrolling down after every new entry is added. But if they've scrolled up a bit, we let new entries accumulate without changing the scroll position, to allow users to inspect whatever they were interested in.

Staying at the bottom

In this case we can add Runs to our paragraph, keeping our chunk map up to date by creating new chunks as needed. The scroll to the end actually triggers our normal scroll handler, which conveniently unloads old chunks without any extra work.

Colors and Run batching

In my log system, lines are marked with the log source and type; and can be colored accordingly. We need to make sure log lines from different sources are in different runs, so we can apply different colors to them. But that doesn't mean that every line has to have its own Run. We can batch up multiple lines within a Run, as long as the log coloring hasn't changed. But we also need to take care not to cross chunk boundaries with a Run, to allow seamless loading and unloading.

This means as log entries come in, they might create a bunch of small Runs, but if you scroll back up to them after the chunk has unloaded, they come back batched into a single Run.

Final result:

Maybe I shouldn't have put most of the logic in one file, but at least it's less than 1000 lines.

AllowSetForegroundWindow quirks

David Rickard — Tue, 04 Apr 2023 05:58:39 +0000

At some point when developing for Windows you may have seen your app try to get focus for itself but end up flashing the taskbar icon instead. As Raymond Chen explains, you can't steal foreground focus.

I've come across a couple of additional quirks with AllowSetForegroundInfo:

Issues when launched from Windows notifications

I discussed this problem in my post on Electron notifications. As I mentioned there, there's a wrinkle for activations from Windows Notifications. When your app is launched from the protocol string in a notification, for some reason calling AllowSetForegroundWindow does not work. Chromium worked around this issue by sending a dummy keypress event.

I created a node package to execute the same workaround for Electron, and then also fixed this in Tauri's deep-link plugin.

Ideally Windows should come up with a fix and make sure that any process launched from a notification can call AllowSetForegroundInfo without having to jump through this hoop.

ASFW_ANY

But there is another oddity I came across. AllowSetForegroundWindow's documentation claims that you can pass in ASFW_ANY and it will allow any process to take foreground focus. When originally trying to implement this workaround, I used this because I wanted to see if it would work at all before switching to the more secure approach of passing in the specific process ID.

But it just did not work at all until I passed in the PID. No shortcuts here. 🫤

Tauri + SQLite

David Rickard — Tue, 04 Apr 2023 05:32:27 +0000

For years, SQLite has been my go-to solution for storing any kind of structured local data for apps. The ability to update multiple pieces of data in a transaction has been extremely useful.

Naturally, when building my app in Tauri, I wanted to use SQLite from my Rust backend code.

A bit of poking around led to Rusqlite for an ergonomic SQLite wrapper.

But there's a couple other questions to answer in order to tie it in with Tauri.

Where do you store the SQLite file?

Inside setup() we can create an app handle and call app_handle.path_resolver().app_data_dir(). That's the designated place to store our app data. From there we can initialize our DB file.

How do we access the `Connection` from a Tauri command?

Tauri has a built-in ability to store app state. We'll set up struct to hold it:

pub struct AppState {
  pub db: std::sync::Mutex<Option<Connection>>,
}

The Mutex protects access to the connection object. The idea is that you get the Connection, run a query on it, then release the Mutex.

In setup() we can populate this app state with the DB connection.

let app_state: State<AppState> = handle.state();
*app_state.db.lock().unwrap() = Some(db);

We can also add a convenience trait to easily access the Connection object without jumping through the State fetch and Mutex lock.

pub trait ServiceAccess {
  fn db<F, TResult>(&self, operation: F) -> TResult where F: FnOnce(&Connection) -> TResult;
}

impl ServiceAccess for AppHandle {
  fn db<F, TResult>(&self, operation: F) -> TResult where F: FnOnce(&Connection) -> TResult {
    let app_state: State<AppState> = self.state();
    let db_connection_guard = app_state.db.lock().unwrap();
    let db = db_connection_guard.as_ref().unwrap();

    operation(db)
  }
}

Inside Tauri commands we can supply a app_handle: AppHandle argument, which will be automatically populated by the Tauri framework. From there we can call our db() trait method on app_handle to do database operations. Anything returned from the closure will be passed through.

let my_result = app_handle.db(|db: &Connection| {
    /* Do something with the DB connection and return a value */
});

I pass the AppHandle through to any other modules that need it, so they also have access to the Connection. You can also call app_handle.clone() in case you run into ownership issues.

Full example code

https://github.com/RandomEngy/tauri-sqlite

Scheduling Windows Notifications from Rust

David Rickard — Sun, 19 Mar 2023 23:27:36 +0000

The windows crate exposes the whole WinRT API surface in Rust and makes it quite easy to send native Windows notifications. One particular handy feature is scheduling notifications for the future, that Windows will deliver even when your app is closed: ScheduledToastNotification::CreateScheduledToastNotification .

One little sticking point is that it requires a Foundation::DateTime to specify the start time, and there don't seem to be any helpers to create one from a chrono or any native Rust date struct. I was able to find in the documentation:

A 64-bit signed integer that represents a point in time as the number of 100-nanosecond intervals prior to or after midnight on January 1, 1601 (according to the Gregorian Calendar).

So the job is to figure out how many 100ns intervals are between your desired time and the WinRT epoch. Then create a DateTime from scratch, passing in this tick count to the UniversalTime property. The full demonstration code is below:

use chrono::{Local, NaiveDateTime, Utc, Duration, TimeZone};
use windows::Foundation::DateTime;
use windows::UI::Notifications::ScheduledToastNotification;
use windows::{Data::Xml::Dom::XmlDocument, UI::Notifications::ToastNotificationManager};

use windows::core::{Result, HSTRING};

fn main() {
    let app_id = "my.app"; // AUMID
    let toast_notifier = ToastNotificationManager::CreateToastNotifierWithId(&HSTRING::from(app_id)).unwrap();

    let toast_xml = create_toast_xml().unwrap();

    let local_time_string = "2023-03-19T16:01:27";
    let winrt_start_time = local_time_to_win_datetime(local_time_string);

    let scheduled_notification = ScheduledToastNotification::CreateScheduledToastNotification(&toast_xml, winrt_start_time).unwrap();
    toast_notifier.AddToSchedule(&scheduled_notification).unwrap();
}

fn create_toast_xml() -> Result<XmlDocument> {
    let toast_xml = XmlDocument::new()?;
    toast_xml.LoadXml(&HSTRING::from("<toast>
        <visual>
            <binding template=\"ToastText01\">
                <text>Testing</text>
            </binding>
        </visual>
    </toast>"))?;

    Ok(toast_xml)
}

fn local_time_to_win_datetime(local_date_time: &str) -> DateTime {
    // First parse the time into a timezone-agnostic local time.
    let naive_time: NaiveDateTime = local_date_time.parse().unwrap();

    // Convert the naive local time to the system time zone, preferring earlier if ambiguous.
    // If there was no local time there, go back an hour and try again.
    let date_time = Local.from_local_datetime(&naive_time)
        .earliest()
        .unwrap_or_else(|| Local.from_local_datetime(&naive_time.checked_sub_signed(Duration::hours(1)).unwrap()).earliest().unwrap());

    let winrt_epoch = Utc.with_ymd_and_hms(1601, 1, 1, 0, 0, 0).unwrap();

    let microsecond_timestamp = date_time.timestamp_micros() - winrt_epoch.timestamp_micros();

    DateTime {
        UniversalTime: microsecond_timestamp * 10
    }
}

Using error-stack with Tauri

David Rickard — Thu, 09 Mar 2023 21:44:50 +0000

The problem

Rust's built-in error handling is rather bare-bones and requires a whole lot of effort to preserve a proper stack trace, where other languages give you that for free.

In order to show the inner error along with your error, you need to wrap the inner error explicitly:

#[derive(Debug)]
enum ServiceError {
    Json(serde_json::Error),
    Http(reqwest::Error),
}

You then need to implement Display with case arms for each enum:

impl fmt::Display for ServiceError{
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match *self {
            ServiceError::Json(..) =>
                write!(f, "Could not parse the JSON"),
            ServiceError::Http(..) =>
                write!(f, "The HTTP call failed"),
        }
    }
}

And then implement From to allow the inner error types to convert to your error:

impl From<serde_json::Error> for ServiceError {
    fn from(err: serde_json::Error) -> ServiceError {
        ServiceError::Json(err)
    }
}

impl From<reqwest::Error> for ServiceError {
    fn from(err: reqwest::Error) -> ServiceError {
        ServiceError::Http(err)
    }
}

Basic error-stack support

The error-stack crate makes this a lot better. Its error is a Report, which stores the chain of errors it's encountered. That means you can define an error like this:

#[derive(Debug)]
struct ServiceError;

impl fmt::Display for ServiceError{
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        f.write_str("There was an error calling the service.")
    }
}

impl Error for ServiceError{}

Then convert the error with into_report():

use error_stack::{Result, IntoReport};

fn parse_it(value: &str) -> Result<(), ServiceError> {
    let parsed: serde_json::Value = serde_json::from_str(value)
        .into_report()
        .change_context(ServiceError)?;
    println!("We parsed: {}", parsed);

    Ok(())
}

The into_report() packages up an outside error into a Result, and change_context() adds our own error type as another link in the error chain. You can add another link by calling change_context() again with a different error type. No more annoying From implemenations!

The Report prints out beautifully with all information:

Error: experiment error: could not run experiment
├╴at examples/demo.rs:51:18
├╴unable to set up experiments
│
├─▶ invalid experiment description
│   ├╴at examples/demo.rs:21:10
│   ╰╴experiment 2 could not be parsed
│
╰─▶ invalid digit found in string
    ├╴at examples/demo.rs:19:10
    ├╴backtrace with 31 frames (1)
    ╰╴"3o" could not be parsed as experiment

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

backtrace no. 1
   0: std::backtrace_rs::backtrace::libunwind::trace
             at /rustc/e972bc8083d5228536dfd42913c8778b6bb04c8e/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1: std::backtrace_rs::backtrace::trace_unsynchronized
             at /rustc/e972bc8083d5228536dfd42913c8778b6bb04c8e/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2: std::backtrace::Backtrace::create
             at /rustc/e972bc8083d5228536dfd42913c8778b6bb04c8e/library/std/src/backtrace.rs:332:13
   3: core::ops::function::FnOnce::call_once
             at /rustc/e972bc8083d5228536dfd42913c8778b6bb04c8e/library/core/src/ops/function.rs:250:5
   4: core::bool::<impl bool>::then
             at /rustc/e972bc8083d5228536dfd42913c8778b6bb04c8e/library/core/src/bool.rs:71:24
   5: error_stack::report::Report<C>::from_frame
             at ./src/report.rs:288:25
   6: error_stack::report::Report<C>::new
             at ./src/report.rs:274:9
   7: error_stack::context::<impl core::convert::From<C> for error_stack::report::Report<C>>::from
             at ./src/context.rs:83:9
   8: <core::result::Result<T,E> as error_stack::result::IntoReport>::into_report
             at ./src/result.rs:203:31
   (For this example: additional frames have been removed)

You can attach other bits of arbitrary data to the report as well.

Tauri integration

Tauri will not let you directly return a error_stack::Result from a #[tauri::command]. If you try, it will complain:

no method blocking_kind on type &Result<(), Report<ServiceError>>

Tauri lets you return anything that implements Serialize, but a Report does not. To get around this we can use a wrapper:

#[derive(Debug, Serialize)]
pub struct CommandError(String);

impl<C> From<Report<C>> for CommandError {
    fn from(err: Report<C>) -> CommandError {
        CommandError(format!("{:?}", err))
    }
}

impl fmt::Display for CommandError {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        f.write_str(&self.0)
    }
}

That allows us to easily map our Reports to an error type that Tauri can send to the frontend:

#[tauri::command]
async fn call_the_service() -> core::result::Result<(), CommandError> {
    my_module::call_service().await?;
    Ok(())
}

That will be visible in the Dev console for the frontend page. {:?} is the debug format that includes all error information; if you want to obfuscate for production, you'll want to use {:#}.

Dependency Injection with Vite and TypeScript

David Rickard — Mon, 16 Jan 2023 16:16:26 +0000

Writing a cross-platform web app means you need to bundle different code with each platform. I discussed the approach with Webpack and NormalModuleReplacementPlugin in an earlier post.

In Vite you can do this in vite.config.ts:

import alias from '@rollup/plugin-alias';

...

plugins: [
    {
      enforce: 'pre',
      ...alias({
        entries: [
          {
            find: /\/MainRepository$/,
            replacement: '/TauriRepository',
          },
        ],
      }),
    },
],

This would find any module called MainRepository and swap it out for the TauriRepository module in the same folder.

enforce: 'pre' is important here, otherwise Vite has already run its pipeline and it's too late. If you're just using Rollup without Vite then you should be able to use the alias entry directly.

Dynamic generation of task bar overlay icons in Electron

David Rickard — Thu, 29 Dec 2022 23:31:49 +0000

Electron exposes the ability to show an overlay icon on the taskbar. It's incredibly flexible: allowing you to show any image you want there. But in my case, I just wanted a circle with a number in it to represent the number of unread items.

Pre-generating a bunch of images to bundle with the app didn't seem very appealing, so I settled on a dynamic generation approach:

1) Create an in-memory <canvas> element in the renderer code.
2) Draw the circle and the number in the center of it.
3) Call canvas.toDataURL() and pass this string to the main process via IPC.
4) Create a NativeImage from the data URI.
5) Call BrowserWindow.setOverlayIcon and pass in the NativeImage.

We do the generation in the render process because it has access to Canvas APIs for free.

Here's the code to generate the Data URI:

export function renderTaskBarOverlay(count: number): string {
  if (count > 99) {
    count = 99;
  }

  const canvas: HTMLCanvasElement = document.createElement('canvas');
  canvas.width = 32;
  canvas.height = 32;
  const ctx = canvas.getContext('2d');
  if (!ctx) {
    throw new Error('Could not get context');
  }

  const textY = count > 9 ? 24 : 25;
  const fontSize = count > 9 ? 20 : 24;

  ctx.beginPath();
  ctx.arc(16, 16, 16, 0, 2 * Math.PI, false);
  ctx.fillStyle = '#007A5D';
  ctx.fill();

  ctx.font = `${fontSize}px sans-serif`;
  ctx.textAlign = 'center';
  ctx.fillStyle = 'white';
  ctx.fillText(count.toString(), 16, textY);

  return canvas.toDataURL(); // Defaults to PNG
}

The Electron docs say that this is a 16x16 icon, but I think that must be device-independent pixels they are using because 32x32 looked a lot better on my 4k monitor.

Once it gets to the main process, you can handle it:

export interface TaskBarOverlay {
  imageDataUri: string;
  description: string;
}

ipcMain.on('setOverlay', (event: Event, overlay: TaskBarOverlay | null) => {
  if (overlay) {
    const image = nativeImage.createFromDataURL(overlay.imageDataUri);
    mainWindow.setOverlayIcon(image, overlay.description);
  } else {
    mainWindow.setOverlayIcon(null, '');
  }
});

mainWindow.on('closed', () => {
  ipcMain.removeHandler('setOverlay');
});

And that's it. I was a bit surprised how little code was needed for this.

Forem: David Rickard

Thread-safe async location fetching in Swift

Data-only FCM push messages on iOS SwiftUI

Capabilities

Sending messages from the server

Handling the messages

Running on Android BOOT_COMPLETED

Detection

Solutions

The deeper issue

Dynamic IPv6 DNS updates in Windows with dynv6

Using Auth0 with Tauri

Send to the browser instead

Return URL

Build the auth URL

Protocol handler

Store credentials with keyring

Virtualizing, colored log window in WPF

The problem

Virtualization

The approach

Problem #1: Where are these chunks, even?

Problem #2: Variable height lines

Measure

Guess

But what about resizing?

Problem #4: Unloading chunks

Problem #5: Adding log lines

Staying at the bottom

Colors and Run batching

Final result:

AllowSetForegroundWindow quirks

Issues when launched from Windows notifications

ASFW_ANY

Tauri + SQLite

Where do you store the SQLite file?

How do we access the Connection from a Tauri command?

Full example code

Scheduling Windows Notifications from Rust

Using error-stack with Tauri

The problem

Basic error-stack support

Tauri integration

Dependency Injection with Vite and TypeScript

Dynamic generation of task bar overlay icons in Electron

How do we access the `Connection` from a Tauri command?