The project
Build a note assistant with a fake model first, then replace the adapter with one supported inference service.
Prerequisites
Complete the six teaching modules and their exercises. Keep the design notes and failure cases: they form the starting evidence for this project.
Build in increments
1. What AI means in an Android app
Separate product behavior from the model that helps implement it. Apply the module decision to this project. Your checkpoint: You can explain inference and identify a feature that should not use a model.
2. Tokens, context and model behavior
Understand what a model receives and why its output varies. Apply the module decision to this project. Your checkpoint: You can distinguish formatting success from factual correctness.
3. Choosing cloud, on-device or hybrid
Make a deployment decision from requirements and measured constraints. Apply the module decision to this project. Your checkpoint: Your fallback respects the same privacy promise as the preferred route.
4. Kotlin architecture for model calls
Keep the UI independent from model providers and network behavior. Apply the module decision to this project. Your checkpoint: You can test the ViewModel without a real model or an API key.
5. Evaluation, privacy and cost basics
Measure whether the feature helps before expanding it. Apply the module decision to this project. Your checkpoint: Your evaluation can identify a worse prompt even when its prose sounds better.
6. Connecting the first AI feature
Integrate one narrow capability and prove its behavior at the app boundary. Apply the module decision to this project. Your checkpoint: The feature remains usable when inference is disabled.
Acceptance criteria
- Document why the feature needs a model rather than a deterministic rule
- Show loading, cancellation, refusal and unavailable states
- Evaluate ten representative notes and five failure cases
Evidence to submit
- A repository or reproducible design artifact with setup instructions and tested tool versions.
- A diagram showing components, data flow, authority and failure boundaries.
- An evaluation table with inputs, expected results, actual results and explanations of failures.
- A demonstration of the normal path and at least two relevant failure paths.
- A short decision record covering alternatives, known limitations and the next improvement.
Review rubric
| Dimension | Ready to demonstrate | Revisit when |
|---|---|---|
| Understanding | Explain each boundary and why it exists | You can only repeat framework terminology |
| Implementation | Reproduce the core behavior from a clean setup | Hidden local state is required |
| Reliability | Show bounded failures and useful recovery | The demo only works on the happy path |
| Evidence | Present observed outcomes and limitations | Success is inferred from a generated answer |
| Ownership | Modify a requirement and explain the consequences | You cannot adapt the implementation independently |
Do not treat a completed reading checklist as proof of project readiness. Revisit any module whose checkpoint you cannot demonstrate.