FIT3178 Chap.7 AI Features, Notifications and Deep Links
AI Features, Notifications and Deep Links
AI assistance, notifications and deep links all deliver external suggestions to the app. Their sources differ, but the architectural question is similar: how does an untrusted input become a validated state transition?
A generated recommendation can be wrong, a notification can be stale and a URL can request a route the current user is not authorised to see.
Treat AI output as data with a declared purpose and validation rule. Constrain the task, minimise sensitive input and retain a human decision where harm or personal judgement matters. Structured output still needs schema and domain validation.
If confidence cannot be established, the interface should communicate uncertainty or fall back rather than presenting fluent text as authority.
Notification permission should follow a visible benefit. The payload may contain display text and routing metadata, but sensitive details should not be exposed on a locked screen without need.
A tap can launch the app from a cold state, resume it from background or arrive while the relevant screen is open. Route through one coordinator that can wait for required state and avoid duplicate navigation.
Deep links require parsing, allow-listing and authorisation. Map a URL into a typed route, reject unknown parameters and resolve current domain identity before showing a destination.
A link should not create an object simply because it is absent. Universal-link trust and in-app access checks solve different problems and both matter.
Worked case: a reminder contains a study-plan item identifier and requests an AI-assisted next step. At cold start, the coordinator restores the signed-in session, resolves the item and only then opens the detail.
If the item was deleted elsewhere, the app shows a bounded explanation and returns to the plan. Generated advice is labelled, reviewed and never auto-submitted as the user's work.
Portfolio evidence should exercise stale, unauthorised and malformed inputs. Show one notification received in each lifecycle state and one deep link with an invalid identifier.
For AI, record the prompt boundary, validation and user control. This makes the feature a coordinated system rather than three isolated demos that work only when all assumptions are already true.
A typed route should contain the smallest validated intent, not an encoded screen.
Parsing converts external strings into a known route case; authorisation confirms the current user may perform it; resolution confirms the referenced object still exists; navigation chooses a current presentation.
Keeping those stages separate lets malformed input fail before state access and lets a valid but stale identifier produce a bounded unavailable result rather than an accidental recreation.
For AI-supported behaviour, document an input contract, output schema, domain checks and human decision. Then test an empty result, a structurally invalid result, a fluent but prohibited suggestion and a service failure.
Notifications and links need their own lifecycle matrix: cold, background, foreground and repeated delivery. The common evidence is idempotence—handling the same intent twice should not duplicate screens or mutations—and current-state resolution before any consequential action.
Keep the fallback path executable without the external system.
A failed model call can return the user to manual planning, a denied notification can leave an in-app reminder list, and an invalid link can open a safe home context. A fallback is not merely an error sentence; it preserves the underlying user goal where possible. Demonstrate it under cold-start conditions so hidden restored state cannot make the result look more robust than it is.
What this chapter covers
- 01
AI output
- 02
notification payload
- 03
deep link
- 04
coordinate intelligent output, system delivery and navigation without bypassing consent or validation
- 05
A route request or fluent generated suggestion is untrusted input; neither may bypass permission, existence checks or user review.
Open a stale notification safely
- 1Parse a typed route.
- 1Restore session state.
- 1Resolve current identity.
- 1Handle absence.
- 1Constrain AI output.
Key terms
- AI output
- A probabilistic result that requires task-specific validation before application use.
- notification payload
- The content and routing metadata delivered by the notification system.
- deep link
- A URL or route that requests navigation to a specific application destination.
AI Features, Notifications and Deep Links FAQ
What is the key decision in AI Features, Notifications and Deep Links?
Coordinate intelligent output, system delivery and navigation without bypassing consent or validation.
Which failure path matters most?
A route request or fluent generated suggestion is untrusted input; neither may bypass permission, existence checks or user review.
Are the worked cases official portfolio tasks?
No. They are AskSia-authored practice aligned to the current teaching sequence.
What should be shown in discussion?
Show the state or responsibility trace, the changed condition and evidence that the repair works.
Assessment move
Rebuild the state or dependency map from memory, run the worked change, then explain the first assumption that fails.
Working through AI Features, Notifications and Deep Links in FIT3178? Sia is AskSia’s AI Software Development tutor — ask any FIT3178 AI Features, Notifications and Deep Links question and get a clear, step-by-step explanation grounded in how FIT3178 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
