Homework — a signed build and a look ahead.

1. Create a keystore with keytool (see step 2). Guard it — lose it and you can't update the app on the Play Store.
2. Enable R8 (optimization { enable = true }), add the keep rules and build ./gradlew assembleRelease.
3. Test the RELEASE build, not debug. Install app-release.apk on a phone and walk the whole flow: menu → login → order → payment. If something breaks only here, you're probably missing a keep rule.
4. State audit. Go through every screen and check the empty and error cases: empty cart, "No orders yet", the menu with no internet (the cache from lesson 7!). Each should show a clear message, not blank space.

An honest signpost — "Clean Architecture" and the use-case layer.

All course, Pica was built as MVVM + repository + Koin DI. That's the right-sized separation for an app this scale, and a deliberate choice. You may have heard of "Clean Architecture" or a "use-case (interactor) layer" — when do you need it?

• When it's worth it: when the app or team grows and ViewModels start absorbing business rules (complex calculations, multiple sources for one operation, rules repeated across screens). Then you insert a use-case between the ViewModel and the repository — one business operation, one class (PlaceOrderUseCase), easy to test in isolation.
• When you DON'T need it (like Pica): while a ViewModel just fetches from a repository and maps to state, a use-case layer only adds "empty" pass-through classes. Don't add architecture for architecture's sake.

This is the same principle as recursion in the Algorithms course: name the tool and when to reach for it, but don't build it without a need.

To submit: (1) the app-release.apk/.aab build log, (2) the release build working on a phone (full flow), (3) 2–3 sentences: where in Pica a use-case would appear first if the app grew.

Next. The capstone (13) remains: assemble everything into one Pica, walk the full flow from QR to payment, and describe the architecture.