Keresés

Hirdetés

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

  • thon73

    tag

    Nagy örömmel találtam rá erre a fórumra. Sajnos az Android programozás nem örvend (még) nagy népszerûségnek magyar nyelven.

    Kérdésem: Van-e valakinek tapasztalata AIDE (on-board) fejlesztõkörnyezettel? Már a második projektnél tapasztalom, hogy míg Eclipse alatt gond nélkül fordul (és fut) a látszólag nem hibás program, addig az AIDE alatt FC-vel kilép. Mivel AIDE alatt a debug "elég" korlátozott, eddig nem jöttem rá a hiba okára. (Eclipse alatt meg nincs is hiba) ((És alkalmanként szükségem lenne a fejlesztés on-board folytatására.))

    A kérdésen kívül: kezdeti tapasztalatokat egy blogban kezdtük el leírni (lattilad.org/android), szerintem hasznos forrás a hozzánk hasonló kezdõ ill. hobbiprogramozóknak.

  • thon73

    tag

    válasz Kicsikaszás #273 üzenetére

    Ismerős érzés! Magyar nyelven (e fórumot kivéve) nagyon kevés forrást találtam.
    Elkezdtünk éppen ezért egy blogot, ahol mindent leírtunk, amit csak androidon/androiddal csináltunk. Szerintem kezdőknek kiváló kiindulópont: a fejlesztőrendszer telepítése, egyszerű programok fejlesztése, egy-két fontos alkalmazás.
    Itt található:
    lattilad.org/android

    (Ez dave-11 és pigster hozzászólásához is csatlakozik)

    Boldog Karácsonyt Mindenkinek!

    [ Szerkesztve ]

  • thon73

    tag

    válasz SektorFlop #278 üzenetére

    Az nem megoldás, ha te magad mentesz el egy flag-et az első indításkor? Legjobb talán a preferences-be, de a saját file terület is egyszerűnek tűnik. Uninstall (törlés) során ez is törlődik, egyébként meg mindig ott lesz, és így ellenőrizhető, hogy volt-e már indítás.

  • thon73

    tag

    Van valakinek tapasztalata Android SDK-val Ubuntu 12.04 (vagy hasonló) alatt?
    Addig eljutottam, hogy 32 bites Oracle (Sun) Java 6 Jdk az igazán hozzávaló. (Egyéb JDK-ról megoszlanak a vélemények, de most nem ez a kérdés.)
    A kérdés az: ha több Java JDK van telepítve a gépen, akkor hogyan tudom kiválasztani, hogy az Android SDK melyiket használja? (Persze leginkább úgy, hogy az általában használt JRE ill. a default JDK se változzon meg. Ha egyáltalán lehet ilyet.)

    Előre is köszönöm!

  • thon73

    tag

    válasz thon73 #325 üzenetére

    Senki sem tudja, hogyan lehet a JDK-t beállítani Android SDK alatt? (Az OpenOffice visszarakta az Openjdk-jdk-t, és nem tudom, az Android melyiket használja.)
    Más: ha valaki AsyncTask-ot használ, egy blogcikk-sorozatban összeírtam, amit összeszedtem ill. kipróbáltam. ([link], folytatás folyamatban) Kicsit hosszú ahhoz, hogy a fórumra kerüljön, de ha van itt további ötlet / egyéb tapasztalat / ellenvetés, annak örülök.

  • thon73

    tag

    válasz thyrpacia #351 üzenetére

    Köszi, ez a beállítási lehetőség megvan. Csak úgy tűnt számomra, hogy ez az aktuális jdk kompatibilitási szintjét állítja be. Vagyis, ha pl Java JDK 7 (1.7) van fent, akkor az még beállítható úgy, mintha mondjuk 1.6 lenne. A hozzászólások többsége azonban arról ír, hogy az Android fordító a Sun/Oracle JDK 1.6 "köztes" kódjából dolgozik tovább. Mivel a "köztes" byte-kód nem feltétlenül egyezik meg az egyes gyártók között, ezért nem javasolják az OpenJDK használatát. A Sun Java 1.7 viszont megint más kódot használ, mint az 1.6, sőt arról is olvastam, hogy Open JDK az alapja. Ember legyen a talpán, aki kibogozza, hogy mi az igazság. :(((
    JRE szerintem bármi lehet, ott nincs "köztes-kód" használat, tehát ezek kompatibilisek (kell legyenek). Emiatt levettem a Sun kivételével a többi JDK-t (próbaképp), de az Open Office azonnal visszatelepítette az OpenJDK (JDK-t). Hm. Persze az alapértelmezett még mindig átállítható. De csak rendszerszinten találtam ilyet. :(((
    Egyébként én is használtam (tudatlanul) OpenJDK-val az Android SDK-t, és működött. Ám a vélemyéneyek szerint a működés nem 100%-os, lesznek benne hibák. (Hogy ilyet hogyan lehet szándékosan előidézni, nem tudom.)
    Abban nem vagyok biztos egyébként, hogy az Android SDK kiolvassa ezt a beállítást az Eclipse IDE-ből. (Elvileg más IDE-vel is működik.)
    :F Csak annyit szeretnék megtudni (de azt biztonsággal), hogy az Android SDK (és nem az Eclipse IDE) éppen melyik JDK segítségéval fordít. Ehhez semmi info-t nem találtam.
    Ezzel kapcsolatban valami ötlet? Info? Saját tapasztalat? Nekem még annyi van, hogy készítettem programot AIDE segítségével is. Android-ra (on-board) nincs Sun Java, tehát azt nem használhatja. De akkor vajon mit?

    Az AsyncLink-kel kapcsolatban annyit: még folytatódik (amint lesz időm)!

  • thon73

    tag

    válasz fatal` #355 üzenetére

    Nem úgy működik, hogy a java fordító a forráskódból byte-code-ot csinál, és a .class-ból készít az Android SDK .dex-et? Vagyis az elején kell lennie egy java fordítónak (a jdk-ból) és csak az eredményből lesz Dalvik VM-hez való kód. Ezért mégsem értem, hogy az AIDE a fordítás első felére mit használ fel? ((Mert egyébként teljesen kompatibilis az Android SDK/Eclipse IDE -vel))

    A kérdésem igazából windows alatt sem más, uis. - az írások szerint - az Oracle/Sun Java 7 sem megfelelő a fordításhoz. (Na jó, 99%-ban megfelel.) Ott (Win alatt) egyébként abban különbözik a helyzet, hogy a 7-es és 6-os verziókat nehezebb párban használni, legalábbis nehezebb beállítani/átlátni, hogy melyiket használja a rendszer. (Az Eclipse dokumentációja szerint a környezeti változókat nem használja.) Viszont a 6-os egyre inkább ki lesz téve biztonsági réseknek, tehát pl. bankolásra egyre kevésbé illik használni. (Még két hétig ez persze nem igaz :) )

    Bocsánat, hogy a kákán is csomót keresek; csak izgat a kérdés. Belefutottam ebbe az elméleti problémába, és sehol nem találok választ.
    Igaz, az is egy válasz, hogy használjam az OpenJDK-t vagy a SunJava 7-t, lesz-ami-lesz alapon. Ha hiba jelentkezik, elég majd akkor foglalkozni vele. Én azért örülnék, ha inkább az előbbit tudnánk tisztázni.

    Több infom nincs a fentiekről, nem jártatom tovább a számat, csak fülelek a válaszokra! Köszi!

  • thon73

    tag

    válasz fatal` #357 üzenetére

    OK. Személy szerint elfogadom. Sőt (utóbb derült ki) én is gond nélkül használtam OpenJDK-val. De a kisördög nem hagy nyugodni, így egy kis esti olvasnivaló kételyekkel:
    [link]
    [link]
    java7

  • thon73

    tag

    válasz WonderCSabo #363 üzenetére

    Köszi a válaszokat!
    Hm. Úgy látom, a helyzet nem más, mint az angol oldalak véleménye:

    Legtöbben különböző (OpenJDK JDK 6-7, Sun JDK 7) javaval fordítunk, és úgy TAPASZTALJUK, hogy ez gond nélkül működik (én is). De biztosra nem tudjuk. (Ja: OpenJDK JDK 7 == Oracle JDK 7. Legalábbis ezt írták.)

    Néhányan állítják (és indokolják), hogy csak a Sun JDK 6-t szabad használni. De a hibákról senki nem ír, csak annyit, hogy lehetnek!!

    Ezek alapján én is használom eztán, úgy ahogy eddig, vagyis ahogy a rendszer éppen áll. (Jelenleg egyik Sun 7, másik Open 6)

    Remélem, amikor a Sun 6 lejár, (néhány nap), a gugli megnyilatkozik is kijelenti a tutit! Addig is, ha valaki talál(na) hibát, vagy problémát a nem standard jdk mellett, legyen szíves szóljon, hogy mi is szemügyre vehessük! Egyébként volt már verzióváltás 1.5-ről 1.6-ra, reméljük 1.7-re is lesz!
    Mellesleg az Android SDK-ban hol lehet közvetlenül beállítani az 1.6-os szintet? (Amit az Eclipse menüben) Tudja valaki? Bár nem próbáltam, de az SDK Eclipse IDE nélkül is tud elvileg programot készíteni...

  • thon73

    tag

    válasz SektorFlop #365 üzenetére

    http://stackoverflow.com/questions/6941710/unable-to-open-log-device-dev-log-main-no-such-file-or-directory
    Ez szerintem pont azt célozza, amit kérdezel. Érdekes. nem gondoltam volna, hogy ezt ennyire ki lehet kapcsolni.
    Megírnád, melyik rom/kernel ez, és mit sikerült tenni?

    Bocs, két lépéssel lemaradtam. Akkor legalább annyit, amit a telefon névjegyénél kiír. Vagyis, ho. milyen rom ill. kernel. Köszi!

    [ Szerkesztve ]

  • thon73

    tag

    válasz SektorFlop #369 üzenetére

    Jogos. Hát ettől télleg nem lettünk okosabbak.
    Nézd meg sztem az init.d-ben lévő file-ban (ennek nem írták a nevét, de minden init.d-ben lévő file minden sora végrehajtásra kerül) lévő rm sort, van-e ilyen? (((Ez egyébként egy egyszerű linux utasítás, mely minden indításkor végrehajtásra kerül (ezért van az init.d-ben), és kiveszi a log alól a könyvtárat. Ennek hiányában az nem tud hová írni, tehát nincs log. - Bár én nem vagyok linuxos guru)))
    Nekem a /system/etc/init.d/-ben 6 db rövid file van, de egyikben sincs ez az rm... utasítás. Ezek viszont fontos rendszerfile-ok, óvatosan szabad belenyúlni! Lehet, hogy meghívnak más parancsfile-okat is (nálam igen), akkor érdemes azokat is lekövetni, hátha ott van furcsaság.
    A szervízkódot (második hozzászólás) csak finoman próbálnám ki, nem tudom minden kernel-ben/gyártónál működik-e. De egy próbát megér, utána úgyis kernel csere, ha ezek nem működnek (és kell a log).

    A név is megtévesztő. A 2.3.6 nem ICS verzió. Gondolom a kinézetet vették át. ICS-nek látszó GB. Van ilyen. Csak nem tudom ez melyik.

    [ Szerkesztve ]

  • thon73

    tag

    válasz SektorFlop #371 üzenetére

    Én ES explorert használok. Abban külön engedélyezni kell, ha látni akarom a root-ként a mappákat. Különben üresnek látszanak. Nem ez a hiba? Sztem. init.d-nek lennie kellene, az linux alapmappa, nem az android rendszer használja. Bár én nem ismerek minden disztribúciót/változatot.

  • thon73

    tag

    válasz Ablakos #383 üzenetére

    ...emellett mindkettőben érdemes egy pillantást vetni a Projet/Clean... és Project/Build Autamitcally pontokra. Nekem volt olyan (sztem. bug), hogy az erőforrások megváltoztatása után nem fordított újra automatically, és az R. file elemei még korábbi értékekre mutattak. A biztos, ha törlöd pl. a gen mappát, és utána újrafordíttatod (pl. clean). Ilyenkor ugyanis legyártja újból, és az biztos jó lesz.

    [ Szerkesztve ]

  • thon73

    tag

    válasz fatal` #391 üzenetére

    Csak megjegyzés: az ADT Bundle - a névjegye szerint - Eclipse 3.7.2-t, azaz Indigót használ. Úgy láttam. Egyébként ugyanaz, csak rondább a 'splash-screen', már amit eddigi rövid ismeretségünk alapján tapasztaltam. Előnyök: kisebb méret, könnyebb telepítés - egyik se jelentős előrelépés.

    [ Szerkesztve ]

  • thon73

    tag

    Kivételesen csak egy önálló Android emulátorra (vagy virtuális gépre) lenne szükségem. Tudtok arra valami megoldást, hogy ne a teljes fejlesztőrendszert kelljen letöltenem és telepítenem? Esetleg létezik más megoldás az Eclipse csigalassúsággal induló megoldásán kívül? Köszönöm!

  • thon73

    tag

    válasz CoolBoy323 #467 üzenetére

    Köszi hunfatal! Jó tipp! Csak nem elég neki a .net-em, most növelem.

    CoolBoy323-nak: én magamtól kezdtem tanulni, C-s (de nem C++-os) alapom volt. Mindent leírtam a lattilad.org/android oldalon, ott vannak magyar összefoglalókhoz linkek is. Ha kell, tudok még küldeni anyagot pdf-ben. Ha kell szívesen segítek is, ha elakadsz, még ha csak "hobbi-programozó" vagyok is.

    Én azt javaslom, hogy ne külön kezdd el a Java-t, érdemesebb rögtön Android környezettel kezdeni, mert abban is van rengeteg tanulnivaló. Ha nulláról indulsz, akkor úgyis mindegy. Egy androidos telefon az nagyon hasznos, sőt leginkább elengedhetetlen. Vagy tablet. Emulátoron fejleszteni elég unalmas.

  • thon73

    tag

    válasz fatal` #476 üzenetére

    Ops. Ezt nem nagyon értem. Most nem a tervezetten Bluestacks-os készüléknél vagyok, ezért nem tudtam még kipróbálni. De igazából a saját Android készülékemen (valós, nem virtuális) minden fordítás azonnal fut, ill. a debug is azonnal megy. Csak úgy érdeklődésképpen kérdem: van ahol/akinél kell várni?
    Amúgy - ha már egyszer elindult - a Google AVD sem túl lassú, persze én nem teljesítmény-éhes dolgokat készítek, hanem főleg szövegfeldolgozást...
    De ez a Bluestack igen ígéretesnek hangzik!

  • thon73

    tag

    válasz fatal` #479 üzenetére

    Ez jogos. Én az adataimat (alkamanként 5-6 mega) az external mem-ban tárolom, aminek elsődleges oka, hogy random elérésre van szükségem. (Az sqlite jó lenne, de az meg nem tölthető fel automatikusan.) Van ennek a megközelítésnek hátulütője is, pl. a hibakezelés, de csak egyszer kell megírni.
    A lényeg, hogy emiatt nem tűnt fel, a másolási idő. Én csak akkor vártam, amikor az adathalmazt elhelyeztem…

    CoolBoy: hova küldjem? Küldesz pü-t?

  • thon73

    tag

    válasz fatal` #481 üzenetére

    Erről lehet, hogy érdemes egy kicsit beszélgetni, mert nem találtam jó megoldást.
    Az assets meg a res az vili. Csakhogy azokban az adatokban nem lehet ugrálni, csak folyamatos beolvasást találtam.
    Ha menet közben készül az adat, arra jó az sqlite.
    De mi van akkor, ha van egy aránylag nagy (és kész) adatbázisom, amit bővítenem kell időnként?
    Most pl. pont egy szótár, százezer feletti szócikkel?
    Erre találtam legjobbnak az sd-n való tárolást, kétségtelen, ki lehet venni, meg egyéb problémák is felléphetnek, amire figyelni kell.
    De ha van egyéb megoldásra ötlet, annak nagyon örülnék! (Dupla tárolás, pl. asset-ből beolvasni, kizárva uis. legfontosabb, hogy azonnal reagáljon.)

  • thon73

    tag

    válasz fatal` #483 üzenetére

    Ami nekem hiányzik: Palm/Garnet OS alatt ez úgy működött, hogy a kész adatbázist (most sqlitenak felel meg) a program telepíthette fel, és rögtön kész adatok álltak rendelkezésre.

    Felmerült, hogy az adatok a res/assetsben legyenek, és induláskor áttölti sqlite-ba, de ez dupla hely.

    Az sd-vel a legnagyobb baj, hogy adatbázis-kezelő helyett használom, ill. nemigen tudom, hogyan fogja egy felhasználó oda másolgatni a szükséges adatokat. Hm. Ennek ellenére ezt találtam a legjobbnak.

    Más: nincs kedved a játékfejlesztésről, surfaceview-ről - egy egyszerűbb játék kapcsán tutorialt írni? CoolBoy-nak igaza van, magyarul szinte semmi nem érhető el, utána még mindig meg fog küzdeni az api-k megértésével. De talán, ha van kiindulópont, akkor könnyebb… Én biztos nem fogok mostanában játékot írni.

  • thon73

    tag

    válasz Yany #485 üzenetére

    Ez nem egy rossz ötlet. (én ugyan nem játékra gondoltam, de az adatok szempontjából ez édesmindegy)
    Az adatokra - saját szokásaim alapján: pl. külföldi használat - offline van szükségem, ezért nem is gondolkodtam hálózatban. De a telepítés után miért ne húzhatná le a szükséges adatokat a server-ről? Akkor úgyis rendelkezésre áll a hálózat, legnagyobb valószínűséggel azon telepítették. Igazad van! Köszi! Egyébként utólag belegondolva az pl. SVOX (magyar felolvasó) is így működik: program települ, aztán magának letöltögeti a hangfile-t az első indításnál.

    BlueStacks: sajnos proxy nem beállítható. Ettől függetlenül a saját programokkal télleg kiválóan szuperál! (Mondjuk a gépet Eclipssel együtt futtatva rendesen megfogja, pedig bőven van teljesítmény.)

  • thon73

    tag

    válasz fatal` #488 üzenetére

    Na, pont ezért kellene írni egyet :) de nem erőltetem, csak ötlet volt.
    Ezt viszont nem tudtam megoldani: tényleg lehet egy adatbázist az apk telepítésével együtt feltölteni? Tehát nem egy statikus adathalmazból áttölteni az sqlite-ba, hanem közvetlenül az adatbázist sqlite file formájában a program saját területére áthelyezni? Létezik erre megoldás? (Azno kívül, hogy a pl. raw-ban tárolt adatokat a program saját maga egyesével egy adatbázisba helyezi.)

  • thon73

    tag

    válasz fatal` #490 üzenetére

    Én is erre jutottam. Hát, ez egy kis visszalépés az előző generációhoz.
    De a netes betöltés egy jó ötlet!

  • thon73

    tag

    válasz mark.1337 #493 üzenetére

    "Ez az alkalmazás nem kompatibilis a(z) T-Mobile Samsung GT-I9100 eszközzel" mondja a guglijáték.
    Hát, az enyém nem T-Mobile, különösen, mivel nem eredeti rom van rajta. Mi az, hogy az eszközzel nem kompatibilis, nem az Android verzióval? Vagy a képernyő kicsi?
    Ettől függetlenül szívesen kipróbálnám, ha kapok vmi. instrukciót arra nézve, hogy miként tehető kompatibilissé a készülékem.

  • thon73

    tag

    válasz andyTM #498 üzenetére

    ??? Nem tudtam, hogy van ilyenem... De a rom-ot újra rakom, egy kicsit feljebb mászok az API létrán.

  • thon73

    tag

    Találkozott már valaki olyannal, hogy az Eclipse nem látja az ADT update-t? Viszont indításkor kéri. A help/install alól is elakad.
    ADT-bundle van fenn, Ubuntu 12.04LTS alatt. És itt (kivételesen) közvetlen - proxy és egyebek nélküli - net van. Köszönöm!
    ((B verzió: teljes bundle újratelepítése, de sajnálom rá az időt. Meg lesz még update később is…))

  • 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 pigster #532 üzenetére

    Bocs, lehet h. sokat dumálok.
    Az AsyncTask több metódust is tartalmaz, melyek az UI szálon futnak: onPreExecute - a hátterszál indítása előtt, onPostExecute - háttérszál befejezésekor, onCancelled - felhasználói megszakításkor (vigyázat a háttér még futhat!) és az onProgressUpdate a háttérszállal párhuzamosan fut.
    Ezek bármelyikében írhatunk az UI elemekbe, ami a háttérszálban tilos! Az onProgressUpdate (amiről a cikk szól), lehetővé teszi akár azt, hogy a háttérben lejátszott pl. zeneszámokat egymás után megjelenítsük. Végső soron ez is a folyamat előrehaladásának jelzése.
    Ez azért jó példa, mert azt mutatja be, hogy az egész folyamatot másképp kell szervezni (erre jutottunk mi is végül.)

    Az eredeti kérdés (hátha tud rá valaki jó választ): A teljes AsyncTask lefutása után (tehát amikor az onPostExecute is már meghívásra került), miként lehet újra felébreszteni az eredeti Activity-t, hogy további tevékenységeket végezzen.
    Erre én/mi nem találtunk egyszerű megoldást. Szerintem az egész Android filozófiával ellentmond az, hogy EGY activity TÖBB feladatot végezzen, de hátha lesz valakinek ötlete/tapasztalata ebben.

  • 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 :K !
    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?"

  • 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?

  • thon73

    tag

    válasz pigster #541 üzenetére

    Az infot én is úgy találtam egy példaprogramban, de lehet ListView egy sima Activityben is. A setListAdaptert a ListView-n belül kell kiadni.
    ListView listView = (ListView) findViewById(R.id.listView);
    // Assign adapter to ListView
    listView.setAdapter(dataAdapter);

    Arra figyelj, hogy az AsyncTask logikája szerint a konfigurációs változásokhoz az Activity alkalmazkodik, tehát a listView-t ott kell "létrehozni" (első sor), viszont a feltöltése történhet az AsyncTaskból is. Bár én inkább úgy oldanám meg, hogy az AsyncTask adja az adatokat az Adapter mögé, és az onPostExecute (vagy az onProgress...) csak az adatok megváltozását jelzi.
    ((A kötelező list elem csak a "gyári" adapterre vonatkozik, de azt át lehet és szabad (néha kell is) írni, és akkor olyan lista-elemeid lehetnek, amit csak akarsz.))

    [ Szerkesztve ]

  • thon73

    tag

    válasz pigster #544 üzenetére

    Bocsánat! Figyelmetlen voltam! Alapvetően az előző hozzászólásra akartam válaszolni. De teljesen igazad van, a ListActivity-ben ez kötelező; én már az expliciten megadott ListView-val voltam elfoglalva, ahol nem. Mégegyszer, bocs!
    Az viszont az én kérdésem lenne, mennyivel tud többet egy ListActivity, mint egy sima Activity-n belül elhelyezett ListView?

  • 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 ]

  • thon73

    tag

    Most kezdtem el ismerkedni az Android/SQLite párossal. Lenne egy elméleti kérdésem:
    Ha van egy gigantikus adatbázisom, lehetséges-e azt rendezetten tartani, és (a rendezettség miatt) valamilyen módon a keresést felgyorsítani? (felezés, indexelés, stb., maga az algoritmus nem érdekes, csak az hogy miként lehet beletenni a rendszerbe, vagy van-e ilyen benne eredetileg)
    Továbbmegyek: ha KÉT szempont szerint kell rendezni az adatbázist (legyen pl. gyógyszernév és hatóanyag páros), akkor tudok-e pl. két indexet létrehozni, és annak segítségével villámgyorsan keresni? Tehát pl. ne kelljen az adatbázist újrarendezni két keresés között, ill. ne kelljen minden egyes gyógyszernéven végigballagni, hogy egyezik-e vagy sem.
    Addig eljutottam, hogy az összehasonlítást meg lehet saját módszerrel oldani, de a rendezettségről nem találtam infot. (File-lal megoldottam, de sqlite-ban szeretném ugyanezt.)
    Lehet, h. nagyon triviális a kérdés, akkor bocsánat. Egy linkkel is megelégszem, ami a megf. dokumentációra mutat.

  • thon73

    tag

    válasz Mbazsika #564 üzenetére

    Húú. Köszi. Tényleg pofonegyszerű.

    ((Egy délutánon át keresgéltem, de mindenáron a rendezett adatbázisból akartam kiindulni (rövidzárlat v. mi). Pedig, csak az indexet kellett volna beírnom! Hát, viszek egy csokor szénát a lámáknak...))

    Ha jól értem, elég csak megcsináltatni az indexet, a "gyors" kereséssel nem is kell foglalkozni, kiválasztja maga?

  • thon73

    tag

    válasz Sianis #566 üzenetére

    Köszönöm! Mindkét link nagyon hasznos!

    Egy újabb apró kérdés, amin nem jutok át (google segítséggel sem). Ki tudja, hogy az adapterben átadott nyitott adatbázist és cursor-t hol kell bezárni? A doksi az onDestroy-t javasolja (és az logikus is, mint az onCreate párja), de a program az onPause után is meg tud lógni...
    Vagy hogyan tudom az onStart-ba tenni az adapter elkészítését? Az nem kell az onCreate után kész legyen? (ListActivity-ben) Előre is köszönöm!

  • thon73

    tag

    válasz thon73 #567 üzenetére

    Érdekes. Az egész adapter-kérdést az onResume-ba helyezve is működik. (bocsánat, az előbb elírtam onStart-ra, de az onPause párja az onResume)
    Tehát: adatbázis megnyitás, query, majd a simplecursoradapter az onResume-ban van,
    cursor zárás, adatbázis zárás az onPause-ban.
    ((Az más kérdés, hogy a gyakoribb lekérdezés lehet hosszú, de most csak néhány elemről van szó - inkább az elmélet megértésére.))
    A kérdés most fordítva merül fel bennem: van valami oka, amiért annyi más (hibaüzenetet adó) megoldás mellett ezt nem találtam a neten? Nekem elméletileg és gyakorlatilag is korrektnek tűnik (időtényezőt nem nézve); szól ez ellen a megoldás ellen valami, amit nem vettem észre?

  • thon73

    tag

    válasz SektorFlop #571 üzenetére

    Sianis-nak: Igen, ez fontos észrevétel, nem gondoltam rá. Így már akkor is visszaáll az elejére, ha csak pl. megnézek külön egy rekordot, hiszen más Activity kerül előtérbe. Hm.

    Ez a téma szerintem sokaknak okoz fejtörést. Honeycomb felett változott egyébként a megközelítés (és én még nem tartok ott), de sajnos, a konkrét probléma ettől még megmarad.
    A probléma veleje: az Activity az onCreate-onStart-onResume metódusokon kersztül indul, és rendre az onPause-onStop-onDestroy metódusokon áll le. Ezek persze párban állnak, tehát ha csak az onPause-ig jut a leállás (más kerül az előtérbe), akkor az onResume ponton éled fel a program.
    Ez azt jelenti, hogy az onCreate-ben megnyitott adatbázist az onDestroyban kellene bezárni. Ha előbb zárjuk be (pl. onPause), akkor visszatéréskor (onResume-tól kezdődik), nem lesz nyitott adatbázisunk (mivel a megnyitást végző onCreate nem kerül meghívásra!)
    DE! ÉS ITT JÖN A BAJ! Az Android rendszer - ha fogy a memória - CSAK AZ ONPAUSE VÉGREHAJTÁSÁT GARANTÁLJA! Simán kihagyja az onDestroy-ban lévő zárást.
    Az adapternek viszont végig szüksége van a nyitott adatbázisra, ill. a hozzá tartozó cursorra. Ezért jutottam oda, hogy a listát az onResume-ban kell lekérdezni és megalkotni, aztán az onPause-ban bezárni. Sianis-nak azonban igaza van, ezzel minden apró-cseprő dolog miatt újraépül a lista.

    Kérdések:
    - lehet, hogy nem kell törődni az onPause utáni kényszerleállással? A vélemények szerint kell, saját tapasztalatom nincs (túl nagy a memóriám :) )
    - javítja-e a helyzetet, ha onPause-ban pl. a lista helyzetét is tároljuk?
    - van-e valakinek precízebb ötlete?
    - javasolják a singleton-t (Application-ból származtatva), ami járható út; így ugyanis a teljes Application (és nem Activity!) futás alatt nyitva marad az adatbázis (és a cursor). De honnét tudom, hogy véget ért a történet, és be kell zárni az adatbázist?

    Néha nem látom át, hogy milyen logika alapján képzelték el ezt az egészet. Igaz, én csak amatőrben játszom...

  • thon73

    tag

    válasz SektorFlop #573 üzenetére

    Kellene. Elvileg. A LogCat tele lesz hibával, ha nem zárod, de a program működik. Alattomos.
    A lista jó, ilyen szempontból, csak zabálja a memóriát. Mindent kétszer tárolsz, másolsz, stb. Én csak próbálgatom az SQLITE-t, de a végleges megoldásban több, mint kétszázezer rekordot kellene kezelnem. igaz rövidek, az egész nincs 10 mega.

  • thon73

    tag

    válasz fatal` #575 üzenetére

    Pontosan. Ha onPause-ban bezárom, akkor nem lesz.
    DE:
    onPause után a rendszer bármikor bezárhatja a programot, és akkor az onStop ill. onDestroy nem kerül meghívásra. Ha a zárás az onDestroy-ban van, akkor soha nem kerül meghívásra és bezárásra.

    Ez a helyzet sokkal gyakoribb, mint gondolnánk. Most próbáltam tesztelni: ha home-mal lépek ki a programból, és utána egy csomó minden mást elindítok (ez azért gyakori), akkor az eredeti program figyelmeztetés nélkül bezár ((egyébként a gyakorlatban ez az onStop után következik be, elméletileg már az onPause után is bekövetkezhetne))

    Azt nem tudom, zavarja-e az adatbázist és a cursor-t, ha nyitva marad. Szerintem nem, mert adapterről van szó, tehát csak olvasásról.
    Zavarja-e a rendszert, ha nyitva marad az adatbázis? Mem-leak?
    Vagy ne foglalkozzak az egésszel, mint ahogy a legtöbb példaprogram teszi.

    Egy ideje olvasgatok erről, de sehol nem találtam korrekt módszert a zárásra. Kivéve az onPause-onResume párosát, de annak meg más baja van. (vagyis túl gyakran kerül meghívásra.) Szerintem az egyik legnagyobb hiba az Android tervezésében, hogy az onPause után megengedett a rendszernek az erőltetett kilépés. Mi a nyavajáért nem fejezheti be ilyenkor a dolgát a program!?
    ((A listView esetén sajnos teljes activity-ben kell gondolkodni: amíg a listview látszik, addig az adapter aktív, tehát kell a nyitott cursor és adatbázis is.))

  • thon73

    tag

    válasz thon73 #577 üzenetére

    Még egy apróság: a problémám abból fakad, hogy a dokumentáció kihangsúlyozza, az onPause után az Activity-t a rendszer kilőheti.
    Ezzel szemben többen állítják (és elvileg ez így kell legyen, hiszen az activity csak egy objektum, hogy lehet eltüntetni egy objektumot?), hogy a rendszer Activity-t nem, csak process-t tud kilőni. Márpedig a teljes application egy processben van benne.
    De akkor hogyan lehetséges, hogy az egyszerű példaprogramom újra el tud jutni az onCreate-be, onDestroy nélkül. Kilőtte a rendszer a process-t az egész alkalmazás alól?
    Kételyek között vagyok - nem értem az egészet.És a source-ban is elég nehéz egy ilyen komplex eseményt lenyomozni...

  • thon73

    tag

    válasz thon73 #578 üzenetére

    ...feladtam a harcot az Android életciklusainak megértésére. Sztem. a fejlesztők is, API11 felett teljesen más módszereket alkalmaznak.

    Segítséget szeretnék kérni: egy príma Wayteq xtab700dc-t szeretnék rábírni az Eclipse-szel való együttműködésre most WinXP, (egyébként linux alatt, ami esetünkben könnyebbnek tűnik).
    Android 4.1.1 alatt kell windows driver? Ha igen, tudja-e valaki, hogy ezekhez a remek kínai termékekhez hol lehet szerezni/mit lehet használni?
    Van egy "Internal Memory" (pontosabban csak az van...) feliratú fa-struktúrám. (nem rootolt gép). Ez vajon hova lehet be-mountolva? Vagyis hogyan érhetem el programból? (Rögtön a '\' alatt lehet?) Ha esetleg valaki rootolt gépet használ, megnézné?
    Előre is hálásan köszönöm!
    ((Bocsánat, hogy nem tényleges programozást kérdezek, de oda szeretnék eljutni ezzel a géppel is. Másutt nem hiszem, hogy segítséget találok erre a problémára...))

  • thon73

    tag

    Elkezdtem haladni a korral, megismerkedtem a Fragment-kezeléssel.
    DE!
    Az normális, hogy az Android Developers honlapon lévő példakódok hibásak?? :(((
    Namármost, ahogy végiggondoltam, úgy viszont működik (és a hibás elgondolást is megtaláltam a példakódban).
    Van viszont erről (Fragment) valahol használható leírás, hogy mi a helyes felhasználás módja, vagy mindenki kitalálja magának oszt lesz ami lesz??
    Vagy mi van ilyenkor, amikor a "HIVATALOS" dokumentáció hülyeséggel példálózik?

  • thon73

    tag

    válasz thon73 #631 üzenetére

    A mérgelődésen kívül két konkrét kérdésem lenne Fragment-ekkel kapcsolatban:

    1. A Fragment által létrehozott Options-Menu a Fragment eltávolítása után is megmarad. Ha új Fragment példányt csatolok be, akkor az előző (eltávolított) példány Options-menu-je is, és az új is látszik. Ezt (a régi menüt) mivel tudom kitörölni a Fragment eltávolításakor? (Az előző Fragment már "eltűnt", vagy legalábbis tag keresésével nem találja meg. De a menu maradt.)
    Az invalidateOptionsMenu nem működik, vagy nem tudom, hol kellene kiadni. A menu.clear() (pl. a prepare részben) viszont mindent kitöröl, és egyáltalán nem látszik a menü.

    2. Ha elmentettem egy transaction-t a backstack-re, és nem arrafelé megyek vissza (mert pl. elfordítottam a telo-t), akkor hogyan tudom azt onnan eltüntetni? ((A BackStack-on lévő elemek száma minden elfordításkor növekszik, hiába lesz közben "Destroy". Ez nem is lenne baj, csak a visszafordításkor az alap Fragment-ről szeretnék indulni, miközben a "második" Fragment (vagyis a tranzakció) el van mentve a BackStack-re.))

    API17-tel fordítottam, de API8 minimumra, tehát support package-t használtam. Elvileg ez nem lehetne baj. Előre is köszönöm, ha valakinek van ezzel tapasztalata.

  • thon73

    tag

    válasz Sianis #633 üzenetére

    Igen, a menü létrehozása tökéletesen megy. A menüt a fragmenten belül hoztam létre, és szeretném is, ha ott maradhatna. A gond akkor kezdődik, ha egy fragment osztály több példánnyal kapcsolódik be, mert akkor minden példány hozzáadja a saját menüjét. Ez idáig logikus is, de ha remove v. replece-szel elveszem a fragment-példányt (és persze a back-stack-ben sincs), a menüje akkor is megmarad. És - noha nincs már hivatkozás elvileg sehol erre a példányra - a menü az activity újraindítása után is megmarad! Minden indításnál új fragment-példányt adtam egy FrameLayout-ba (az előzőt elvileg eldobtam) és több száz bejegyzésem lett a menüben!
    Tudom, vissza lehet szerezni a Fragmentet, a gond csak az, hogy ha egyszer valahova becsatoltam, ugyanazt a példányt (külön időpontban sem!) nem lehet másik Layout-ba becsatolni. Ezért kellene két példány egy fragmentből (külön elrendezésben tehát külön időben) de EGY menüvel egyszerre.
    Egyetlen ötletem van: az activity onprepareoptionsmenu-jében ellenőrizni, hogy adott taggal van-e élő fragment, és eszerint betenni a menüt. De ha lehet, a fragmenten BELÜL szeretném a menükérdést megoldani. Csak nem megy…

    A BackStack kérdés egyszerűbb: az nekem is prímán működik. De ha nincs szükségem az utolsó elmentett transaction példányra, azt hogy tudom "visszajátszás" nélkül eldobni? Vagyis csak levenni a stackról, de nem végrehajtani.

    Köszönöm!

  • thon73

    tag

    válasz shinodas #636 üzenetére

    Pl. így? Az ID-t is kiírja.

    private final int MAX_POINTER=10;
    private float[] posx=new float[MAX_POINTER];
    private float[] posy=new float[MAX_POINTER];
    private int[] id=new int[MAX_POINTER];
    private int pointerCount = 0;

    @Override
    public boolean onTouchEvent(MotionEvent event)
    {
    switch (event.getActionMasked())
    {
    case MotionEvent.ACTION_DOWN:
    case MotionEvent.ACTION_MOVE:

    pointerCount = event.getPointerCount();
    for (int cnt = 0; cnt < pointerCount && cnt <MAX_POINTER; cnt++)
    {
    posx[cnt] = event.getX(cnt);
    posy[cnt] = event.getY(cnt);
    id[cnt] = event.getPointerId(cnt);
    }
    this.invalidate();

    break;
    }
    return true;
    }

    @Override
    protected void onDraw(Canvas canvas)
    {
    for (int cnt = 0; cnt < pointerCount; cnt++)
    {
    canvas.drawText(Integer.toString(cnt) + ", [" + Integer.toString(id[cnt]) + "]", posx[cnt], posy[cnt]-80f, text);
    canvas.drawCircle (posx[cnt], posy[cnt], 30f, paint);
    }
    }
    }
    }

    Nem vagyok benne biztos, hogy a getAction() action_POINTER_up kódot is visszaad. Ahhoz sztem. getActionMasked() lekérdezés kellene. De lehet, h. rosszul tudom. A fenti megoldás viszont akár tíz ujjal is működik. (Már ha a hardver tudja...)

    [ Szerkesztve ]

  • thon73

    tag

    válasz thon73 #635 üzenetére

    Az első kérdésemet egyszerűsítem: ha egy Fragment NINCS a BackStack-ben ÉS fragmentTransaction.remove-val (utána commit-tal) levettem a képről - akkor hogyan lehet eltüntetni végleg? Az onCreateOptionsMenu pl. megtalálja.

    A második kérdésem továbbra is fennáll.

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