Skip to main content

Handle notification opens

A useful notification opens the relevant part of your app. Define a small payload contract between your sender and mobile clients, and keep the actual resource data behind your authenticated API.

Define a navigation payload​

The extras fields below are an application-owned convention:

{
  "screen": "order_details",
  "resource_id": "order_1042",
  "notification_id": "notice_5081"
}

Maintain an allowlist of supported screen names. Treat resource_id as a lookup reference, then fetch the current resource using the signed-in user's permissions. A notification does not grant access to the order.

Connect platform callbacks​

On Android, handle the notification-open callback for your pinned JPush SDK and pass validated navigation data to your app router. On iOS, handle the notification response through the registered delegate, report the notification to JPush as required, and complete the system callback.

Some Android manufacturer channels use a distinct click-delivery configuration. Verify the path for each channel enabled for your app, particularly when the app process was not running.

Handle cold start and signed-out users​

Store a pending route while the app initializes. If authentication is required, complete sign-in before fetching the target resource. Once the destination is ready, consume the pending route so a lifecycle retry does not repeatedly open the same screen.

If the resource no longer exists or the current account lacks access, open a neutral screen with a clear explanation. Avoid showing cached private content from the previous signed-in account.

Verify navigation​

Test a tap while the app is open, in the background, fully stopped where the platform permits delivery, and signed out. Also test an unknown screen name, a stale resource, and repeated callbacks for the same notification.

Provider references: JPush Android documentation and iOS notification API. The payload convention on this page belongs to your application.