Learn through PocketCards, the runnable flashcard app in Android + AI Cookbook. Open the hands-on codelab · Browse the pinned source.
Start with constraints
PocketCards uses cloud inference through Firebase AI Logic, while decks and review metadata live locally. “Saved on this device” describes storage after review; it does not mean generation is on-device. When the learner selects Generate flashcards, the notes are sent to Google's cloud service. The UI explains this before the request.
Choose a deployment route by examining the task, data policy, network availability, device coverage and acceptable latency. A provider's model quality alone is not enough. A hospital's private notes and a student's public biology passage can have different constraints even if the transformation is identical.
| Route | What it buys | What you must account for |
|---|---|---|
| Cloud | Provider-managed model execution and broad device reach | Network, provider data handling, quotas and service failures |
| On-device | Local inference and potential offline use | Supported hardware, runtime/model availability, memory and measured quality |
| Hybrid | Different routes for different conditions | Explicit routing rules, user expectations and evaluation of both paths |
Why the sample uses this route
The first lesson should make the request boundary visible without requiring model downloads or accelerator troubleshooting. Cloud inference lets us focus on prompting, structured output and asynchronous Android state. Manual creation remains available without Firebase or a network. That fallback preserves the ability to study, but it is not a local AI substitute.
Generate → cloud request → reviewed draft → local save
Manual → user-authored draft → local save
Study → local saved deck → local review progress
Configuration is not authorization
The downloaded google-services.json identifies the learner's Firebase application. It must match com.androidengineers.pocketcards. The repository excludes this file so contributors do not share one Firebase project. Client configuration should not be treated as a privileged secret that makes an APK safe by itself: values needed by a mobile SDK are part of the built app. Service controls such as App Check, quotas and authorization where applicable still matter.
An emulator cannot satisfy every production attestation path. This sample uses a debug App Check provider in debug builds and Play Integrity in release builds. A registered debug token is sensitive; keep it local and revoke it if exposed. Do not disable protection simply to make a demo pass.
Make a decision record
Write five sentences: what data is accepted, where inference executes, what leaves the device, how a failure behaves and what evidence would justify changing the route. A hybrid design must state when cloud fallback is allowed. It must not silently upload material promised to remain local.
Checkpoint: Turn off connectivity and distinguish studying a saved deck from generating a new one. Then propose an on-device version. Identify the capabilities and measurements needed before claiming equivalent functionality; this project does not currently ship an on-device adapter.
Worked design review: the offline promise
Suppose a user is travelling without connectivity. They expect yesterday's deck to work. The sample can satisfy that expectation because studying reads locally saved data. It cannot promise to generate new AI cards offline because its generator invokes a cloud service. Manual card creation is a useful alternative, but calling it “offline AI” would misdescribe the feature.
A proposed local adapter would still implement CardGenerator, but sharing an interface does not make it an interchangeable product. Before accepting it, measure supported devices, model download/setup, memory use, latency and grounded-answer quality on the same cases. Also decide what happens when the model is not installed. These are extension requirements, not existing PocketCards features.
Decision record example
Accepted data: public study notes
Inference: cloud, only after Generate is selected
Local data: saved decks and review metadata
No connection: study saved decks or create cards manually
Change the route when: privacy/offline requirements justify a tested local model
Design exercise: A future screen promises “these notes never leave your device.” Can it silently fall back to Firebase when local inference fails? No. A routing convenience cannot override that promise. Either keep the task local or obtain a separate, clear choice before upload. This answer follows from the product requirement, not from which SDK is easiest to call.