Új hozzászólás Aktív témák

• #4840 Zalanius tag bandi0000 #4839

  Új Válasz 2019-04-13 16:10:51 #4840

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Zalanius

  tag

  válasz bandi0000 #4839 üzenetére

  Ha M vagy újabb a verzió, kértél / kaptál rá futás közben is engedélyt?

• #4803 Zalanius tag Tityahome #4802

  Új Válasz 2019-01-27 16:08:18 #4803

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Zalanius

  tag

  válasz Tityahome #4802 üzenetére

  Rootolt esetben a SystemUI kis módosításával a navbar elég jól átszabható, bár új funkciók hozzáadását sosem próbáltam, azt nem biztos, hogy 5 percből meg lehet úszni. Az viszont biztos, hogy valamikor a 4-es, 5-ös időkben az egyéb "always on top" trükkökből sokat kinyírtak. Esetleg valami ilyesféle koncepció?

• #4790 Zalanius tag speedbump #4789

  Új Válasz 2018-12-23 13:08:26 #4790

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Zalanius

  tag

  válasz speedbump #4789 üzenetére

  Már nem szükséges, de 25-ös SDK-ig kellett, mert a return type adott esetben View volt. 26+ compile esetén viszont a metódus:
  public <T extends View> T findViewById (int id)

  Itt egy forrás hozzá, ahol külön is említik, hogy így a legtöbb esetben nem kell már kasztolgatni.

  szerk. a compile sdk beállítás a fontos itt, nem a min.

• #4735 Zalanius tag thon73 #4733

  Új Válasz 2018-11-24 22:37:53 #4735

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Zalanius

  tag

  válasz thon73 #4733 üzenetére

  Ha jól sejtem, a setArguments megoldást keresed, a példákban legtöbbször egy static [***] newInstance() metódusból kiindulva magyarázzák el. Bővebben itt, keresd a DetailsFragment definíciós részét.

  Ha app crash / forceclose utáni újraindulásra gondoltál, akkor ez tárgytalan.

• #4732 Zalanius tag [KgP].Robot #4731

  Új Válasz 2018-11-23 12:28:56 #4732

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Zalanius

  tag

  válasz [KgP].Robot #4731 üzenetére

  Még az L időkben írtam ilyet, az apache.http.* modulokkal nem is kellett újra feltalálni a meleg vizet, ott volt minden kulcsrakészen. Nagy vonalakban: kellett egy HttpProcessor, HttpService, HttpContext meg egy ServerSocket. Aztán a bejövő requesteket egy runnable és néhány HttpRequestHandler segítségével feldolgozzuk, HttpResponse-ban válaszolunk, kész. És persze az egészet egy Service-ben érdemes valamilyen .start() és .stop() kezelés mögé tenni.

  A régi dokumentációkban mindegyik osztályhoz volt annyi favágós és tutorialos kód, amiből az egész összerakható, de mivel 22-es API-tól kezdve ez az egész deprecated lett mindenestül, inkább OFF-ba tettem.

• #4701 Zalanius tag [KgP].Robot #4700

  Új Válasz 2018-11-05 19:43:01 #4701

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Zalanius

  tag

  válasz [KgP].Robot #4700 üzenetére

  Build.SERIAL, android_id, MAC, tehát nagyjából ami az évek és verziók során szóba jöhetett, valahol mind elvérzik. Átírható root esetén vagy akár anélkül is, vagy változékony (pl. factory reset az android_id-nál), vagy lehet üres (ro.serialno minden további nélkül), no meg a 6-7-8-9 verziókban szigorítások voltak, engedélyek mögé lettek rejtve stb. Van is némi dokumentáció arról, hogy szándékosan nehezítik az ilyesmit, és inkább az "app instance"-féle azonosítási módhoz adnak tippeket. Itt egy olvasnivaló: android.com

Új hozzászólás Aktív témák