Learning outcome
Demonstrate understanding with an independent extension and scored evidence.
Finish by explaining the architecture without reading the source, then make one independent improvement. This course teaches a working preview; course progress or a completion certificate is a learning record, not Google endorsement or proof that your app is production-ready. Use the evidence below to assess actual capability.
Answer before checking the explanations
- Does A2UI require a Gemini key, and why does this app need a server?
- What are the three server-created messages, and how is a component ID different from a data path?
- Why is a JSON-valid model response not automatically a safe event interface?
- When does a checkbox value reach the agent, and how does this sample preserve it after refinement?
- What do fake-repository instrumentation tests establish that a screenshot does not?
- Why can cancelling a coroutine leave a blocking HTTP call or provider computation running?
- Which data survives rotation, New conversation and process death?
- What would you change before hosting this server for untrusted public users?
Expected reasoning
| Question | Key explanation |
|---|---|
| Key ownership | Protocol/rendering is provider-independent; Gemini generation needs server credentials |
| Message lifecycle | createSurface, updateDataModel, updateComponents; graph identity is separate from bound state |
| Trust | Validate graph/actions against allowed catalog and event records; evaluate prose separately |
| Feedback | Local binding update, snapshot on request, exact-label carry-over for refine |
| Evidence | Deterministic render/action/state behavior, not actual inference quality |
| Cancellation | Job cancellation alone does not cancel synchronous OkHttp execution or guarantee provider cancellation |
| Lifetime | ViewModel across configuration changes; reset clears conversation but keeps saved IDs; endpoint persists; process death loses conversation |
| Deployment | Authentication, authorization, per-user quotas, rate limits, provider limits, monitoring, privacy and abuse handling |
Independent capstone: implement stable checklist item identity so completed items can survive a label edit. Keep domain IDs separate from component IDs and ready paths, define how new/removed items behave, and ensure the agent cannot mark an uncompleted item as verified. Extend request/output validation and tests before changing UI behavior. This is not implemented by the baseline and has no supplied copy-paste solution.
Required capstone evidence
- A short design identifying who owns stable IDs and how an update maps old items to new ones.
- Failing then passing tests for label edit, reorder, new item, removed item and two distinct items with the same text.
- A bounded request/output contract and proof that unknown IDs are rejected or handled explicitly.
- One real-device generation/refinement recording or screenshots, with model and commit recorded and no secrets.
- A limitations note that separates self-reported completion from external verification and describes context-window eviction.
Self-assessment: 20 points
| Area | Points | Evidence |
|---|---|---|
| Explain boundaries and lifecycle | 4 | Accurate answers to key/protocol/state questions |
| Reproduce live flow | 4 | Device setup and generated event → preparation → refinement |
| Red/green validator exercise | 4 | Failing/passing logs and policy explanation |
| Independent capstone | 4 | Domain identity design, tests and working interaction |
| Quality and limitations | 4 | Evaluation matrix, failure recovery and honest production gaps |
Readiness threshold
Aim for at least 16/20 with evidence in every area. Regardless of score, do not claim readiness if credentials are exposed, tests use an undisclosed runtime fallback, or the live action loop has not worked. Revisit the relevant lesson instead of merely marking it complete.
Practice and checkpoint
Submit your source diff, red/green test logs, device/model evidence and short evaluation report. Explain one remaining limitation you would prioritize next and the test that would demonstrate its improvement.
Source and next steps
- Pinned implementation — The exact app and server revision used by this lesson.