State and Notification Broker APIs in Windows Mobile 6.5

The State and Notification Broker (often abbreviated as SNAPI) in Windows Mobile 6.5 provided developers with an efficient, event-driven architecture to track dynamic device states and system-level property changes. Instead of continuously polling the operating system for updates—which drained battery and consumed processor cycles—applications could register interest in specific system properties, such as battery status, signal strength, or incoming calls, and automatically receive notifications the moment those properties changed.

Architecture and Data Storage

The State and Notification Broker stored system states inside the Windows Mobile registry under dedicated keys, primarily:

  • HKEY_LOCAL_MACHINE\System\State
  • HKEY_CURRENT_USER\System\State

These keys contained subkeys for hardware components, networking configurations, and telephony features (e.g., Phone, Battery, Connections). Device drivers and system services updated these registry values whenever a hardware state or system context changed.

How Applications Listened for Changes

Developers could register to listen for state changes using either native C++ APIs or managed code via the .NET Compact Framework.

1. Native API Implementation

In native C++, the broker relied on a set of core functions provided by the Windows Mobile SDK:

  • RegistryNotifyWindow: Routed state change notifications directly to an application's window procedure (WndProc). When registering, the application supplied the target registry root key, subkey, value name, window handle (HWND), and a custom window message ID. When the value changed, the OS dispatched that message to the window.
  • RegistryNotifyMsgQueue: Used point-to-point message queues (CreateMsgQueue). This was the preferred approach for background worker threads or console-style services that lacked an active user interface or window message loop.
  • RegistryNotifyCallback: Allowed an application to specify a direct callback function or an event handle to be signaled upon state modification.

2. Managed Code (.NET Compact Framework)

For managed applications, Microsoft exposed SNAPI through the Microsoft.WindowsMobile.Status namespace via the SystemState class.

Instead of working with low-level registry handles, managed developers instantiated a SystemState object referencing a predefined property (e.g., SystemProperty.PhoneIncomingCall or SystemProperty.PowerBatteryStrength). The class exposed a standard .NET Changed event:

SystemState incomingCall = new SystemState(SystemProperty.PhoneIncomingCall);
incomingCall.Changed += new ChangeEventHandler(OnIncomingCallChanged);

Under the hood, the runtime mapped these events directly to the native SNAPI notification queues.

The Notification Lifecycle

  1. Registration: The application specified the key to monitor and the delivery mechanism (Window message, message queue, or .NET event). The broker created an internal listener hook linked to that registry path.
  2. Detection: An external event occurred (e.g., cell tower connection changed). The relevant system driver updated the corresponding key in HKEY_LOCAL_MACHINE\System\State.
  3. Dispatch: The State and Notification Broker intercepted the registry write and checked its list of active registrations. If an application was subscribed, the broker immediately sent the update payload to the registered target.
  4. Consumption: The app received the update, extracted the new value, and executed the required application logic.
  5. Deregistration: When the monitoring was no longer needed or when the app closed, it called RegistryCloseNotification (or disposed of the SystemState object) to free system handles and prevent memory leaks.

Benefits of the Broker Model

  • Power Efficiency: Eliminating continuous polling allowed mobile processors to stay in low-power idle states longer, drastically preserving battery life.
  • Low Latency: State changes were delivered almost instantaneously, allowing user interfaces to reflect real-time network drops, battery warnings, and telephony events.
  • Centralization: All components—from third-party apps to internal OS shells—relied on the same standardized state repository, ensuring uniform system behavior across Windows Mobile 6.5 devices.