Hirdetés
-
Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
ph A megfizethető, szivacsokkal jól megpakolt modell ötfajta kapcsolóval és kétféle színösszeállítással/kupakprofillal szerezhető be.
-
Olcsó 5G-s ajánlatot nyújt a Realme Indiának
ma Megérkezett a Realme C65 5G, az első készülék a MediaTek Dimensity 6300-zal.
-
Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
gp Továbbra is szeptemberi premierrel számolnak a fejlesztők, reméljük több halasztásra már nem kell számítanunk.
Új hozzászólás Aktív témák
-
pittbaba
aktív tag
válasz pittbaba #400 üzenetére
Az egyik kérdésemre megtaláltam a választ, hiányzott a stopManagingCursor(cursor);
Azt még mindig nem tudom pontosan, mi az újabb technika a Kurzor feldolgozására. Elvileg lehet valahogy a háttérben futtatni ezeket a kéréseket, ennyit tudtam az angolból értelmezni, de a példák alapján sem tudtam megoldani. Tudtok segíteni?
PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
pittbaba
aktív tag
-
thon73
tag
válasz pittbaba #522 üzenetére
Bocs, közben lemaradtam egy válaszról, de amit írtam, továbbra is érvényes.
Ennyire sztem. nem egyszerű. A doInBackground fut egyedül háttérszálon, ez tud egy értéket (melynek típusa beállítható pl. String) átadni, a már nem háttérszálon futó onPostExecute-nek. De ezt az értéket a fő szál csak úgy magától nem fogja megkapni.
Ugyanakkor a megkötés CSAK az UI elemekre vonatkozik, tehát pl. osztályváltozók a háttérszálról is irhatóak (amennyire tudom, a teljes Application (és szálai) egy heap-en helyezkednek el). A fondorlat abban van, hogy az AsyncTask osztály és a hívó Activity nem feltétlenül létezik ugyanabban az időpillanatban! Az érték átadásakor ezt figyelni kell, ez a legnagyobb buktató!
Ha egyszer elindul, akkor az AsyncTask osztály létezni fog addig, amíg fut v. hivatkozunk rá. Akkor is, ha a háttérszál befejeződött. Így az tűnik a legjobbnak, ha az eredményt egy AsyncTask osztályváltozó tartalmazza, és abból olvassa ki a hívó Activity. A nagy kérdés az, hogy miként értesül a fő Activity arról, hogy futás befejeződött. Ehhez be kell építeni egy Handlert, de akkor kérdéses, hogy érdemes-e AsyncTask-ot használni. Vagy: az AsyncTask get metódusa várakozik, amíg be nem fejeződik a futás. Ezt még nem próbáltam, kérdés, h. ez nem jelenti-e a fő szál leállítását (sztem igen). És akkor még mindig fel kell készíteni arra a fő activity-t, hogy pl. a kép elfordítása során újraindul, mégis ellenőrizze le, nem áll-e rendelkezésre egy kész AsyncTask eredmény.
((Az AsyncTask-kal kapcsolatos tapasztalatokról - mivel elsőre én sem értettem miként működik - írtam egy hosszabb cikket: [link]. Felmerült bennem a kérdés, hogy egyáltalán van-e valami előnye más megoldásokhoz képest.))[ Szerkesztve ]
-
thon73
tag
válasz pittbaba #526 üzenetére
Nem tértem ki, mert eddig ez a probléma nem tűnt fel. Ahol én idáig AsynTask-ot használtam (nem csak a cikkekben szerplő programokban), ott a program célja mindig egy önálló, de nagyon hosszú számítás volt. Ezt általában kiírta file-ba, és azzal már egy következő program (vagy programrész) dolgozott.
Az én esetemben az "eredmény" - vagyis, hogy a kiírás megtörtént - az onPostExecute (pontosabban updateUI) metódusban került kiírásra egy UI elembe. Már, ha volt ilyen. Mindenesetre tovább gondolkodtam.Az onPostExecute egyébként UI szálon van, tehát simán meghívhat, írhat, bármit csinálhat - ha éppen létezik a fő Activity. ((Márpedig itt nagy valószínűséggel léteznie kell, mert mindketten ugyanabban a szálban futnak, tehát amíg az activity az újraindulással van elfoglalva, addig nem futhat az onPostExecute, ha meg ő fut, akkor az Activity nem tud újraindulni.)) Én azt tenném, hogy innen (onPostExecute) meghívnám (vagyis triggerelném) a fő Activity egy metódusát (érdemes azért ellenőrizni, hogy éppen létezik-e). Ez tulajdonképp egy Listener lesz, amit pl. a konstruktorban át is lehet adni. Ez igen egyszerű, és ugyanúgy fog működni, mint ahogy pl. egy gomb lenyomásakor elsül az onClick metódus. Mégis kell egy AsyncTask osztályváltozóban jelezni, hogy már van kész eredmény, mert ha ez megvan (tehát van már elindított AsyncTask és van már eredmény is), akkor a fő Activity (újra)indulás után nem az AsyncTask indítása felé mozdul, hanem a további számítás felé. Bár ilyenkor már a számítás megkezdődött, tehát látni fogod, hogy kiszállt és újraindult a program. De mégsem kell mégegyszer lefuttatni a teljes AsyncTask-ot.
B. (lehet egyszerűbb, csak kevésbé felhasználóbarát) verzió: az onPostExecute felfed egy gombot, ami tájékoztatja a felhasználót, hogy "Oké, megvagyok, mehetünk tovább!". (Megteheti, hiszen UI szálon van!) És azt megnyomva ugrik a végrehajtásra.A másik kérdésre válaszolva: minden AsyncTask-nál el kell készíteni a keretet. Ha csak a paraméterekben van változás (vagyis nagyjából ugyanazt végzi el, még ha egyszer pl. szöveget, máskor meg képet tölt is le), akkor sztem. elegendő egy AsyncTask-ot készíteni, de gyökeresen más feladatokra kénytelen leszel újakat készíteni. Arra még mindig nem jöttem rá, ez mennyiben egyszerűsíti a programot. De biztos van oka, hogy ilyet csináltak.
Nagyon örülök, ha tetszett a cikk, amennyire időm engedi, folytatni fogom. A baj az, hogy most is egyszerre három projekttel (egy billentyűzet, egy adatbáziskezelő és egy könyvolvasó) bíbelődöm, (meg van egy negyedik készen), és mindig lemaradok az írással. De ha van, akit érdekel, akkor igyekezni fogok!
[ Szerkesztve ]
-
thon73
tag
válasz pittbaba #529 üzenetére
Egyáltalán nem hülyeség. A legnagyobb gond az AsyncTask-ban, hogy a hívó Activity és az AsyncTask külön léteznek. Pl. indításkor még nem létezik AsyncTask; míg a készülék elfordításakor - átmenetileg - az Activity tűnik el. Valamilyen módon tudnia kell mindkét folyamatnak, hogy létezik-e a másik.
A timeConsumingTask valójában egy "változó", vagy C-beli fogalommal mutató, mely az elindult TimeConsumingTask típusú példányra mutat. Ha ennek null értéket adunk, attól a példány még létezik, esetleg fut is, amíg a GC el nem tünteti. Első próbálkozásra kézenfekvőnek tűnt ezt a változót használni:
- ha értéke null, akkor nincs futó AsyncTask (itt timeConsumingTask-ra bővítettük). Ezt fontos tudni, mert ilyenkor lehet csak pl. újra elindítani az AsyncTask-ot, különben több példány futna együtt, és keverednének az eredmények (nézd meg a log-ot az első próbálkozásoknál, ahol ez megtörténik: egyszerre több háttérfolyamat számol, függetlenül attól, hogy az Activity csak az egyikről "tud". A többit még nem takarította el a GC.)
- ha értéke nemnull, akkor van éppen aktív háttérfolyamat, és az érték arra mutat.
((A C mutatóaritmetika nehéz, de sokkal jobban segít megérteni ezeket a folyamatokat.))
Ki tudja, hogy a háttérszál befejeződött? Hát az onPostExecute metódus! (meg az onCancel is), tehát ők tudják "törölni" ezt a mutatót. Ez teszi lehetővé, hogy a háttérfolyamatot újra indítsuk (már amennyiben szükség van erre). ((De szükség lehet, mert a hibátlan lefutás csak annyit jelent, hogy a HÁTTÉRSZÁL hibátlanul futott! De a számítás nem biztos, hogy megfelelő eredményt adott, mert pl. egy file hiányzott!! Tehát újra kell számolni.))
Azért tudod itt írni a timeConsumingTask változót, mert "belső" osztályként készült az AsyncTask rész. Egyébként is tudnád (ha public), csak pl. callerActivity.timeConsumingTask-ként. Korábbi eszmefuttatás alapján az onPostExecute idején az Activity-nak léteznie KELL, bár ezt azért mindig ellenőriztük.
A későbbi megvalósításokban - mivel a timeConsumingTask null-ra állításával az abban tárolt (returnedResult) eredmény is elveszett - egy belső változó tájékoztatott a timeConsumingTask állásáról. ((Ilyen egyébként a task metódusai között is van, én - részben didaktikai okokból sajátot használtam, lehet még optimalizálni.)) A timeConsumingTask non-null értéke értéke azt jelentette: van már elindított (lehet, hogy befejezett) háttérszál, és a belső "state" változó tudta megmondani, hogy a futás befejezett-e v. sem. Ettől függetlenül a timeConsumingTask non-null értékét ellenőrizni kell, mert lehet, hogy még soha nem is indítottuk el, és emiatt nem is létezik (és akkor belső változói se léteznek, a programunk pedig - nem létező változó olvasásakor FC-t dob).
Van fent egy PackageSave2 cikk is, abban pont egy már meglévő programot illesztettem bele az AsyncTask keretbe. A cikk tartalmazza az üres keretet is, sztem. abból érdemes tovább építkezni.
Két fontos feladat van:
1. Mindkét osztálynak figyelnie kell, hogy létezik-e a másik! (Ez nagyon fontos, ezen lehet elbukni)
2. Gondoskodni kell arról, hogy csak egyetlen (vagy legalább ellenőrzött számú) AsyncTask futhasson egy időben. ((A korábban indítottak is tovább futnak, függetlenül attól, hogy a hivatkozásukat már lecseréltük))A triggerelést próbáltam, de mégis csak felesleges, mert amíg azt be nem fejezi az Activity, addig az onPostExecute sem fejeződhet be. (Voltaképp onnan hívjuk meg az Activity egy metódusát.) Inkább úgy kell szervezni a programot, hogy a Working-thread tényleg working-thread legyen, vagyis ott történjék a "munka", függetlenül attól, hogy egyes részei gyorsak vagy lassúak. Az Activity valójában csak egy indító keret lesz. Azt esetleg érdemes lenne megnézni, hogy ha az Activity-t meghívjuk egy másik Activity-ből, akkor a visszatérést hogyan lehet az onPostExecute-ba, vagy egy onnét triggerelt metódusba tenni. Ha előbb ki tudod próbálni, mint én, akkor mindenképp szólj, kérlek, mert nagyon érdekel!
(((Volna még egy kérdésem, minimálisan off-topic: nem érdemes ezt a diskurzust áttenni a cikkek hozzászólásába? Ott bőven van hely bármilyen hosszú eszmefutattásra. Saját ellenvéleményem: magyar nyelven praktikusan itt van az egyetlen élő fórum (és legyünk büszkék rá!!), tehát érdemes itt megbeszélni a kérdéses pontokat. Még akkor is, ha egy ekkora téma, mint az AsyncTask, nem hogy egy fórumba, de még egy emészthető cikkbe se fér bele.)))
-
thon73
tag
válasz pittbaba #531 üzenetére
Hogy az előző hozzászólást folytassam:
Én az onPreExec.-ben, vagy a háttérszál legelején (tehát nem az activity-ban!) kérném el, ami már megvan (sqlite lekérdezés). Ezt, ill. a netről érkező adatokat folyamatosan szedném össze, és alkalmanként az onProgressUpdate megjelenítené azokat, ill. jelezné, h. tart a folyamat. Az onPostExecute csak annyit tesz a képhez, hogy "oké, minden adat kirajzolva!"
Ha nincs pl. Wifi, akkor a háttérszál (hiba nélkül!!) befejezi a futást, és valahol kiírja, hogy "nincs net". Ez az az eset, amikor a háttérszál RENDBEN lefut, de a számítás "HIBÁS".
Valahova odateszel egy gombot, hogy frissítés, és akkor - ha éppen nem fut - újraindítja az egészet. Vagy, ha gondolod, időnként - ha éppen nem fut - újraindítja az egészet. Én ez utóbbit kissé "költségesnek érzem", ha látom, hol a busz, nem vagyok kíváncsi arra, hol lesz 10 mp múlva. Vagy legalábbis 3g-n nem, ami a buszmegállóban azért valószínű.Másik ötlet: a lekérések service-ként futnak, amik időnként szólnak a fő programnak, hogy ezt vagy azt írjon ki. Itt talán könnyebb a kettőnél több folyamat indítása, ill. az időzítés; de ezzel nincs sok tapasztalatom. Azt sokan írták, hogy AsyncTask helyett többnyire service-ben gondolkodnak.
Én is gratulálok a BKV kezdeményezéshez, én már a hétvégén ajánlgattam Pesten, h. létezik ilyen (csak nem találtam). Ezek szerint egy kicsit még várni kell rá... De jó lesz nagyon! Hátha még azt is megmondja, hogy egy nagy téren a 8 állásból melyikből indul az én buszom... ((Pestiek előnyben, én szegény vidéki GPS-sel közlekedem))
Úúú! csak lemaradtam egy kérdésről. Ami lejárt az a ProgressDialog. Sztem., ettől függetlenül prímán működik, de lecserélhető akár Fragment-re is. Csak az olyan összetetté tenné a kódot, hogy a lényeg eltűnne, ezért maradtam a "régi" megoldásnál. Meg azért is, mert én 5 hüvelyken élek, semmi szükségem (még) a fragmentekre, majd a Note 8"-en !
Az érték megőrzés másra vonatkozik: a végeredményt az AsyncTask osztályváltozója tárolja. Ha törlöd a mutatóját, akkor elveszik a végeredmény is. De egyébként az AsyncTask nem indítható ugyan újra, de nem veszik el (az eredmény sem), amíg új példányt nem indítasz.
Jól értettem a kérdést?[ Szerkesztve ]
-
thon73
tag
válasz pittbaba #535 üzenetére
Bocsánat, félreértettem.
A dokumentáció szerint az onRetain... helyett a setRetainInstance (boolean retain) használata javasolt. ((Gondolom, kompatibilitási problémák miatt az előző is működni fog.)) Ez más elven működik, nem egy objektumot, hanem az egész fragmentet (ami kb. egy activity, vagy activity rész) őrzi meg. Nagyképernyő és JB hiányában ebben még nem mélyedtem el, csak elolvastam. Megmondom őszintén, más részek sokkal inkább érdekeltek, mint az, hogy a rendszer egy jól ismert részét kicserélték. A nálaménál későbbi gépeken.
((Off: még mindig nem vagyok meggyőződve arról, hogy nyerek valamit a GB rendszer lecserélésével. Szintén SGS2. ÉS: néhány verzióval ezelőtt még nem láttam, h. használhatnék API11 feletti osztályokat - kompatibilitási kiegészítéssel. De lehet h. csak én voltam figyelmetlen...))A static-ról (c-s alapon) én is azt gondoltam, hogy az egyetlen példányt jelöl. DE NEM! (Olvasd el a többi részt is, megvilágosodik, remélem! ebben középen) Csak azt jelenti tehát, hogy a belső osztály v. változó nem a példányhoz, hanem a külső osztályhoz kötődik. Arról valóban gondoskodni kell, hogy EGYETLEN példány legyen, de ezt a fentiekben megtettük. Legfelső szintű osztályként nem kell a "static" és működni fog!
A programot úgyis tesztelni kell először, és akkor kiderül, hogy a tesztelők melyik megoldást tartják jobbnak, és átláthatóbbnak. Sztem. itt biztos találsz olyat, aki buszozik, és szívesen utazik ezzel.
Én beépítenék egy visszafelé mutató ellenőrzést is (a rosszindulatúak elkerülésére nem is teljes körben talán): ha elmozdult egy megálló, akkor visszaszól a központi szervernek, és jelzi a változást. Valahogy úgy, mint a túra-térképeknél leadott útvonal. Meg az igo is megkérdezi mindig "Megérkezett a célhoz?" -
pittbaba
aktív tag
válasz pittbaba #537 üzenetére
Találtam egy kérdéses részt az utolsó előtti részben, nekem kifagyás lett az eredménye, de lehet csak az én logikámban kell máshogy.
StarTask metódusnál az indítás előtti feltételed:
private void startTask(String route_id ,String stop_id){
try {
if (async_task == null || async_task.returnedResult !=null) {
indulhat_a_task... }Ebben az esetben akkor is indul a háttér task, ha már lefutott, de már megvan az eredmény. Szerintem csak akkor kell futtatni, ha a task nem fut(ott), vagy ha nincs eredmény. Így a hibajelenség is megszűnt.
if (async_task == null || async_task.returnedResult ==null) {
PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
pigster
senior tag
válasz pittbaba #540 üzenetére
setListAdapter akkor van, ha nem "sima" aktivityd van, hanem ListActivity (... extends ListActivity). Ekkor a listviewnak kötelezően @android:id/list id-t kell adni (vagy vmi ilyesmit)
Ha normál Aktivity van, akkor a setAdapter-t tudod használlniFIGYELEM! A többszázezres Samsung okostévék kéretlen reklámokat tolnak az arcodba.
-
thon73
tag
válasz pittbaba #538 üzenetére
Maga a task nem indulhat újra, de egy új példányt elindíthatsz belőle. Ha az AsyncTask értéke non-null (tehát van már futó/futott példány), és a returnedResult is értéket kapott, az azt jelenti, hogy ez az AsyncTask példány eredményesen végigfutott, csak azért tartottuk meg, hogy a returnedResult megmaradjon.
A hiba nem itt lesz, hanem valószínűleg ott, hogy az újraindításnál ugyanezt a task példányt indítod el. De ez csak feltételezés, mert a többi kódrészletet is látni kellene. Mit ír a LogCat? Lefagy v. FC? -
kltz
tag
válasz pittbaba #547 üzenetére
A manifest-ben kell beállítani a activity-nél, hogy mit történjen amikor elforgatod.
Ha API Level 13 alatt az configChanges = orientation ,ha nagyobb API Level-t használsz akkor a configChanges = screenSize, de ha mind2 esetben szeretnéd használni akkor configChanges = orientation | screenSize.
Alapbeállítás szerint amikor elforgatod akkor újra indul az activity és ott nem fut le a task. Ha ezeket beállítod és elforgatod nem indul újra csak a layout rendezi át.
Bővebben: [link]Üdv KLtz
-
thon73
tag
válasz pittbaba #547 üzenetére
A példaprogramban az eredményt az AsyncTask osztály tárolja, mert az az újraindításnál megmarad(hat). Az újrainduló Activity létrehozza az üres ListView-t, de azt az AsyncTask osztály tölti fel. Mivel az már lefutott, ezért a beépített rutinok nem indulnak el. Én külön is választottam az eredmény kijelzését végző updateUI-t. Mivel a ListView adatait az adapteren keresztül kapja, lehet, h. elegendő annak megadni az AsyncTaskban tárolt adatokat. Ilyenkor arra kell vigyázni, hogy az Asynctask létezzen az adapter indítása előtt. (Vagy az ellenőrizze a meglétét)
Ezt a "hibát" nem lehet egy sor átírásával megoldani, a program szerkezetét kell megfelelően elrendezni.[ Szerkesztve ]
-
Karma
félisten
válasz pittbaba #622 üzenetére
Nem vagyok nagy guruja a témának, de a Google kitalálta az ilyen felhasználáshoz az ADK-t, és vannak fain kulcsrakész lapok az ilyen hobbifejlesztéshez.
“All nothings are not equal.”
-
thon73
tag
válasz pittbaba #711 üzenetére
Én magam nem tudtam, de sztem. itt a megoldás: how-to-access-device-settings-programmatically
naandesh hozzászólása, első sor, ha gond az angol.
Írd meg, légyszi., hogy sikerült-e!Ja, és ne felejtsd az engedélyeket!! Köv. hozzászólásban ott van az is
[ Szerkesztve ]
-
thon73
tag
válasz pittbaba #751 üzenetére
A problémával csak felhasználóként találkoztam. [link] Ez a program olyat tud, hogy az előtérbe került hívást (még a hallgató felvétele előtt!!) háttérbe nyomhatod, ahonnét később (amíg a hívás tart) előtérbe lehet venni, és felvenni. Tehát elvileg megoldható.
((Mielőtt valaki megkérdezné, hogy ez mire jó: hosszú úton SVOX-szal szoktam könyvet felolvastatni. De ha hívás érkezik, akkor a felolvasás megszakad, majd a telefon felvétele után beleolvassa a könyvet a telefonba. Na ezt szoktam befejezni egy mozdulattal, mielőtt fogadom a hívást.)) -
pittbaba
aktív tag
válasz pittbaba #770 üzenetére
Úgy néz ki az async json lekérés indítása előtt kellett egy cancelDiscovery, így már nincs hiba. Azért a magyarázatára kíváncsi lennék miért zavarodik be a háttérfolyamat. Elvileg a startDiscovery is aszinkron fut, de ennek nem kellene a másikat zavarnia nem?
PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
Sianis
addikt
válasz pittbaba #790 üzenetére
Egyébként azt mondanám, hogy AndroidAnnotations idevágó része.
Írsz egy metódust, megtoldod @UiThread(delay=6000) annotációval és elfelejted a problémát egy percen belül. Ezzel bebiztosítod, hogy főszálon fusson és 6mp várakozás legyen a tényleges futtatása előtt.
Én minden új projektemben alapból használom az Annotations-t, mert nagyon felgyorsítja a fejlesztést, illetve csökkenti a repetatív feladatokat is.
Sianis
-
SektorFlop
aktív tag
válasz pittbaba #826 üzenetére
public void onReceive(Context context, Intent intent) {
Log.d("MSG", "onReceive start");
if ("android.intent.action.BOOT_COMPLETED".equals(intent.getAction())) {
Intent i = new Intent(context, MainActivity.class);
i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(i);
}
}Én így csináltam, nem rég. De látom nálad ez a rész volt kikommentelve.
"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."
-
Sianis
addikt
válasz pittbaba #833 üzenetére
Ezért írtam, hogy AndroidAnnotations-ös.
Sianis
-
SektorFlop
aktív tag
válasz pittbaba #839 üzenetére
Logcat-et másold ki lehet abból kitudunk deríteni valamit. Vagy egy elmebeteg ötlet, pakolj minden sor után egy Log-ot és lehet már azzal előrébb leszel hogy ha tudod melyik sornál van gubanc. És am egy buta kérdés, a "MainActivity"-el nem lehet baj?
[ Szerkesztve ]
"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."
-
pittbaba
aktív tag
válasz pittbaba #1498 üzenetére
Itt a megoldás:
[link]Valamiért ha a nap elmúlt idejére időzítünk (pl: 11:00-ra időzítem a következő eseményt, de már 13:00 óra van, azt gondolná az ember, másnap 11:00-kor fog aktivizálódni, hát nem.. ), akkor azonnal aktivizálódik, és lefut az onreceive, ezért időzítés előtt vizsgálni kell, elmúlt e már az időzített időpont, és ha igen, akkor hozzá kell adni egy napot a kezdő időponthoz:
if(alarm.getTimeInMillis() <= now.getTimeInMillis())
_alarm = alarm.getTimeInMillis() + (AlarmManager.INTERVAL_DAY+1);
else
_alarm = alarm.getTimeInMillis();PH Konfigom: Gigabyte GA-H97M-D3H, i7 4790K,GTX 960, Seasonic SS-620GM
-
thon73
tag
válasz pittbaba #1716 üzenetére
Lehet, h. hülyeség, amit gondolok, de a "kilövés" az egész Application process-t érinti. A handler azon belül van, - elvileg - az is megszűnik. Arra kellene rájönni, hogy miért lő ki a rendszer egy előtérben lévő Applicationt? B lehetőség: Ha esetleg nem az application process indítaná a handler-t? Pl. service - bár ezzel nincs tapasztalatom.
-
Karma
félisten
válasz pittbaba #1719 üzenetére
Egy dolog hogy ágyúval verébrének tűnik, de ha egyszer ez a rendeltetésszerű használata az Androidnak, nem pedig szembemenni a UI életciklussal, szerintem nem kéne kategorikusan elvetned.
Nem nagy cucc egyébként egy Service osztályt írni, én is meglepődtem az első után, visszatekintve a félelmeimre.
[ Szerkesztve ]
“All nothings are not equal.”
Új hozzászólás Aktív témák
- Azonnali informatikai kérdések órája
- A Gigabyte is visszaveszi alaplapjainak alapértelmezett tuningját
- Nintendo Switch
- A fociról könnyedén, egy baráti társaságban
- Milyen videókártyát?
- TCL LCD és LED TV-k
- Egyéni arckép 1. lépés: ARCKÉPHEZ VALÓ JOGOSULTSÁG
- Háztartási gépek
- AMD Radeon™ RX 470 / 480 és RX 570 / 580 / 590
- Elemlámpa, zseblámpa
- További aktív témák...
- LG NanoCell 55NANO766QA Halvány píxel csík
- Philips 58PUS8545/12 1 ÉV GARANCIA Játék üzemmód
- Tyű-ha! HP EliteBook 850 G7 Fémházas Szuper Strapabíró Laptop 15,6" -65% i7-10610U 32/512 FHD HUN
- Bomba ár! HP EliteBook 840 G5 - i5-8G I 8GB I 128GB SSD I 14" FHD I HDMI I Cam I W10 I Gari!
- The Last of Us Part I Ps5