Skip to main content

Remote Push Notifications

Work in progress

Remote notification registration and delivery are not a completed, verified end-to-end integration. The 16 October 4.1 source includes payload handling, registration-failure and callback work; the Windows receive handler remains empty, and provider/device validation remains open. See the reconciled platform table. No published Wisej-4-Hybrid-PushNotifications package was found on NuGet on 1 October 2026. The older Wisej 3 install recipe and DeviceRemoteNotification snippet are not a supported 4.1 setup.

For application-scheduled notifications, start with Notifications and the core DeviceLocalNotification reference. Local notifications do not require an APNS or FCM server.

How Remote Push Notifications Work​

  1. The native client requests permission and registers with Apple Push Notification Service (APNS) or Firebase Cloud Messaging (FCM).
  2. The provider returns a device token. The application sends the token to its own authenticated server and updates it when it changes.
  3. The server sends a notification through the provider using its server credentials.
  4. The native client processes receipt and user interaction, including foreground, background and cold-start cases.

These are platform requirements, not evidence that the current Hybrid source completes each step. Provider credentials, Apple entitlements and provisioning, Android Firebase configuration, and OS permissions must be configured for the actual application.

Setup​

There is no verified NuGet-only setup to recommend for the current Notifications extension. Maintainers working from source must align both extension assemblies with the core runtime and register the native middleware. The current Wisej-facing source uses the namespace Wisej.Hybrid.Notification, DeviceNotifications.RegisterForRemoteNotifications(), and DeviceNotificationsInfo.RemoteToken. Token and notification events are exposed on the information module, rather than on the obsolete DeviceRemoteNotification type.

Do not treat these source API names as a ready-to-run recipe. Verify the complete bridge, registration failures, payload shape, token refresh and view subscription lifecycle first.

NuGet Packages​

See Extensions for the package pairs that are published. No replacement push package ID is proposed here.

Register Client Extension​

Client registration alone does not implement provider setup or close the delivery gaps. Follow the source version under test and validate the provider configuration for that application.

Registering for Push Notifications​

The former registration snippet used types and events that do not match the current extension. Use the source API names described above only in a source-based integration under test; no verified complete registration example is available yet.

Processing Push Notifications​

Acceptance testing must cover denied permissions, failed provider registration, refreshed tokens, payload delivery while the app is open, delivery while backgrounded, and opening the app from a notification. Test on the intended physical devices with the application's signing and provider configuration.

Platform Capabilities describes the current limits. Notification work is tracked for maintainers in Hybrid issue #13, which requires access to the private repository.