Forem: Technocoder

Finding Distributed Notifications on macOS Catalina

Technocoder — Mon, 13 Apr 2020 16:42:00 +0000

With a new macOS update comes new breaking changes. One particular breaking change on Catalina is how observing distributed notifications works.

But first, what are distributed notifications?

Many people will be familiar with the concept of regular notifications. You know, that alert that pops up somewhere on your screen that gives you some information about something.

A notification generated using AppleScript

Distributed notifications are similar to regular notifications (in fact, they send the same NSNotification structure) but instead of showing them to the user they can be broadcasted to other processes that listen for that particular notification. More generally, distributed notifications are a form of interprocess communication.

What can we use distributed notifications for?

One very useful notification that iTunes issues is the com.apple.iTunes.playerInfo notification. This notification is issued whenever the user changes the state of the current track including when they stop playing or select a new track. Associated with the notification is a bunch of useful fields about the change such as the track name, artist, and total track length.

By registering an observer to this notification I created an iTunes Discord Rich Presence client that automatically updates what song I am currently playing (somewhat similar to Spotify’s Rich Presence).

iTunes Discord Rich Presence

The main benefit of this compared to polling the iTunes player state with AppleScript is that it uses less processor time and is hence more energy efficient.

The problem with macOS Catalina

Catalina replaced the beloved iTunes application with Apple Music (which is incidentally a lot slower and laggier but that is a story for another time). Of course, that means the name of any iTunes related distributed notifications have changed.

The fix is simple. Just replace the old notification name with the new one. One of the parameters for registering the notification observer is:

notificationName

The name of the notification for which to register the observer; that is, only notifications with this name are delivered to the observer. When nil, the notification center doesn’t use a notification’s name to decide whether to deliver it to the observer.

Perfect! All we have to do is leave the name as nil and that will let us listen to all of the distributed notifications. Then we just have to find the one emitted by changing a track.

Code that listens for all distributed notifications

All right, let’s start it up and wait for all the data to pour in.

It certainly looks like it’s running!

Nothing’s happening?

Here is a hint. The problem isn’t with my code. This method does not work on macOS Catalina. The behaviour of the addObserver method has changed so that leaving the name as nil will do nothing if the process is not privileged. Incidentally, running the code under sudo does not seem to make it work either.

Finding the name of the notification

At first I considered two main options:

Tracing the Music application’s system calls
Brute forcing every possible notification name

The former option was quickly ruled out when dtruss (a system call tracer) failed to start due to System Integrity Protection (and I could not be bothered turning it off). The latter option seemed quite feasible but when I did the math:

26 lowercase and 26 uppercase letters
At least ten characters in the name
52¹⁰ is about 144 quadrillion operations

Yeah, that is not going to work.

That is when I realised there was another option that finds a lot of use in reverse engineering: analysing the executable itself. Since the notification name is a string we can use the strings tool to find all the strings in the executable.

To test out my idea I tried running strings on Spotify first. The bulk of the actual executable is located inside of the application bundle at: Contents/MacOS/Spotify. We know that one of Spotify’s notification names is com.spotify.client.PlaybackStateChanged so we can match that against the output from strings Spotify:

Searching for Spotify’s notification

Great! Let us try doing the same with Apple Music now.

On Catalina the Music application is located in /System/Applications. Even though we don’t know the exact name of the notification we can filter out a lot of the strings by matching against com.apple.Music. It seems that all of the notifications have to contain the application’s bundle identifier.

List of strings containing the bundle identifier

One of those names looks suspiciously similar to an iTunes notification. In particular: com.apple.Music.playerInfo. Let’s try it out!

Updated code for a particular notification

Output from the notification listener

Brilliant! We finally get some data printed out. It is a little bit different from the iTunes notification (for example, there is no Display Line 0 field anymore) but fixing that is a comparatively easy task.

In summary

Distributed notifications are a way for different processes to send messages to each other
Catalina breaks using nil as a value for the name parameter in addObserver to listen for all distributed notifications
The strings tool can be used to find a list of potential notification names for an application by filtering against the bundle identifier

Ideally, Apple should update the documentation to reflect this change in behaviour but it seems that it is too niche to warrant a mention. I am just glad I got my Music Rich Presence working again.

Embrace the static typing system: Strong types

Technocoder — Sat, 11 Nov 2017 10:02:52 +0000

The following is about a 3 to 5 minute read.

First, what is strong typing?

It should be noted that "strong typing" isn't really an official technical term. I will however be using the following definition when I talk about strong typing.
Simply put, strong typing is the tendency for a compiler to enforce types and a typing "discipline". Some examples of strongly typed languages (in my opinion) are Haskell, Rust and C++.

The opposite of strong typing is weak typing. Weakly typed languages typically allow us to easily change the type of something or "coax" a type to be something else. For example in C we can force a pointer to become a void* or really any pointer we want.

Strong typing and weak typing aren't mutually exclusive. Instead, it's more of an axis. For example, in most languages we'd almost always find some sort of casting system.

Strong typing should not be conflated with static and dynamic typing. Those two terms refer to when types are checked and enforced. Static typing checks types at compile time whereas dynamic typing checks types at runtime. Static typing is orthogonal to strong typing.

A different way at viewing types

I'm assuming that everyone knows more or less how object oriented programming works. I want to emphasise the difference between what a particular user defined type is and what a user defined type is for. See the following contrived example:

struct Circle {
    radius: f32,
}

impl Circle {
    fn new(radius: f32) -> Circle {
        Circle {
            radius,
        }
    }
}

For those unfamiliar with Rust the "new" function is essentially the same as a constructor.

Notice how I haven't yet replaced "f32" with a user defined type yet. At the moment "f32" describes what the variable radius should be: A float. However, it doesn't describe what it's for. I'll (hopefully) show you what I mean.

fn new(f32) -> Circle {
    // function body
}

That's more or less the function signature. Can you tell, just by looking at that, what parameter we're meant to be putting inside there? It could be the radius, or it could be the diameter or even the circumference. It might not even describe the size aspect of the circle at all!

That's what I mean by "it doesn't describe what it's for". Or in other words, there's no meaning associated with that type. There's already a term for this: primitive obsession, but I don't think it's only applicable to primitives.

This issue is especially prevalent when we actually use this function in code. See the following:

fn main() {
    let some_random_circle = Circle::new(30.0);
}

We have no idea what this code is doing! The "30.0" is entirely meaningless. As said before, it could refer to anything. The only way to find out what's actually happening here is to look inside the "new" function itself.

(We could pull the "30.0" into a separate variable. But as we'll see later on we can fix this in other ways that might be more beneficial. Or you know, read the documentation. Alternatively, if you have a super fancy IDE it will automatically display the parameter name alongside the variable put in. cough cough CLion and Intellij. But generally the problem is we can't just scan over the code and understand what it does)

How we fix this

The way we fix this is actually quite simple. Simply create a new type that describes what 30.0 actually refers to. See the following:

struct Radius {
    radius: f32,
}

impl Radius {
    fn new(radius: f32) -> Radius {
        Radius {
            radius,
        }
    }
}

struct Circle {
    radius: Radius,
}

impl Circle {
    fn new(radius: Radius) -> Circle {
        Circle {
            radius,
        }
    }
}

Now Circle won't let us put anything other than a Radius inside there. There's no way we can mistake that for a circumference or a diameter. Because, the compiler won't let us make that mistake. Here's the updated main function:

fn main() {
    let some_random_circle = Circle::new(Radius::new(30.0));
}

Perfect! Now anyone looking over this code can immediately tell that this is a circle being constructed by a radius value.

Don't forget about diameter and circumference

You could overload the new constructor if you wanted to be able to construct a Circle by Diameter. Unfortunately, Rust doesn't have support for overloading at the moment (as far as I know). The way I fix this is by having Diameter explicitly cast to Radius.

struct Diameter {
    diameter: f32,
}

impl Diameter {
    pub fn new(diameter: f32) -> Diameter {
        Diameter {
            diameter,
        }
    }
}

use std::convert::From;
impl From<Diameter> for Radius {
    fn from(diameter: Diameter) -> Self {
        Radius::new(diameter.diameter / 2.0)
    }
}

fn main() {
    let circle = Circle::new(Diameter::new(30.0).into());
}

(Note that creating a "From" implementation for Radius automatically creates the into() function for any diameter variable. This is considered the preferred way for adding a cast instead of creating a "Into" implementation for Diameter)

As we scan over this code we can still immediately understand the Circle construction. The into() function invocation lets other programmers know that we thought about the code and confirmed that we really do want to convert this Diameter into a Radius.

An additional benefit is that every function that uses Radius no longer has to have an additional function that takes in a Diameter (had we taken the function overloading course). Imagine if we added a Circumference struct. We'd have to go over the entire codebase looking for usages of Radius and create an additional function that takes in Circumference.

Also, if we accidentally used Diameter without the into() invocation the compiler throws us an error (In Rust at least, other languages might implicitly cast it). That's a bug avoided if we really meant to use Radius.

There's no way I have 3000 different shape structs in my library

It's true that up until now I've been using a very contrived example. I can't imagine the average programmer creating a shape struct/class each time they write a program. It's time to show a real world example.

This example actually came up during the development of the game I'm working on. I was creating a virtual windowing system so that there would be separate windows inside of my game window. Additionally, I had to manage coordinates carefully so that I don't confuse my virtual windows and the real window. Here's what initially happened:

// Somewhere inside the depths of my MainMenu state
fn event(&mut self, event: &Event) {
    Event::MouseButtonPressed {x, y, ..} => {
        let cursor_position = some_function_that_uses(x, y);
        if let Some(position) = self.virtual_window.on_mouse(cursor_position) {
            if self.button_inside_virtual_window.contains(cursor_position) {
                // Do something cool
            }
        }
    }
}

Some of the variable and function names have been changed for clarity. Anyways, have you spotted the logic error yet?

The "contains" function is being passed "cursor_position" when in reality it was meant to take in "position" (The variable inside "if let Some(position) = ..."). Worse yet, I had even thought of this possibility and it still took me a good while to understand why my button was being activated halfway across the window.

Here's how I added two structs so this could never happen again:

struct RawPosition {
    x: f32,
    y: f32,
}

impl RawPosition {
    // Some constructor for RawPosition

    fn force_virtual(self) -> VirtualPosition {
        VirtualPosition {
            x: self.x,
            y: self.y,
        }
    }
}

struct VirtualPosition {
    x: f32,
    y: f32
}

impl VirtualPosition {
    // Some constructor for VirtualPosition
}

// some_function_that_uses(x, y) now returns a RawPosition
//
// on_mouse(cursor_position) now takes in a RawPosition and
// spits out a VirtualPosition
//
// contains(cursor_position) now takes in a VirtualPosition

Now if we try to run the same code from before the compiler throws us an error. We can't pass in a RawPosition to a parameter that's a VirtualPosition! Bug avoided.

What's the deal with the force_virtual function then? Well, I don't always want to draw a button onto a VirtualWindow. Sometimes I want to draw it onto the real window. In cases like those I don't need to process the RawPosition data. However, the compiler won't let us use it (if it did, that would defeat the entire purpose of this article) so we have to create a function that converts it.

I name it force_virtual because it lets other programmers know that I have thought this through and I really do want to convert RawPosition to VirtualPosition.

Conclusions

Strong typing may not be best for you. If you're working in a language where structs/classes have an impact on runtime performance you might want to consider the tradeoffs between safety and performance.

Strong typing won't suit everything. In my real world example I had to weigh how often I would draw a button in a virtual window instead of the real window. However, I highly recommend using it if you can. It can help to avoid a lot of headaches early on and improves readability. Let the compiler do as much work for you as it can.

I'm not very experienced in Rust (or programming in general although I guess it's relative) but I'll try my best to answer any questions you all may have. Otherwise, if you've made it this far, thanks for reading!

Resolving the game state machine cyclic dependency

Technocoder — Sun, 05 Nov 2017 04:39:01 +0000

If you've been making (or trying to make) games for any amount of time, it's likely you've seen and used the state machine. Here's a minimal implementation in C++:

class State {
    StateMachine* stateMachine;
public:
    virtual void onEnter() {}
    virtual void onExit() {}
}

class StateMachine {
    std::stack<std::unique_ptr<State>> states;
public:
    void push_state(std::unique_ptr<State> state) {
        states.top()->onExit();
        states.push(std::move(state));
        states.top()->onEnter();
    }
    void pop_state() {
        states.top()->onExit();
        states.pop();
        states.top()->onEnter();
    }
    void change_state(std::unique_ptr<State> state) {
        states.top()->onExit();
        states.pop();
        states.push(std::move(state));
        states.top()->onEnter();
    }
    State& peek() {
        return *states.top();
    }
}

The pointer inside the State class allows itself to access methods from the StateMachine class. This is particularly useful in game development.

Say if you were designing a platformer game. You could have a MainMenu state, a InLevel state, and a Settings state. In order for the MainMenu state to be able to transition to the InLevel state it needs to access the change_state method.

The problem is we have a cyclic dependency here! StateMachine needs to know about State for it to call its onExit and onEnter methods (and more). State needs to know about StateMachine so it can change the current states.

The works well enough in C++ but it poses a huge problem in Rust (which is what I'm creating my game in). See the following code:

pub trait State {
    fn event(&mut self);
    fn update(&mut self, state_manager: &mut StateManager);
    fn draw(&self);
}

pub struct MainMenuState {}

impl State for MainMenuState {
    fn event(&mut self) {}
    fn update(&mut self, state_manager: &mut StateManager) {}
    fn draw(&self) {}
}

pub struct StateManager {
    states: Vec<Box<State>>
}

impl StateManager {
    pub fn new(initial_state: Box<State>) -> StateManager {
        StateManager {
            states: vec![initial_state],
        }
    }

    pub fn peek(&mut self) -> &mut Box<State> {
        return self.states.last_mut().expect("StateManager is empty");
    }
}

fn main() {
    let mut state_machine = StateManager::new(Box::new(MainMenuState{}));
    state_machine.peek().update(&mut state_machine);
}

That's my attempt at replicating the state machine in Rust. If we compile this code we get the following error:

error[E0499]: cannot borrow `state_machine` as mutable more than once at a time
  --> src/main.rs:33:38
   |
33 |     state_machine.peek().update(&mut state_machine);
   |     -------------                    ^^^^^^^^^^^^^- first borrow ends here
   |     |                                |
   |     |                                second mutable borrow occurs here
   |     first mutable borrow occurs here

I'd just like to point out how awesome Rust's error messages are. None of that cryptic stuff that I find with C++ compilers.

If you aren't too familiar with Rust, here's the gist (no, not a Github gist) of what's happening. Rust only allows you to have one piece of code modifying the same variable at the same time (a mutable borrow). This's so it can find and prevent data races at compile time. We modify the state_machine variable when we use the peek method from StateManager and when we use the update method (which modifies the StateManager it's given).

At this point I decided to change the structure of the code instead of "fighting the borrow checker".

Somehow I needed a way to notify the StatesManager to change its states without doing so directly. That means the code responsible for notifying the StatesManager couldn't be the State struct.

I do this by making the State struct return a Rust enum that signifies whether it wants to change the current states. The StateManager would then change the states depending on the value of the enum.

Rust makes this especially easy because you can "attach" any value to any enumeration. See the following:

pub enum StatesRequest {
    PushState(Box<State>),
    ChangeState(Box<State>),
    PopState,
    None,
}

pub trait State {
    fn event(&mut self);
    fn update(&mut self) -> StatesRequest;
    fn draw(&self);
}

fn main() {
        let mut state_manager = StateManager::new(Box::new(MainMenu{}));
        let request_status = state_manager.peek().update();
}

Now State doesn't need to know anything about the StateManager. The only dependency it has is the StatesRequest enum. Whenever it wants to change the state it just needs to create a new instance of StatesRequest with the State added in the enum.

// Inside the MainMenuState impl
fn update(&mut self) -> StatesRequest {
        if userPressedStartGame {
            return StatesRequest::ChangeState(Box::new(InLevel{}));
        }
}

Here's the rest of the modified code:

impl StateManager {
    pub fn new(initial_state: Box<State>) -> StateManager {
        StateManager {
            states: vec![initial_state],
        }
    }

    pub fn update_states(&mut self, states_status: StatesRequest) {
        match states_status {
            StatesRequest::PushState(state) => {
                self.states.push(state)
            },
            StatesRequest::ChangeState(state) => {
                self.states.pop().expect("StateManager is empty");
                self.states.push(state);
            },
            StatesRequest::PopState => {
                self.states.pop().expect("StateManager is empty");
            },
            StatesRequest::None => ()
        }
    }

    pub fn peek(&mut self) -> &mut Box<State> {
        self.states.last_mut().expect("StateManager is empty")
    }
}

fn main() {
    let mut state_manager = StateManager::new(Box::new(MainMenu{}));

    // The following code would be in some sort of loop
    let request_status = state_manager.peek().update();
    state_manager.update_states(request_status);
}

Hurrah! No more compile errors and we remove the cyclic dependency.

This was easy enough to do in Rust (owing to it's fantastic enums) but can we do it in C++?

Absolutely. It does look slightly different though:

struct StatesRequest {
    std::unique_ptr<State> new_state;
    enum Type {
        PUSH,
        POP,
        CHANGE,
        NONE
    } type;
}

(I've grown a slight liking to snake case instead of camel due to Rust)

Feel free to ask any questions you may have. I'll try my best to answer them but I'm not a Rust or C++ expert (or a program design expert) by any means. Otherwise, thanks for reading!