PocketCards final assessment

How to take this assessment

Complete the six lessons, their exercises and the PocketCards codelab first. Work without the answer key for 25–30 minutes, then review your reasoning. Use your own project evidence for the practical section. This is a self-assessment, not an externally graded certification.

The knowledge section contributes 40 points and the project contributes 60. Aim for at least 80/100, including at least 30/40 for knowledge and 45/60 for the project. All completion gates below must also pass. A high total cannot compensate for exposed credentials or an unverified live integration.

Part A: explain the behavior — 40 points

Each question is worth four points. State the conclusion and explain the responsible boundary. Award two points for each idea listed in its answer key.

1. A learner studies the supplied deck with no Firebase configuration. Has the app demonstrated inference? Which action would provide that evidence?
2. Five cards pass JSON parsing and local validation, but an answer contains a date absent from the notes. Why did validation allow it, and what additional check is needed?
3. Does the 8,000-character input limit enforce a precise token budget? What other request material consumes context?
4. Generated decks are saved locally. Does that mean notes remain on-device throughout generation? Describe the actual path.
5. Request A is cancelled, request B starts, and A finishes late. What must the state policy prevent, and what mechanism does this sample use?
6. Saving a Got it rating fails. Should the screen advance? Explain when the action becomes successful.
7. The fifth card of a five-card deck is completed. Why can reading cards[5] crash, and how does the current screen handle absence safely?
8. Two questions differ only by repeated spaces and letter case. What should the codelab improvement normalize, and what learner-facing text should it preserve?
9. A passage has five target facts. Four cards contain three supported answers covering two distinct facts. Calculate supported-answer rate and coverage.
10. A client request times out. What can you conclude about the app's waiting state, and what can you not conclude about provider usage?

Part B: demonstrate your project — 60 points

For each row award zero for missing evidence, half the points for partial behavior with a documented gap, and full points only when all listed evidence is present. Do not award points for a claim without a command result, source reference or app observation.

The capstone brief offers extension choices. Repeating the codelab validation fix is not the independent extension.

Completion gates

• No Firebase configuration, App Check token, private study notes or configured APK in the submission.
• One real provider generation is evidenced separately from fake-backed tests. If access is unavailable, mark the integration incomplete and return later.
• Failed persistence does not silently advance the card; finishing the last card does not crash.
• The published setup points to your actual source revision and states untested behavior.

A failed gate means “needs another pass,” regardless of the score. Record the specific gap and its next verification action.

Answer key — review after attempting Part A

1. No inference is demonstrated by the handwritten sample (2). A configured Generate action with an actual provider response demonstrates cloud inference (2).
2. Shape/local constraints do not establish factual support (2). Compare the answer to the source through review and task evaluation, rejecting or correcting unsupported claims (2).
3. Characters and tokens are different units, with language-dependent tokenization (2). Instructions and schema also contribute to the request/context budget (2).
4. Local persistence describes saved decks, not inference (2). Generate sends notes through Firebase AI Logic to cloud inference before review and local save (2).
5. A stale result must not replace B's draft or update B's state (2). The sample cancels work and invalidates its request identity so outdated results cannot publish (2).
6. Keep the current card and expose retry/error behavior (2). Advance only after the updated review state is successfully persisted (2).
7. Valid indices are 0–4, so index 5 is absent (2). The screen captures a safe getOrNull snapshot and renders completion or an empty state when there is no card (2).
8. Normalize the comparison key using trimmed/collapsed whitespace and stable case handling (2). Preserve the original valid display question; this detects formatting duplicates, not all semantic paraphrases (2).
9. Supported-answer rate is 3/4, or 75% (2). Coverage is 2/5, or 40%, because duplicate coverage of one fact is counted once (2).
10. The local wait has exceeded the configured request timeout and must leave loading with a useful recoverable state (2). This does not establish that remote computation stopped or that no usage occurred (2).

Turn the result into a next action

Missed questions 1–4: revisit product boundaries, structured output and inference location. Missed 5–7: trace ViewModel state, persistence ordering and the safe study snapshot. Missed 8: repeat the red/green exercise. Missed 9–10: revisit evaluation and request limits.

Copy codeAssessment record
Source commit:
Knowledge: __ / 40
Project: __ / 60
Completion gates: pass / needs another pass
Evidence links:
Weakest concept:
Next experiment:
Retest result:

When all gates pass, write a short explanation of what you can now build and which limitations remain. Keep that explanation specific to PocketCards; this course does not establish mastery of on-device inference, agents or every Android AI API.