OK, tak pokrok. Už vím že bych dispatchTouchEvent neměl používat a měl bych použít onInterceptTouchEvent. Jenže pořád tam je ta otázka. Jak odchytit klik aniž bych tím zabil scrolování vnořeného HorizontalScrollView. Protože jakmile pošlu MotionEvent.ACTION_DOWN tak si to převezme ScrollView a mám smůlu. Když si ACTION_DOWN interceptnu tak to funguje ale zabiju tím scrollování. Takže mi pořád uniká klíčový pattern.

Snažím se pochopit jak Android zpracovává doteky. Co jsem pochopil:
- touch bublá skrze hirearchii z window dolu do views (dispatching)
- pak bublá zpátky přes (onTouch) ...

Co nechápu je intercepting.

Co potřebuju vyřešit.

Mám RecyclerView .. v něm mám row s LinearLayoutem a v něm mám HorizontalScrollView. Ten HSV si bere veškerý touch který potřebuju detekovat v LinearLayoutu. Potřebuju poznat že jde o click a pak to gesto neposlat dolu a zachytit ho v LinearLayoutu.

Jenže teď jak na to když MotionEvent je nejprve DOWN, pak MOVE a pak UP. Jenže klik umím zjistit až ve chvíli kdy je event UP a to je už pozdě protože v tu chvíli si ty eventy už konzumuje HSV. Nějaký nápad nebo pattern jak se tohle běžně řeší?

Díky!

Zdravím, zase mám problém. :) Mám ConstraintLayout a v něm HorizontalScrollView .. a na tom ConstraintLayoutu mám onClickListener ale je "hluchý". Je možné, že touch konzumuje HorizontalScrollView. Jinak si to neumím aktuálně vysvětlit. Dá se tomu nějak předejít aby nekonzumoval a posílal dál?

S klavesnici a layoutem jsem se sral tak dlouho az jedine uspokojive reseni byla klaveanice vlastni s polem kde se mi zobrazuje to co vlastne pisu, do te doby strasnej provlem protoze ne vsechna poleuzou byt nahore aby byla videt i s klavesnici

MIKULAS: Přesně, mě štve i ten WhatApp co si tam tu notifikaci občas hodí, aby neměl označenou práci za podezřelou.

MIKULAS: Ja si je prepinam na silent & minimized, taky nemam rad nahore ikonky. Ale mas samozrejme pravdu. Vysvetlit to uzivatelum je nadlidsky vykon a radsi to smazou :-).

JOHNY_G: a když přece vyhraješ, tak to bude muset být super-mega-užitečná appka, aby se uživatelé byli ochotni stále koukat na tu sticky notifikaci - což je většinou nepřekonatelný UX problém - lidé mají rádi to oznamovací centrum vyčištěné

DATEL: Řešili. Můžeš se dostat poměrně daleko, když to bude foreground s persistentní notifikací, bude STICKY, a když uživatele provedeš až do nastavení systému, ale nikdy nevyhraješ úplně :-(. U některých výrobců nevyhraješ nikdy. Musíš využívat času, kdy je aplikace v prostředí, a tu servicu si znovu nakopnout.

DRIZDIK: Prave ze jak to vypada dle logu, tak Doze mode se mi spusti i v te foreground service. Zkusim jeste vypnout optimalizaci baterie pro tu aplikaci (Honor ). A diky za ten tip na ACTION_REQUEST, kouknu na to, co by to melo umet.

DATEL: Pak to mohou být nějaké optimalizace kvůli baterii, to se dá ještě obejít pomocí ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, ale to už je i na mě vyšší dívčí, ve zkratce je tam ještě Doze mode, který by ale měli Foreground Services pozdržet, ale každý systém se pak k těm services chová jinak .. největší dementi v tomhle bývají u Huawei a Xiaomi aby to vypadalo, že baterie dlouho vydrží.
SUK: Tam se o komunikaci většinou stará Google Play Services (Firebase Notifikace) ..

Hm, tak testovaci aplikace sice stale bezi, ale v logu jsou videt casova okna (loguju kazdou minutu). Wake lock na tohle asi reseni nebude, to by system tu aplikaci brzo sejmul pocitam. Jak tohle resi treba GPS tracker aplikace? Nebo ty to maji dane tim, ze dostavaji polohu? Je mozne, ze kdyz bych kazdou tu minutu delal ping na server, ze by tam ty okna (Doze?) nebyly?

DRIZDIK: Pocitam prave s foreground a notifikaci. Ted jsem delal testovaci aplikaci, kazdou minutu mi zaloguje cas do souboru, zatim mam navic jen boot receiver. Ten JobScheduler tam mam v planu dodat zitra, prave na situace, kdy to stejne system sejme. Akoraz tam je myslim limit nejkratsiho intervalu 15 minut :-( Navic mam dojem, ze sluzba sice bezi na popredi, ale v logu mam okna, kdy se nic nezalogovalo. Ale to muze byt tim, ze to loguje v jinem vlakne spoustenem v te sluzbe.

DRIZDIK: Jo. A kdyz je neco push ze serveru, tak co to prijima? Na to existuje nejaky genericky zpusob? Btw, cim by mohlo byt, ze prave ta moje vec, ac ma nastaveny velmi nizky interval, tak se syncuje velmi nepravidelne?

SUK: Můýže to zabít, některé věci zase automaticky ožijou (sticky services), něco ani take (případ force-close) Většina těchhle synchronizací je buď schedulovaná(aby ti právě stále něco neběželo na pozadí) nebo pushovaná ze severu.

DATEL, DRIZDIK: Chapu-li dobre, tak system si muze dovolit zabit cokoliv, nezavisle na uzivatelskem nastaveni, pokud to nezobrazuje notifikaci? Jak funguji treba synchronizace kalendare/kontaktu atd? Osobne s tim mam prave trosku problem, ze se mi nesyncuje kalendar (CalDAV) kdovijak casto.

DATEL: Nemusí .. je známej případ kdy ty systémy občas dělali force-stop, což ti nedovolí té appce znovu najet. S foreground servicem musíš stále zobrazovat notifikaci. Druhá možno je kombinace backgroundu a workmanageru, který by měl naplánované pingání.

DATEL: ještě doplním dotaz, zda foreground service přežije i úpravy výrobců vlastních nadstaveb s různými "save battery" a optimalizacemi.

Ahoj, řešil jste někdo jak zabezpečit, aby aplikace zůstala živá a systém ji nesejmul při první příležitosti - obzvlášť Android 8, 9 a 10. Stačí teoreticky foreground service, která bude pingat na server (aplikace má primárně spojení s aplikačním serverem)? Nebo případně přidat Alarm / Job? Nesmí být závislé na GMS / Firebase Messages (tj. že by server posílal notifikace, kterou by zobrazil systém, když by app byla zrovna stopnutá). Díky za tipy.

Mimochodem, je možnost nějak observovat jestli window pannuje? Totiž mám průhledný status bar a potřeboval bych změnit jeho barvu během pannigu.