Namų darbas — pasirašytas leidimas ir kur toliau

Namų darbas — pasirašyta versija ir žvilgsnis toliau.

1. Susikurk raktinę su keytool (žr. 2 žingsnį). Saugok ją — pametęs negalėsi atnaujinti programėlės Play parduotuvėje.
2. Įjunk R8 (optimization { enable = true }), pridėk keep-taisykles ir surink ./gradlew assembleRelease.
3. Testuok RELEASE, ne debug. Įdiek app-release.apk į telefoną ir pereik visą srautą: meniu → prisijungimas → užsakymas → mokėjimas. Jei kas nors lūžta tik čia — tikriausiai trūksta keep-taisyklės.
4. Būsenų auditas. Pereik kiekvieną ekraną ir patikrink tuščią bei klaidos atvejį: tuščias krepšelis, „Nėra užsakymų", meniu be interneto (talpykla iš 7 pamokos!). Kiekvienas turi rodyti aiškią žinutę, ne tuščią plotą.

Sąžininga nuoroda — „Clean Architecture" ir use-case sluoksnis.

Per kursą Pica statyta MVVM + repozitorija + Koin DI. Tai — tinkamo dydžio atskyrimas šio masto programėlei, ir sąmoningas pasirinkimas. Galbūt girdėjai apie „Clean Architecture" ar „use-case (interactor) sluoksnį" — kada jo reikia?

• Kada verta: kai programėlė ar komanda auga ir ViewModel'iai ima kaupti verslo taisykles (sudėtingi skaičiavimai, keli šaltiniai vienai operacijai, taisyklės, kartojamos keliuose ekranuose). Tada tarp ViewModel ir repozitorijos įterpiamas use-case — viena verslo operacija, viena klasė (PlaceOrderUseCase), lengvai testuojama atskirai.
• Kada NEreikia (kaip Pica): kol ViewModel tik paima duomenis iš repozitorijos ir atvaizduoja būseną, use-case sluoksnis tik prideda „tuščių" klasių. Nepridėk architektūros dėl architektūros.

Tai — tas pats principas, kaip rekursija Algoritmų kurse: įvardink įrankį ir kada jo griebtis, bet nekurk jo be poreikio.

Atsiskaitymui: (1) app-release.apk/.aab surinkimo log'as, (2) release versija veikianti telefone (pilnas srautas), (3) 2–3 sakiniai: kur Pica'oje pirmiausia atsirastų use-case, jei programėlė augtų.

Toliau. Lieka baigiamasis (13): sujungiam viską į vieną Pica, pereinam pilną srautą nuo QR iki apmokėjimo ir aprašom architektūrą.