JOHNY_G: Taky dobry, diky :)

GEGE: S Unrealem mám nulové zkušenosti, ale podle zkušeností s Unity bych šel taky do iOSu, jestli máte na výběr. Nebudeš muset řešit, proč tyhle 2 obskurní, a tenhle jeden extrémně populární chipset nepodporuje zrovna ten nejefektivnější formát textur, a zrovna ten nejlepší shader :-D. Nemluvě o mrdačce s OBB, protože APK na Google Play se musí vejít do 150 MB :-). AAB může být větší, ale pro konkrétní zařízení může vyplivnout max. 150MB APK, jestli se nemýlím.

MAKROUSEK: Souhlasim, jsem rad, ze to rikas.

Zdravim vespolek. Jdu sem s prosbou o radu. V pristich mesicich chceme vyvinout jednu appku v Unreal Enginu a ji exportovat pro mobilni zarizeni. Appka bude slouzit k prezentaci jednoho letniho resortu s domy na prodej, takze pravdepodobne za 2 roky nebude mit vyuziti. Rozhodujeme se mezi iOS nebo Androidem. Nikdo z teamu s tim momentalne nema zkusenosti. Snazim se ted ziskat dostatek informaci na to, abychom se rozhodli, ktery OS a ktery store bude lepsi. Dokazu si predstavit, ze taky optimalizace pro ruzna zarizeni bude slozitejsi resp snazsi.

Mate nekdo zkusenosti s vyvojem jak pro Android, tak pro iOS? Da se obecne rict, ze pro jeden z operacnich systemu je vyvoj a optimalizace jednodussi? Je vetsi pain udrzovat aplikaci v AppStore nebo iOS?

Nemá někdo dobrý manuál, jak před sestavením AOSP Androidu 11 aktualizovat bezpečnostní záplaty? V základu je repozitář na bezp. aktualizaci z října 2021 (android-11.0.0_r46), od listopadu 2021 jsou k dispozici měsíční aktualizace (android-security-11.0.0_r49 až *_r65). To málo, co jsem na netu našel, jsem zkusil, ale zatím neúspěšně. Např. v adresáři frameworks/base:

1. git fetch https://android.googlesource.com/platform/frameworks/base 6ea0366c46b03f9e99e349d9732dbe80754f35c1 --depth 2
2. git cherry-pick 6ea0366c46b03f9e99e349d9732dbe80754f35c1

JOHNY_G: Ale jo, řešme. Teda jestli se ti chce. Mě to samozřejmě zajímá. Já vlastně do dnes pořádně nevím co to ten Context je. Zatím to beru tak, že to je nějaký popis scopu. Ale jestli to je popis threadu, nebo nějakého dispatchera nebo co...

Application oproti tomu vnímám jako nejvyšší objekt aplikační hierarchie.

Jinak díky moc pánové za pomoc. Moc si toho vážím. Bohužel kdykoliv se nachomýtnu k Androidu tak to je za situace kdy není po ruce někdo zkušený kdo by mě nachytřil.

LWEEK: Application je ContextWrapper, a ContextWrapper je Context :-)). Ale to je jedno, formality neřešme.

JOHNY_G: V té servise:

@Inject
lateinit var fetchAllScheduledActivitiesDataUseCase: FetchAllScheduledActivitiesDataUseCase

override fun onCreate() {
super.onCreate()

(application as App).appComponent.inject(this)
}

Tzn, aplication v tomhle případě prý není Context ale Application, takže si to castuju a v applikaci si držím při životě componenty takže bych se k nim měl být schopný touto cestou dostat.

Jinak ta FCM servisa mi nabízí property "application". Tak ji castuju a z ní si beru components a injectuju tu servisu stejně jako to dělám u fragmentu. Očekávám že mi to tam injectne ty usecasy a ty volám tedy s IO dispatcherem.

JOHNY_G: Tak teď si mi v tom zamotal hlavu a to už jsem si myslel že vím co chci. x) Totiž, to co stahuju je tabulka, která může mít několik stovek záznamů. V zásadě to není zas takový brutus. Celá transakce má pořád velikost stovek kilobajtů a včetně zápisu trvá na WiFi asi tak sekundu dvě. Když ta akce selže, tak to není konec světa protože před updatem DB si odnastavím flag, že ty data mám updatnutý a pokud to selže tak při dalším spuštění aplikace se ty data updatují. Ale pokud by to selhávalo většinu času tak to není optimální chování. :)

LWEEK: Pokud je to FirebaseMessagingService, kde zachytáváš onMessageReceived, tak to je IntentService, a nespouští se jako foreground service (která by normálně jela na main threadu), ale na nově vytvořeném worker threadu mimo hlavní vlákno. Pokud máš kromě ní ještě nějakou skutečnou foreground service (tedy s viditelnou notifikací v liště), jejímž účelem je udržet aplikaci při životě, zatímco dělá něco na pozadí, tak ta nemá přímý vliv na životnost jakékoli jiné služby. Ale může ti držet při životě aplikační context. Takže v praxi pokud máš dejme tomu nějaký usecase singleton v aplikačním scopu, který ti tu blocking práci udělá (stáhne data, uloží do DB), tak ho jen provoláš v onMessageReceived a další život té služby, která ho zavolala, tě nemusí zajímat, dokud zůstane naživu aplikace jako taková. U jednoho REST callu se toho ale v zásadě nemusíš bát, ten by měla přežít služba i sama o sobě :-). Předpokládám ale celou dobu nějaké menší nárazové balíčky dat, jejichž ztráta není pro běh aplikace problematická. Android ti totiž nikdy nedokáže garantovat, že proces nechcípne, zejména při zhasnutém displeji. Pokud jde o synchronizaci nějakých větších databází, tak už je samozřejmě WorkManager na místě. I v něm ale můžeš použít CoroutineWorker, popř. spustit coroutine jako runBlocking v normálním doWork. Worker ti vždycky někdy proběhne, akorát úplně nevíš kdy (i u Immediate/Expedited to mohou být řádově minuty, když je systém v doze mode) :-)). Takže tldr; krátké nárazové a postradatelné operace v Coroutině, kterou si vyrobíš v runtime a provedou se hned, dlouhá kontinuální práce ve WorkerManageru, a provede se až systém uzná za vhodné :-).

Respektive ten IO dispatch stejně jako Main dispatch blokuje servise usnout? Já totiž ani nevím na jakém dispatchi jede ta servisa, ale tipl bych si, že foreground servisa pojede na Mainu?

JOHNY_G: Tzn ta foreground servisa se neuspí když tam běží corutina?

DRIZDIK: V dokumentaci jsem se dočetl, že:

Coroutines are the standard means of leaving the main thread in Kotlin. However, they leave memory once the app closes. For persistent work, use WorkManager.

Ale je pravda, že nevím jestli tím close myslí jako killnutí apky nebo jenom to že je suspendovaná.

Můj problém je, že jsem iOS vývojář, takže dost často uvažuju v kontextu iOS a na Androidu to bývá kolikrát dost jinak. Možná bude lepší vysvětlit o co mi jde.

Mám firebase messaging foreground servisu. Jakmile přijde silent zpráva určitého formátu, tak se mají ze serveru stáhnout nová data a uložit do DB.

Business logiku mám v repozitáři. Vím, že by tam měl ještě před tím voláním být usecase. Ten samo vyrobím. Takže to co potřebuju je dostat se k tomu usecase (skrze dagger componenty v application) a provolat funkci, která může v extrémním případě chvíli trvat. Volat to přes corutiny mě trochu děsí, protože nevím kolik času ta servisa má než ji systém utne a pokud bych volal asynchronně tak předpokládám, že se apka uspí jakmile projede lifecyklus té servisy.

Možná něco takového? Ale nevím jak moc to je "deadlock" odolné. Ideální by bylo mít možnost ten job cancelnout když se canceluje worker, ale takovou metodu Worker nejspíš nemá.

class ActivitiesUpdateWorker @Inject constructor(
ctx: Context,
params: WorkerParameters,
private val repository: ActivitiesRepository
) : Worker(ctx, params) {

private val job = SupervisorJob()
private val scope = CoroutineScope(Dispatchers.IO + job)

override fun doWork(): Result {
scope.launch {
repository.getAllScheduledActivities(true)
}

while (!job.complete()) { continue }

return Result.success()
}
}