Voice Command

Voice Command turns the vehicle’s physical voice-command button into a normalized event your tweak can handle. This page covers the event path, the event types to expect, and the routing rules that keep one press from firing several tweaks.

Purpose

Voice Command exposes events originating from the vehicle’s physical voice-command control to supported third-party tweaks. It lets you use a control the driver already has under their thumb as an input for application-specific functionality.

For example, a tweak may receive the vehicle voice button event and use it to activate a voice interface inside Google Maps or another supported application.

Your tweak does not need to interface with the vehicle hardware. DuoDash handles the vehicle-facing side and exposes a normalized event.

Event flow

The general event path is:

Vehicle
    │
    │ Physical Voice Command Button
    ▼
CarPlay / Vehicle Interface
    │
    ▼
DuoDash
    │
    ▼
Voice Command Core
    │
    │ normalized event
    ▼
Third-Party Tweak
    │
    ▼
Application-Specific Action

Example: application voice activation

A common behaviour a third-party developer might want:

User presses voice button on steering wheel
                │
                ▼
DuoDash receives vehicle event
                │
                ▼
Voice Command Core dispatches event
                │
                ▼
Google Maps integration tweak receives event
                │
                ▼
Tweak activates Google Maps voice search

Conceptually:

// Illustrative example only.

[[DDVoiceCommand sharedInstance]
    registerHandler:^(DDVoiceCommandEvent *event) {

        if (event.type == DDVoiceCommandEventPress) {
            [GoogleMapsIntegration activateVoiceSearch];
        }
    }];

The actual API may use Objective-C protocols, C callbacks, notifications, IPC messages, Darwin notifications, XPC, or another DuoDash-specific transport mechanism, depending on the final implementation.

Event types

Depending on what the vehicle and CarPlay environment expose, DuoDash may normalize events such as:

Press
Release
Long Press
Double Press

The official SDK will define which events are supported.

Event consumption and routing

The Voice Command API will define whether an event is:

• Broadcast to all registered tweaks.
• Routed only to the active application.
• Routed to the currently selected provider.
• Consumable by one handler.
• Allowed to propagate after being handled.

Follow the routing rules DuoDash defines, and do not globally intercept vehicle controls unless it is genuinely necessary. The recommended conceptual behaviour:

Vehicle Event
     │
     ▼
DuoDash determines eligible handler
     │
     ▼
Active application integration
     │
     ▼
Handler accepts event
     │
     ▼
Application action

This is what stops several tweaks from all responding to the same steering-wheel button press.

Full integration example

Registration guarded by availability and capability checks, with the application action dispatched to the main queue:

// PSEUDOCODE — NOT FINAL DUODASH API

static void HandleVoiceCommand(DDVoiceEvent event)
{
    switch (event.type) {

        case DDVoiceEventPress:

            dispatch_async(
                dispatch_get_main_queue(),
                ^{
                    ActivateApplicationVoiceSearch();
                }
            );

            break;

        default:
            break;
    }
}

static void InitializeDuoDashIntegration(void)
{
    if (!DDIsAvailable()) {
        return;
    }

    if (!DDCapabilityAvailable(@"voice-command")) {
        return;
    }

    DDVoiceRegisterHandler(
        @"com.example.voiceintegration",
        HandleVoiceCommand
    );
}

The final DuoDash SDK may use a different mechanism. Note that the handler does not assume it is called on the main thread — see the threading rules on the tweak-writing page.

API reference

To be published when the DuoDash Developer API is finalised. It will cover the Voice Command header, handler registration and removal, the event structure, and the event routing rules.

Next: registering a tweak, provider lifecycle and the release checklist →