• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    LWEEKAndroid development
    MIKULAS
    MIKULAS --- ---
    2 odpovědi
    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é
    JOHNY_G
    JOHNY_G --- ---
    1 odpověď
    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.
    DATEL
    DATEL --- ---
    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.
    DRIZDIK
    DRIZDIK --- ---
    1 odpověď
    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) ..
    DATEL
    DATEL --- ---
    1 odpověď
    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?
    DATEL
    DATEL --- ---
    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.
    SUK
    SUK --- ---
    1 odpověď
    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?
    DRIZDIK
    DRIZDIK --- ---
    1 odpověď
    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.
    SUK
    SUK --- ---
    1 odpověď
    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.
    DRIZDIK
    DRIZDIK --- ---
    2 odpovědi
    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
    DATEL --- ---
    1 odpověď
    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.
    DATEL
    DATEL --- ---
    3 odpovědi
    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.
    LWEEK
    LWEEK --- ---
    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.
    LWEEK
    LWEEK --- ---
    +1
    Nakonec jsem to vyřešil tak, že jsem do manifestu vložil: android:windowSoftInputMode="adjustPan". Díky za tipy.

    Asi to je fakt. Záleží na co je člověk zvyklý. Já řeším problémy v iOSu úplně bez větších potíží a jsem na to zvyklý a mám to rád. V Androidu asi narážím, protože ta platforma je prostě namyšlená jinak. Každá platforma má asi své plusy a mínusy.
    JOHNY_G
    JOHNY_G --- ---
    U notche ještě nezapomeň na windowTranslucentStatus (true) a statusBarColor (transparent) v android:theme, pokud kolem něj chceš kreslit.
    JOHNY_G
    JOHNY_G --- ---
    +2
    LWEEK: Tohle je problém vývojářů, kteří nejsou sžití s cílovou platformou. Zcela nesprávně očekáváš iOSové chování a snažíš se aplikovat iOSové postupy na prostředí jiného systému. Je tu strašně moc proměnných na to, abych ti poradil konkrétní řešení. Možná by stačilo mít BottomNavigationView v aktivitě a obsah ve fragmentu, a korektně pracovat s gravity vs. layout_alignParentBottom/layout_constraintBottom_toBottomOf a windowSoftInputMode. Možná by stačil windowSoftInputMode s jinou strukturou layoutu. Možná, že by se na to dal použít CoordinatorLayout s příslušným layout_behavior. Těžko říct zpatra, bude to chtít trochu experimentování :-).

    LWEEK: Notch se na Androidu handluje přes fitsSystemWindows a WindowInsets (resp. WindowInsetsCompat, pokud si chceš ušetřit bolehlav). Ve většině případů funguje fitsSystemWindows naprosto automaticky (když ho pochopíš), někdy ale musíš něco ručně postrčit přes inset.

    No a kdybys trval na jablečném přístupu, můžeš, tuším, WindowInsets (nebo úplně na surovo ViewTreeObserver) použít právě i na to skrývání bottom baru. Jeden z mnoha přístupů řeší třeba tento článek (jeho prioritou jsou animace, ale tento problém adresuje): https://proandroiddev.com/animating-keyboard-appearance-in-android-application-425a2a26de9a
    TOOMIX
    TOOMIX --- ---
    Děláme pro Android a iOS v Xamarin.Forms s komponentama od Syncfusion a na iOS se toho moc pozitivního říct nedá, samý klacky pod nohy, ale každá ta platforma má svoje plusy a mínusy
    STARF
    STARF --- ---
    +1
    a jestli to ma byt bez skakani, tak bych pouzil scrollTo()
    ale nejaky maly "glitch" tam asi vzdy bude, vic se mi libi smoothScrollTo()
    STARF
    STARF --- ---
    LWEEK: Mas v AndroidManifest u tagu activity pridano android:windowSoftInputMode="adjustResize" ?
    Ve fragment XML potom je nutne u nestovaneho view pridat android:layout_alignParentBottom="true". A v tride mScrollView.post { mScrollView.smoothScrollTo(0, saveButton.y.toInt()) }.
    pozn.: saveButton je posledni view, co ve fragmentu mam - proto jsem to testoval na nem

    zkousel jsem si ted udelat jeden layout s edittextem, abych si otevrel softinput (klavesnici) a nasledne prejit do dalsiho fragmentu a chova se to spravne
    TCHUBA
    TCHUBA --- ---
    LWEEK: Když potřebuješ soubor rozdělit na tematické bloky, máš moc dlouhý soubor :D
    Taky roky dělám jak iOS tak Android a dokud Xcode nevyhodí adresářovou strukturu řešenou přes pbxproj, nepřestane mi při každém git commitu nabízet neznámé soubory které jsou v .gitignore (něco z dependencies) a začne brát parametry ze storyboardů stejně jako ze swift kódu (dívám se na tebe, semanticContentAttribute, který ve storyboardu nefunguje a ve swiftu ano), tak budu vždycky preferovat Android Studio
    Kliknutím sem můžete změnit nastavení reklam