Google Android
Jelentkezz be a hozzászóláshoz.
#18754
köszi
#18753
A mai TV-k ben viszont van médialejátszó, ennyi erõvel 😊
Mondjuk én telora csak próbaképp felraktam filmet fullhd-ban, hát szépszép, de szerintem le is merülne ha megnéznék egy filmet, plusz utazás közbe inkább mást csinálok 😊
Mondjuk én telora csak próbaképp felraktam filmet fullhd-ban, hát szépszép, de szerintem le is merülne ha megnéznék egy filmet, plusz utazás közbe inkább mást csinálok 😊
\"Say \'what\' again. Say \'what\' again, I dare you, I double dare you motherfucker, say what one more Goddamn time! \" Uplay: Mekee85 Steam: psn_mekee85 Origin: Mekee85
#18752
Jah telepítsd az angolt, 3 nyelvet tud egyszerre kezelni. A javaslatokat asszem nem lehet kikapcsolni. Én most Kii Keyboard Premium-ot használok.
Értem én, csak leszarom. :) Nem kell válaszolnod, igazam van.
![[HUN]FaTaL](https://media.sg.hu/forum/avatars/10557508481320070594.gif)
#18751
Telepítsd fel az angol szótárat.
http://goo.gl/gd6Zi5
#18750
"Javasolt szavak" illetve az autocorrectet is jólenne kikapcsolni, mert nemtudok vele angol szöveget írni.
#18749
😄
: Every man lives, not every man truly dies.: Razor,Lightning Revenant
#18748
Ismertek ilyesmi programot, ami kiér a widget terület széléig, és ha berakok alá egy pontosan akkora képet, mint amekkora a widget, akkor nem akarja átméretezni?
sg discord: https://discord.gg/ezkyQvNE
#18747
Használja valaki a Swiftkey programot? Hogyan lehet eltávolítani azt a sort ahol megjeleníti az esetleges szavakat?
#18746
egy olyan kerdesem lenne meg, h barmilyen bluetooth-os telo felismer egy bluethoot-os billenttyuzetet, egeret?
#18745
olyan telot veszek amin van hdmi vagy mhl, ezekkel ra lehet kotni tv re
#18744
Meg is vettem, mint minden filléres szart. 😄 Ha lát valaki profi idõjárás jelzõt ami akciós. Tell me.
"Anime is the proof that two nukes weren't enough."
#18743
koszi kituno valaszt adtal
#18742
Super Hexagon learazva
Regards,
#18741
Mert a mai telefonokat rendkívül nehéz rákötni egy TV-re 😊
“A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable” _____/|_____\o/___ Cápatámadás
#18740
Kérdés továbbá, hogy szükséges-e, ha a kijelzõ felbontása kisebb, ugye...
\"Say \'what\' again. Say \'what\' again, I dare you, I double dare you motherfucker, say what one more Goddamn time! \" Uplay: Mekee85 Steam: psn_mekee85 Origin: Mekee85
#18739
Lathato akadasok sztem nelkul biztosan nem viszi egy mai teloban levo 2 magos proci az 1080p-t. Az egy 2 GHz-es core 2 duo-t is meg tudna izzasztani. Esetleg az abszolut csucs telokbam levo 2 ghz kornyeki a15 procik, de abban is ketelkednek. Szoval az ilyen videok lejatszasa minden esetben a gpu-n szokott tortenni, es igy tudnak tenylegesen tokeletesen akadas nelkul lejatszodni.
Egy mai 2 magos telo melle szoktak olyan gpu-t h ezzel ne legyen gond, ha erre iranyul a kerdes, de nem biztos h minden esetben. Amelyik telok pl 1080p-ben vesznek fel videot (GS2, Galaxy Nexus es kesobbi modellek), azok vissza is tudjak azt jatszani 😊
Egy mai 2 magos telo melle szoktak olyan gpu-t h ezzel ne legyen gond, ha erre iranyul a kerdes, de nem biztos h minden esetben. Amelyik telok pl 1080p-ben vesznek fel videot (GS2, Galaxy Nexus es kesobbi modellek), azok vissza is tudjak azt jatszani 😊
Regards,
#18738
de azert meg varom az ehhez kapcsolatos infokat, elvileg akkor egy 2magos 1Ghz-es telo siman viszi a full hd-t igaz?es amugy a teloba beepitett gpu-k reszt vesznek a feldolgozasban?(lehet hule kerdes)
#18737
koszi
#18736
Ha jól tudom elvileg egy Motorola Defy is le tudja azt játszani, mert a legtöbb mobil/normális processzorba direkt van bele építve népszerû kodekekhez dekóder.
“A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable” _____/|_____\o/___ Cápatámadás
#18735
sziasztok, azt szeretnem megkerdezni, mekkora proci kell egy teloba h gond nelkul lejatszon egy full hd (1920x1080p)-s filmet?
#18734
Felig off, de ez valami oriasi:
Regards,
#18733
Sikerült mégis, még talán GB-re való VoiceSearch.apk, és amúgy igen diktálni lehet neki 😊
Sajnos magyarul általában kurva nagy hülyeségeket hoz ki 😄
Sajnos magyarul általában kurva nagy hülyeségeket hoz ki 😄
#18732
Nem lenne rossz, de valamiért Voice Search kell neki a hangjegyzetekhez (lehet nem is hangjegyzet funkció az, hanem beszédfelismerés? 😄).
Sajnos a 4.2.2-es custom ROM-omon az nincs, GApps-bõl nem tudtam ráerõszakolni (elég fura FC-t produkál, nem Java stacktrace-t nyom a logcatbe, hanem memory dumpot). Azért még a ROM installerbe belenézek hátha volt mégis benne, csak én pucoltam ki valamiért a systembõl 😊
Sajnos a 4.2.2-es custom ROM-omon az nincs, GApps-bõl nem tudtam ráerõszakolni (elég fura FC-t produkál, nem Java stacktrace-t nyom a logcatbe, hanem memory dumpot). Azért még a ROM installerbe belenézek hátha volt mégis benne, csak én pucoltam ki valamiért a systembõl 😊
#18731
Egyszeru, puritan, letisztult ahogy Guglitol megszokhattuk 😊 Jo cucc. Widgetje is van termeszetesen.
Saor Alba
#18730
nem nagyon használtam jegyzet appokat, de pár napja mikor ezt megláttam már töltöttem is le 😄 Google minõség, ez mindent elárul 😊
ASUS B550-PLUS, AMD 5600X, 32 GB DDR4, EVGA RTX 3070, SM-OB1, HD 600 + Asus Xonar DX, TonePort UX1 + Alesis Elevate 5, Novation Circuit \o/
#18729
Igen erre is gondoltam, 100-200 órát elmegy (kivéve amikor csinál vmit a cpu, akkor akad az egész, de butter nélkül gondolom ilyen).
Meg az is gond, hogy ezeréves szar kernelre tákolták (állítólag Froyo kernel) rá az ICS-t, mert GB alatt nem volt ennyi lassulás.
Meg az is gond, hogy ezeréves szar kernelre tákolták (állítólag Froyo kernel) rá az ICS-t, mert GB alatt nem volt ennyi lassulás.
http://goo.gl/gd6Zi5
#18728
Ú köszi szépen!
Eddig a szintén Google féle jegyzetek alkalmazást használtam.
Azzal sincs bajom, de az kicsit fapadosnak tûnik ehhez képest. Mindenképp kipróbálom.
Eddig a szintén Google féle jegyzetek alkalmazást használtam.
Azzal sincs bajom, de az kicsit fapadosnak tûnik ehhez képest. Mindenképp kipróbálom.
Semmi pánik négerek vagyunk! Azért jöttünk, hogy kölcsön kérjünk egy kis füvet!
#18727
Nem nagyon kene ilyen lassulasnak tortennie, de tippre hosszabb tavon pl az is okozhat ilyen, hogy a nativ kodoknal elszivarog a memoria, igy az OS-nek kevesebbel kell gazdalkodnia, kevesebb progit tud bent tartani a memoriaban, tobb mindent ujra kell tolteni, stb. Egy par 100 orat azert illene elmennie ujrainditas nelkul, erezheto lassulas nelkul.
Mas jegyzet progi a Google-tol:
Keep
Mas jegyzet progi a Google-tol:
Keep
Regards,
#18726
Értem én, csak leszarom. :) Nem kell válaszolnod, igazam van.
#18725
azzal én is szórakoztam pár hétig 😊 de aztán meguntam
#18724
Nem tudom már, hogy ki de aki a Hill Climb Racing játékot ajánlotta itt valaki másnak az elmehet a sunyiba 😄
már 30 órát beleöltem kb a játékba, most csináltam meg fullosra az 5. jármûvet -.- 😄
már 30 órát beleöltem kb a játékba, most csináltam meg fullosra az 5. jármûvet -.- 😄
#18723
Konkrétan pl buszon fordult elõ meg gyár melletti dohányzóban. 😊
Szóval mondhatjuk igen, mind a két esetben fémes burkolattal voltam körülvéve.
Viszont amikor gyáron belül próbáltam eddig néhányszor, ott mindig mûködött, pedig ott is van fém jócskán.
Böngészés minden esetben gyors, csak youtube kínlódik néha.
Szóval mondhatjuk igen, mind a két esetben fémes burkolattal voltam körülvéve.
Viszont amikor gyáron belül próbáltam eddig néhányszor, ott mindig mûködött, pedig ott is van fém jócskán.
Böngészés minden esetben gyors, csak youtube kínlódik néha.
Semmi pánik négerek vagyunk! Azért jöttünk, hogy kölcsön kérjünk egy kis füvet!
#18722
volt rá példa, fõleg árnyékolt helyeken (pl cégben, ahol sok a fémburkolat a falakon)
RPG, Photoshop, \../, `;,,;´ ,\../
#18721
Olyanom van, hogy 3G-H erõsségû T-mobilos mobilnettel néha youtube videók lejátszásánál csak annyi történik, hogy forog a karika pár másodpercig, majd kiírja, hogy "Gond volt a hálózattal".
Természetesen nem életbevágó probléma, csak érdekelne, hogy olykor esetleg más is szokott-e még ilyet tapasztalni?
Természetesen nem életbevágó probléma, csak érdekelne, hogy olykor esetleg más is szokott-e még ilyet tapasztalni?
Semmi pánik négerek vagyunk! Azért jöttünk, hogy kölcsön kérjünk egy kis füvet!
#18720
"Egyaltalan nem hibas feltetelezes, nagyon sok esetben gyorsit, es effektive semmibe nem kerul"
Akkor friss bekapcsolás után miért indulnak gyorsabban a programok, mint akkor, amikor a rendszer már egy csomó szart a memóriában tart? 😊 Most egy egy magos, régi telefonról beszélek, az új szörnyeken lehet, hogy nem kerül semmibe.
"A GC tipikusan 5 ms-en belul lefut, raadasul gingerbread ota konkurrensen fut, igy ha nincs valami brutalis szemetmennyiseg, gyakorlatilag kizart hogy eszrevedd hogy egyaltalan fut."
Nem kizárt, hogy a telefonom ROM-ja egy kalap szar, fõleg a régi kernel miatt.
"Siman lehet egyebkent hogy a Process-ed ures, csak epp meg nem lett felszabaditva, ezek nem azonnal mennek."
Ez lehet. 😊
Lifecyclet ismerem, a killprocesst nem tudtam, hogy nem azonnal szabadít.
Akkor friss bekapcsolás után miért indulnak gyorsabban a programok, mint akkor, amikor a rendszer már egy csomó szart a memóriában tart? 😊 Most egy egy magos, régi telefonról beszélek, az új szörnyeken lehet, hogy nem kerül semmibe.
"A GC tipikusan 5 ms-en belul lefut, raadasul gingerbread ota konkurrensen fut, igy ha nincs valami brutalis szemetmennyiseg, gyakorlatilag kizart hogy eszrevedd hogy egyaltalan fut."
Nem kizárt, hogy a telefonom ROM-ja egy kalap szar, fõleg a régi kernel miatt.
"Siman lehet egyebkent hogy a Process-ed ures, csak epp meg nem lett felszabaditva, ezek nem azonnal mennek."
Ez lehet. 😊
Lifecyclet ismerem, a killprocesst nem tudtam, hogy nem azonnal szabadít.
http://goo.gl/gd6Zi5
#18719
Egyaltalan nem hibas feltetelezes, nagyon sok esetben gyorsit, es effektive semmibe nem kerul. Naplozas pl tuti nem lenne ingyen, a szokasaid alapjan be kene toltenie elore programokat, a betoltes enne az aksit (sokszor feleslegesen), meg sokkal komplexebb es ezer masik problemat felvet, ha rosszul tudja a szokasaid, rosszabb mintha nem is lenne.
A GC tipikusan 5 ms-en belul lefut, raadasul gingerbread ota konkurrensen fut, igy ha nincs valami brutalis szemetmennyiseg, gyakorlatilag kizart hogy eszrevedd hogy egyaltalan fut.
Siman lehet egyebkent hogy a Process-ed ures, csak epp meg nem lett felszabaditva, ezek nem azonnal mennek.
Lasd itt meg itt
A GC tipikusan 5 ms-en belul lefut, raadasul gingerbread ota konkurrensen fut, igy ha nincs valami brutalis szemetmennyiseg, gyakorlatilag kizart hogy eszrevedd hogy egyaltalan fut.
Siman lehet egyebkent hogy a Process-ed ures, csak epp meg nem lett felszabaditva, ezek nem azonnal mennek.
Lasd itt meg itt
Regards,
#18718
Hat de most is tarhelyre kell irogatni, mert bármikor kiloheti. Egyébként meg root nélkül nem baszogat senki semmit, amit nem akarsz.
http://goo.gl/gd6Zi5
#18717
Így látatlanban ha valami kiírsz tárhelyre, azt onnantól bármi baszogathatja, míg a Dalvik VM-ben szépen elfutogat magában, õ se borít meg senki mást, meg õt se 😊
“A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable” _____/|_____\o/___ Cápatámadás
#18716
Egyébként én az állandó fájlba írkálást (az activity állapotát) tartom baromságnak, sokkal jobb lenne, ha valami fájlba hibernálná az egészet, amikor kilövi, aztán azt töltené vissza. Bár gondolom oka van, hogy nem így lett az API megcsinálva.
http://goo.gl/gd6Zi5
#18715
"Nem tudom, legtöbb alkalmazást elnézve ekkor ugyanaz az xml kerül betöltésre"
Ilyen alkalmazást én még egyet sem láttam. Konkrétan melyik barom fejlesztõ tölti be az álló nézetet fekvõnek is? Ha mégis ezt csinálja, akkor meg miért nem tiltotta le a manifestben?
Az, hogy ugyanúgy néz ki az nem jelenti, hogy nem kell újratölteni, pl. ha szélesebb egy edittext akkor ugye az másik xml (vagy legalábbis a forgatástól a mérete megváltozik).
A többit passzolom, nem nagyon használtam még ezt a részét az SDK-nak. XML-t nézegetni tudsz szerintem, de akkor neked kell lekezelni mindent az onConfigurationChange metódusban.
"-programozónak explicite kelljen jeleznie, hogy újrapéldányosítást kér (feltételezve, hogy valóban helytálló a megfigyelésem)"
Szerintem ez nem megoldható.
Ilyen alkalmazást én még egyet sem láttam. Konkrétan melyik barom fejlesztõ tölti be az álló nézetet fekvõnek is? Ha mégis ezt csinálja, akkor meg miért nem tiltotta le a manifestben?
Az, hogy ugyanúgy néz ki az nem jelenti, hogy nem kell újratölteni, pl. ha szélesebb egy edittext akkor ugye az másik xml (vagy legalábbis a forgatástól a mérete megváltozik).
A többit passzolom, nem nagyon használtam még ezt a részét az SDK-nak. XML-t nézegetni tudsz szerintem, de akkor neked kell lekezelni mindent az onConfigurationChange metódusban.
"-programozónak explicite kelljen jeleznie, hogy újrapéldányosítást kér (feltételezve, hogy valóban helytálló a megfigyelésem)"
Szerintem ez nem megoldható.
http://goo.gl/gd6Zi5
#18714
"Nem tudom, legtöbb alkalmazást elnézve ekkor ugyanaz az xml kerül betöltésre, és nekem sem kellett eddig még újat létrehoznom emiatt"
Nagyon durván flexibilis az Android layout kezelése, eddig max talán a WPF féle xaml layoutoknál láttam ekkora flexibilitást, mióta ismerem ezeket sokszor egyenesen gagyinak érzem a HTML5/CSS3 adta lehetõségeket, persze JS-el megoldható sok minden de azért akkor is.
Nagyon durván flexibilis az Android layout kezelése, eddig max talán a WPF féle xaml layoutoknál láttam ekkora flexibilitást, mióta ismerem ezeket sokszor egyenesen gagyinak érzem a HTML5/CSS3 adta lehetõségeket, persze JS-el megoldható sok minden de azért akkor is.
#18713
"Bár gondolom a butterrel reszeltek rajta, nekem még ICS van."
Nekem mióta 4.2.2 van a "szegény" (a Samsung szerint már az ICS futtatására is teljesen alkalmatlan...) Gio-mon, azóta nagyon ritkán tapasztalok GC okokra visszavezethetõ lassulásokat, max kb hetente 1x amikor van úgy 8-10 alkalmazás az alkalmazásválasztó listában (ezek szerint így mondják szépen a taskváltót 😊) és valami kövérebb dolgot indítanék hirtelen.
Ha megpróbálok visszaemlékezni annak idején GB romokkal ezerszer szarabb volt a helyzet. ICS-t azt nem sokáig használtam, de azzal sem volt ennyire még fényes a helyzet.
Nekem mióta 4.2.2 van a "szegény" (a Samsung szerint már az ICS futtatására is teljesen alkalmatlan...) Gio-mon, azóta nagyon ritkán tapasztalok GC okokra visszavezethetõ lassulásokat, max kb hetente 1x amikor van úgy 8-10 alkalmazás az alkalmazásválasztó listában (ezek szerint így mondják szépen a taskváltót 😊) és valami kövérebb dolgot indítanék hirtelen.
Ha megpróbálok visszaemlékezni annak idején GB romokkal ezerszer szarabb volt a helyzet. ICS-t azt nem sokáig használtam, de azzal sem volt ennyire még fényes a helyzet.
#18712
"Képernyõ elforgatáskor muszáj újratöltenie az activityt, mi mást csináljon?"
Nem tudom, legtöbb alkalmazást elnézve ekkor ugyanaz az xml kerül betöltésre, és nekem sem kellett eddig még újat létrehoznom emiatt - neked mik az ilyen irányú tapasztalataid? Megoldható lenne pl, hogy:
-programozónak explicite kelljen jeleznie, hogy újrapéldányosítást kér (feltételezve, hogy valóban helytálló a megfigyelésem)
-forgatásnál megnézi, van-e másik, jobban megfelelõ XML, és csak akkor történjen meg az újraindítás (szerintem tökéletes lenne)
Manifestes workaroundot ismerem, használom is, csak arra lettem volna kíváncsi, hogy miért így oldották meg pl a forgatás kezelést, ahogy (biztos vagyok benne, hogy kimerítõen elemezték az esetleges alternatívákat).
Én az összes hosszú ideig tartó mûveletet service-ben futtatnám, ha jól rémlik, Android kilövési sorban az hátrébb is van, mint az onDestroy-olt Activity.
Nem tudom, legtöbb alkalmazást elnézve ekkor ugyanaz az xml kerül betöltésre, és nekem sem kellett eddig még újat létrehoznom emiatt - neked mik az ilyen irányú tapasztalataid? Megoldható lenne pl, hogy:
-programozónak explicite kelljen jeleznie, hogy újrapéldányosítást kér (feltételezve, hogy valóban helytálló a megfigyelésem)
-forgatásnál megnézi, van-e másik, jobban megfelelõ XML, és csak akkor történjen meg az újraindítás (szerintem tökéletes lenne)
Manifestes workaroundot ismerem, használom is, csak arra lettem volna kíváncsi, hogy miért így oldották meg pl a forgatás kezelést, ahogy (biztos vagyok benne, hogy kimerítõen elemezték az esetleges alternatívákat).
Én az összes hosszú ideig tartó mûveletet service-ben futtatnám, ha jól rémlik, Android kilövési sorban az hátrébb is van, mint az onDestroy-olt Activity.
/*WTF?!*/
#18711
Képernyõ elforgatáskor muszáj újratöltenie az activityt, mi mást csináljon? Nem tudja kitalálni, hogy fektetve hogy néz ki, újratölt egy másik xml-t. Ha meg mégsem akarod, hogy újratöltsön akkor kilövöd a manifestben, beállítod, hogy orientationchangenél ne töltse újra és kész. 😊
Akkor maradjon a sima másolás.
Akkor maradjon a sima másolás.
http://goo.gl/gd6Zi5
#18710
Nézd, nálam nem a memóriafoglalás okozza a problémákat (bár ott sem értem, hogy miért kell egy már bezárt Activity példányhoz tartozó objektumokat (nem a .class-eket!) tárolni, hisz úgyis újak fognak létrejönni következõ onCreate során), hanem hogy egy destroy-olt Activity-hez tartozó szálak miért kerülnek még ütemezésre, hiszen Activity újraindításakor egy új példány fog létrejönni, és onDestroy elõtt már megtörténik a bundle elmentése, ergo háttérszál nem sok hasznos dolgot csinálhat - SDK ajánlásai szerint. Engem ez az egész kicsit a cooperative multitaskra emlékeztet jellegében. Ott is ugye, amíg minden alkalmazás megfelelõen mûködött, nem volt gond. Csak ha elõfordult egy gányul megírt, vagy hibás alkalmazás... Itt persze messze nem olyan súlyosak a következmények, "csak" az erõforrások pazarlódnak.
API dokumentáció általában valóban jó, de az csak azt írja, hogy mivel mit lehet elérni, de azt nem, hogy mi a mögötte meghúzódó koncepció. Lásd még képernyõ elforgatáskori onDestroy-onCreate páros. Értem én, hogy ekkor esetleg már más layout lehet a megfelelõ, de szerintem messze nem ez a jellemzõ, és elég nagy lehet az ebbõl adódó overhead (még szerencse, hogy erre is van workaround).
Szerintem speciel pont a fájlletöltés a legjobb példa a service használatára😊
API dokumentáció általában valóban jó, de az csak azt írja, hogy mivel mit lehet elérni, de azt nem, hogy mi a mögötte meghúzódó koncepció. Lásd még képernyõ elforgatáskori onDestroy-onCreate páros. Értem én, hogy ekkor esetleg már más layout lehet a megfelelõ, de szerintem messze nem ez a jellemzõ, és elég nagy lehet az ebbõl adódó overhead (még szerencse, hogy erre is van workaround).
Szerintem speciel pont a fájlletöltés a legjobb példa a service használatára😊
/*WTF?!*/
#18709
"-ami appot nemreg hasznaltal, nagyobb esellyel fogod ujra elinditani a kozeljovobe"
Ez egy eleve hibás feltételezés. Inkább naplózná miket használok gyakran.
"-amint memoriara van szukseg, a rendszer felszabaditja a bezart programok altal lefoglalt memoriat a legregebbivel kezdve, igy effektive semmi hatranya a dolognak."
Csak épp a GC baromi lassú, ez a probléma. Bár gondolom a butterrel reszeltek rajta, nekem még ICS van.
Ez egy eleve hibás feltételezés. Inkább naplózná miket használok gyakran.
"-amint memoriara van szukseg, a rendszer felszabaditja a bezart programok altal lefoglalt memoriat a legregebbivel kezdve, igy effektive semmi hatranya a dolognak."
Csak épp a GC baromi lassú, ez a probléma. Bár gondolom a butterrel reszeltek rajta, nekem még ICS van.
http://goo.gl/gd6Zi5
#18708
Ha eppen nem fut az Activity, akkor legalabb az onPause-nak meg kellett hivodnia, ahol illik gondoskodni rola, hogy ne nagyon fusson hosszabb ideig terhelo dolog. Hosszabb ideig a hatterben futasra egyebkent is Service-ek hasznalandok.
Annak pedig hogy mi az oka, hogy a memoriaban marad egy app kilepes utan:
-ami appot nemreg hasznaltal, nagyobb esellyel fogod ujra elinditani a kozeljovoben (akkor is ha elotte kifejezetten kileptel belole), igy gyorsitja az ujboli inditast
-amint memoriara van szukseg, a rendszer felszabaditja a bezart programok altal lefoglalt memoriat a legregebbivel kezdve, igy effektive semmi hatranya a dolognak.
Egyebkent (mint kb mindenrol) egy rakas nagyon jol osszeszedett tema van rola a neten, es az API-k is nagyon jol dokumentaltak, pelda kodok is vannak, szoval felesleges talalgatni rola, egyszerubb utananezni 😊
Annak pedig hogy mi az oka, hogy a memoriaban marad egy app kilepes utan:
-ami appot nemreg hasznaltal, nagyobb esellyel fogod ujra elinditani a kozeljovoben (akkor is ha elotte kifejezetten kileptel belole), igy gyorsitja az ujboli inditast
-amint memoriara van szukseg, a rendszer felszabaditja a bezart programok altal lefoglalt memoriat a legregebbivel kezdve, igy effektive semmi hatranya a dolognak.
Egyebkent (mint kb mindenrol) egy rakas nagyon jol osszeszedett tema van rola a neten, es az API-k is nagyon jol dokumentaltak, pelda kodok is vannak, szoval felesleges talalgatni rola, egyszerubb utananezni 😊
Regards,
#18707
Hm, ebben van igazság. De én tudok olyan dolgot, amihez háttérszál kell. Pl. tegyük fel másolsz valami nagy fájlt (vagy töltesz le ftprõl) és háttérbe rakod az appot. Gondolom én attól még örülsz neki, ha másol. Viszont nem hiszem, hogy ez service-szel jó megoldás lenne, az inkább idõzített folyamatokhoz való, nem?
http://goo.gl/gd6Zi5
#18706
"Ezt szerintem máshogy nem is lehetne megoldani, különben a háttérben semmit sem tudnál csinálni."
Háttérben végrehajtott komolyabb mûveletekre nem a Service-t kéne használni? Egyáltalán, egy activity két példánya (másodszori onCreate után) hogy kommunikál, onSaveInstance Bundle-ba raksz egy referenciát a worker szálra?
Egyébként ha valaki a vissza gombbal zár be egy Activity-t (amellyel ekvivalens emlékeim szerint az Activity.finish, tehát killProcess hatékonyabb), akkor feltehetõen nem kíváncsi az ottani mûveletek eredményére, felesleges tovább engedni a szálakat...
Háttérben végrehajtott komolyabb mûveletekre nem a Service-t kéne használni? Egyáltalán, egy activity két példánya (másodszori onCreate után) hogy kommunikál, onSaveInstance Bundle-ba raksz egy referenciát a worker szálra?
Egyébként ha valaki a vissza gombbal zár be egy Activity-t (amellyel ekvivalens emlékeim szerint az Activity.finish, tehát killProcess hatékonyabb), akkor feltehetõen nem kíváncsi az ottani mûveletek eredményére, felesleges tovább engedni a szálakat...
/*WTF?!*/
#18705
Akkor ezekszerint kilõ mindent. Akkor már csak azt nem tudom, hogy a leállítás gomb miért marad aktív, mintha még futna valami.
"és ugye a szálak (és úgy általában, minden) leállításáról a programozónak kell explicite gondoskodnia"
Ezt szerintem máshogy nem is lehetne megoldani, különben a háttérben semmit sem tudnál csinálni.
" Viszont ezt csúnya megoldásnak tartom, és jobb szeretnék ajánlások szerint dolgozni, csak néha tényleg elgondolkozom, hogy mi is lehet a megfontolás a hasonló dolgok mögött..."
Valóban nem olyan szép, viszont többen is megköszönték már, hogy nem rohasztom a memóriában feleslegesen az appot kilépés után. Persze elméletben elég lenne az activity.finish() is, gondolkodtam már rajta, hogy átírom.
"és ugye a szálak (és úgy általában, minden) leállításáról a programozónak kell explicite gondoskodnia"
Ezt szerintem máshogy nem is lehetne megoldani, különben a háttérben semmit sem tudnál csinálni.
" Viszont ezt csúnya megoldásnak tartom, és jobb szeretnék ajánlások szerint dolgozni, csak néha tényleg elgondolkozom, hogy mi is lehet a megfontolás a hasonló dolgok mögött..."
Valóban nem olyan szép, viszont többen is megköszönték már, hogy nem rohasztom a memóriában feleslegesen az appot kilépés után. Persze elméletben elég lenne az activity.finish() is, gondolkodtam már rajta, hogy átírom.
http://goo.gl/gd6Zi5