A notification may arrive after the underlying task has changed, or may not arrive at all. An agency can connect a push service successfully while leaving these product cases unresolved. Define the event's useful lifetime, the information safe to display and what happens when the user opens an old alert.
Related service: Mobile application development- 01Create a scoped event
- 02Send with useful expiry
- 03Open with identity checks
- 04Refresh the current record
SECTION 01
Define what the alert means
Separate a reminder, a status update and a request for acknowledgement. Decide whether repeated updates should replace an earlier alert or remain individually visible. Choose minimal lock-screen content where details are sensitive. The receiving screen should validate both the current account and the referenced record.
Firebase's delivery documentation explicitly distinguishes an accepted message from a delivered one and describes expiry behavior. Android's notification guidance covers presentation and interaction. These platform capabilities do not establish your business semantics; the agency needs an agreed rule for stale events and an observable result when a user acts.
SECTION 02
Illustrative example: a changed appointment
A customer receives a reminder for an afternoon appointment while their phone is offline. The appointment is later moved with the customer's agreement. When the device reconnects, an old reminder must not invite them to act as though the original time is still current.
The notification uses an appropriate expiration policy, and opening any surviving alert loads the current appointment. The screen explains that the time changed rather than silently showing unrelated information. If the appointment was canceled, it presents that state. The example does not assume push ordering or delivery is guaranteed across devices and providers.
SECTION 03
Test the alert after the world changes
During acceptance, delay delivery, duplicate an event, sign out before opening it and remove the target record. Test permission disabled, foreground app use and a new device registration. Confirm that an old user's notification cannot expose another account's details after account switching.
Request event types, expiration rules, delivery diagnostics and token-lifecycle ownership at handoff. A simple in-app activity list may be sufficient for non-urgent updates, with push added as a convenience. Avoid building a critical operating process around an assumption that every alert reaches a person immediately; define an appropriate acknowledgement or alternate workflow where necessary.
SECTION 04
Frequently asked questions
Does a push message ID prove delivery?
No. It commonly confirms provider acceptance. Delivery and user interaction require separate evidence and still have platform limitations.
Can we make every notification permanent?
That often leaves stale information visible. Choose expiry and replacement behavior according to how long the event remains useful.
What if the user turns notifications off?
Keep important tasks discoverable in the app and explain any limitations. Do not treat notification permission as a substitute for a reliable task workflow.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Message lifespan and deliveryFirebase
- Android notification behaviorAndroid Developers
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy