FERRENC: k hromade zde relevantnich duvodu proc to nepouzivat pribyl dalsi - od COVIDu je Face ID nepouzitelne, protoze to museli upravit tak, by to fungovalo s rouskou

DRIZDIK: Plus heslo jsi schopný invalidovat a vygenerovat si nové celkem levně pokud víš že , ale plastika vyjde trošku dráž.

FERRENC: Nosíš svoje hesla viditelně na veřejnosti? Má k tvým heslům přístup kdokoliv se dostane "on premises" a ty spíš (žárlivá manželka) nebo třeba nejsi při vědomí (někdo kdo tě jebne po hlavě venku)? Úplně raketová věda to není, ale teď přichází generování obsahu a 3D tisk, což u MS stačí obraz, u Apple je třeba 3D model.

BAT: Asi jsi mě nepochopil. Než budu Face ID důvěřovat, abych si ho nastavil na citlivé bankovní aplikace atp., tak chci vědět, proč ho označují za méně bezpečné přihlášení.

Ahoj, máte někdo tip na "How to beat FACE ID/Recognition"? Nejlepší obrana je znát slabiny SW, takže se snažím najít nějaké návody, jak to obejít, ale chápu, že ty výsledky Google asi trochu koriguje = resp. není snadné něco relevantního vygooglit. Díky!

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é :-).