Test Flutter Push Notifications in Every App State

A Flutter push notification needs to work when the app is open, in the background, and starting after its process has ended. Those cases use different delivery and navigation paths. A passing callback test does not show whether tapping a tray item opens the right screen after login and startup have finished. When building a notification feature, I tested those states on an emulator and repeated the send to check duplicate handling. I also checked what happened when the destination was missing or the user had signed out. Each case needed an expected screen and a way to verify how the app reached it.

Choose how foreground messages appear

When the app is visible, the system may not display a normal tray notification. The application must decide whether to show an in-app banner, update state silently, or defer the message. That choice needs to respect whatever modal, celebration, or navigation is already active.

I tested arrival during ordinary home state and during an overlay. A notification that technically arrives but obscures a more important flow is not correct.

Check navigation after a background tap

From the background, the operating system owns presentation and returns control after the user taps. The app must parse a bounded route, restore session state, and navigate only after the router is ready.

I avoided treating a server-provided string as an arbitrary navigation command. The payload maps to known destinations and validates the identifiers required by those screens.

Wait for startup before opening the destination

When the process is gone, notification intent competes with authentication restoration, local storage initialization, and the initial route. If navigation happens too early, the app can lose the target or briefly show the wrong screen.

My emulator walk included swiping the app away, sending the notification, tapping from the tray, and waiting through a clean launch. Screenshots and logs made timing bugs visible in a way a mocked callback could not.

Prevent repeated sends for the same reminder

Retries are normal in notification systems. I added a stored dispatch record keyed by user, notification kind, and date so a repeated job would not send the same reminder twice. Then I deliberately invoked the dispatch again and confirmed only one tray item arrived.

Client-side suppression can improve presentation, but it should not be the only defense. The service that decides to send needs an idempotent record of that decision.

Time zones changed the product rule. Streak and comeback notifications depend on calendar days, not simply elapsed hours. I found that eligibility based on local time could behave differently across devices and server jobs. For that reminder feature, I chose a documented UTC calendar day. Other products may need each user’s local day, so the rule should be agreed before implementation.

Choosing which calendar day counts affects who receives a reminder and when. Teams should define whose day matters before writing a cron expression.

Cover permissions and failure cases

• Foreground arrival with and without another overlay.
• Background tray display and tap routing.
• Terminated tray display and cold-start routing.
• Logged-out or deleted-account behavior.
• Invalid and stale destination identifiers.
• Repeated server dispatch and repeated client delivery.
• Permission accepted, declined, and later changed in settings.

Each case needs an expected visible result and an expected analytics or log trail.

I tested failure as a user experience. Valid delivery is only half the feature. I checked what happens when the destination record no longer exists, the user is signed out, permission is denied, or the notification arrives after the underlying state changed. The app should fall back to a safe screen and avoid exposing a raw exception or looping through login.

I also verified that deleting an account prevents later dispatch and that stale tokens can be retired without blocking other users. Server logs use privacy-safe identifiers and structured event names rather than notification bodies. These cases matter because reminders often arrive hours after the state that created them. By then, a goal may be abandoned, a quest completed elsewhere, or an account removed. Notifications should be treated as hints to re-fetch authoritative state, not as authoritative state themselves.

Analytics events were designed around decisions rather than message content: dispatch attempted, provider accepted, foreground received, notification opened, route resolved, route rejected, and preference changed. That makes delivery gaps diagnosable without copying private notification text into the analytics system. Track provider acceptance, device receipt, and opening separately so failures can be located accurately.

I repeated the highest-risk walks after a clean app restart and after rebuilding the debug package. That guarded against success caused by leftover local state or a hot-reload session. Reproducible setup is part of mobile evidence.

Repeat the flow from a clean app start

Write the expected behavior for each app state before wiring the notification callbacks. Test arrival, display, tapping, navigation, and a safe fallback for missing or unauthorized destinations. Repeat dispatches to verify duplicate protection, and confirm that account deletion stops later sends. Record provider acceptance separately from device receipt and opening. Use an emulator for repeatable checks, then qualify the intended platforms and devices before promising delivery behavior that a mocked callback or a single Android session cannot establish.

Photo by Szabó Viktor on Pexels.