Hirdetés
Új hozzászólás Aktív témák
-
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.
-
Karma
félisten
Volt egy szakasz, amikor a BugSense SDK-ja nyílt forráskódú volt, akkor húztam be a forrását, és alakítottam át úgy, hogy az ő rendszerük helyett saját Azure-os backendre küldje a cuccot (eszközadatok, stacktrace főleg), ott meg tárolom és emaileket küldözgetek.
Az androidos oldal lényege egyébként annyi, hogy az Application onCreate-ben meg kell hívni a Thread.setDefaultUncaughtExceptionHandler metódust, ezzel lehet mindent elkapni.
-
Karma
félisten
Jahogyja. Nem jött át a szándék, hogy integrálni akarnád ezt a cuccot a projektedbe, és ott van ez a telepítési mizéria
Egyébként meg próbáld meg kézzel berakni a metaadatot.
Vagy ez a tool maga generálná ki az API kulcsot? Mert akkor nehezen tudom elképzelni, ki generálná le helyettükNem használtam még, TestFlightot illetve saját hibanaplózó cuccot szoktam csak.
-
Karma
félisten
válasz
XperiaP
#1688
üzenetére
Ennek így nem sok értelme van.
A Java mindig kiegészített UCS-2-vel dolgozik, így ha valamit megjelenítesz, az is Unicode lesz praktikusan. Az adott Unicode szöveg UTF-8 kódolt alakja annyira nem izgalmas/hasznos.Nem UTF-8 szöveget akarsz inkább dekódolni és megjeleníteni?
Mert erre több lehetőséged is van: ha byte tömbbe olvastad a fájlt, akkor a new String(byte[], Charset) konstruktort használhatod. Ha meg Streamed van (jobban megéri, mint a teljes anyagot betölteni és alakítani, pazarolva a memóriát és a GC időt), akkor egy InputStreamReader kell, aminek szintén van Charsetes konstruktora. -
Karma
félisten
-
Karma
félisten
válasz
rgeorge
#1679
üzenetére
Láttam már lábbalhajtós megoldást: a SOAP envelope egy string resource, amibe kód rakja bele a generált XML törzset, kifelé meg sima parsolás, minden metódushoz kézzel megírva... Na ez igen fájdalmas, rugalmatlan és értelmetlen is.
Látni láttam hogy van ksoap2-android, ami talán szofisztikáltabb, de sose használtam. Meg mondjuk nem segít, ha egy AXIS 1.4-es WS-hez kell kapcsolódni, amit semmilyen mai lib nem támogat...
Ha a megrendelő rugalmas, mindenképp menj a rendes REST API irányába!
-
Karma
félisten
válasz
RexpecT
#1673
üzenetére
Az IntentService-szel annyi a baj, hogy terv szerint addig él, amíg a kliensek kérésein dolgozik, aztán leáll magától. Ha az kell, hogy az alkalmazás többi részétől függetlenül tekerjen, a Service-ből kellene kiindulnod.
Egyébként ha akkor is követni akarod a felhasználót, amikor nem a te activityjeid vannak elöl, akkor semmi baj nincs a main szálon futtatással. Ha igen, és a pozíciófrissítés utáni számolgatás, DB, stb. miatt lagot okoznál, akkor is átrakhatod csak ezt a feldolgozást háttérszálra egy AsyncTaskkal.
-
Karma
félisten
válasz
RexpecT
#1671
üzenetére
Ehhez a feladathoz szerintem egyikre sincs szükséged. A Looperek kezelését hagyd meg a rendszernek, Handler meg inkább a UI szálon aszinkron hívásokhoz praktikus.
A helymeghatározásnál ha a PendingIntentes megoldást használod, mondjuk egy Service-ből*, akkor már jó leszel szerintem.
* A Service is a main szálon fut alaphelyzetben, de ez kisebb probléma, mint hogy a szálkezelést nem az általad említett ponton kéne elvágni.
-
-
Karma
félisten
-
#1627
Karma
félisten
WonderCSabo
#1626
Karma
félisten
válasz
WonderCSabo
#1626
üzenetére
Jól. Bár némely widgetet JNI-n keresztül is elérhetővé faragtak, valamelyik oldalon láttam...
-
Karma
félisten
Huh, már a gondolattól megpördült kétszer a gyomrom...
Ha az a fajta mazochista vagy, akinek nem baj, hogy rengeteg energiát beleöl egy koncepcionálisan halott dologba úgy, hogy eredményt nem vesz ki belőle soha az életben (ld. hobbigolfozó), akkor nézz szét a Lazarus wikijén. A Google a két kulcsszóra együtt elég sok aloldalt dobott fel, amik csak néhol mondanak ellent egymásnak
Sokkal de sokkal jobban járnál, ha előszednél egy Java könyvet és azt forgatnád. Főleg, hogy ez a torzszülött felélesztéséhez is kell Java és JNI is.
-
Karma
félisten
válasz
ted_mosby
#1599
üzenetére
Simán. A developer.android.com-on végigmész a Develop -> Trainingen, aztán amikor megértetted az Activity és a BroadcastReceiverek szerepét, nézz utána célirányosan az AlarmManager (időzített futtatáshoz), AudioManager (némítás/visszaállítás) osztályoknak, meg a BOOT_COMPLETED eseménynek.
Vagy leveszel a polcról egy kész appot, mint a Tasker vagy a Llama, és nem írod újra a kereket.
-
Karma
félisten
válasz
macsaba97
#1591
üzenetére
Nézd meg ezt a linket. A "Use hardware buttons..." szakasztól kezdve érdekes, lépésről lépésre leírja, mi kell a médiagombok kezeléséhez. Azt nem követeli meg viszont, hogy ténylegesen zenét játsz
Ha korábban emlegettem a RemoteControlClientet, akkor bocs, ennél egyszerűbb a helyzet. És egyébként 2.2-től működik is a linkelt út.
-
Karma
félisten
-
Karma
félisten
válasz
E.Andras
#1586
üzenetére
Melyik részébe gabalyodtál bele?
Pár dolog kell csak szerintem a dologhoz:
1) Háttérben, az email appot megkerülő emailküldés. Ezt a JavaMail API-val egyszerű. Csak kell hozzá egy SMTP szerver, de arra használhatod a saját GMailed vagy pl. a SendGridet.
2) Rá kell venned a rendszert, hogy figyelje az aktuális helyzetet. Ehhez most nem tudok linket adni, de biztos az Android doksiban is van róla bőven szó.
3) Van egy egyszerű UI-od egy szövegdobozzal és gombbal, ahol annyi a plusz dolgod hogy mindig visszaadod az EditTextnek a fókuszt, hogy a billentyűzet előjöjjön (ha nem csal az emlékezetem).
4) Android szempontból meg egy Activityt írsz, ami gombnyomásra indít egy AsyncTaskot a GPS kérés + email történethez. -
Karma
félisten
válasz
macsaba97
#1581
üzenetére
A történet igazából ott kezdődhet, hogy ezt a zenelejátszó témát kivered a fejedből. Ne onnan indulj ki.
Neked egy olyan képnézegető program kell – a példa kedvéért nevezzük Shotgunnak –, ami ezt a pár dolgot tudja:
- képeket tud megjeleníteni és lapozni a képernyőn
- feliratkozik a media button eseményekre, hogy a BT távirányítótól ő kapja a jelzéseket.
- le tudja zárni (hardcore) vagy fekete háttérrel eltakarni a kijelzőt (easy mode).Ennél felesleges jobban túlbonyolítani fejben.
-
Karma
félisten
Pufferméretről vitáztunk korábban a topikban, de különösebb konszenzusra azt hiszem nem jutottunk. A Java a 8192-es varázsszámot szokta használni, mint ahogy egyes libraryk is.
Elméletben lehetne spekulálni a NAND page méretekkel meg a fájlrendszer, a kernel sajátosságaival, de ha ki akarsz csavarni mindent azt hiszem kísérletezned kéne.
Egy ilyen szótár-keretrendszer mérésekre is elég jónak tűnik
10000 szó kikeresése, stb.Tisztelem a PalmOS-es megoldást, a régi idők rendszerei mindig megkövetelték hogy az ember alaposan kimérje minden lépését. Ahhoz képest a modern platformok nagyon engedékenyek minden fronton
A blogot mindenképp el fogom olvasni; vannak kérdéseim de lehet hogy nagy újdonság nem lenne bennük.
Amúgy annyit már most leszűrtem, hogy van ebből egy régebbi C változat, gondoltál arra, hogy NDK-val közvetlenül felhasználod?
-
Karma
félisten
Ezeket az indexelős történeteket szerintem még desktopon előre el kéne készítened, aztán az adatbázisoddal együtt rakni be az appba. Teljesen nonszensz ugyanis a 45 perces inicializálás, főleg ha teljesen redundáns és amúgy is tiszta Java kóddal csinálod.
De az indexek újraolvasása is olyan, hogy szerintem jobban elférne app indításkor egyszer, mint minden config change-nél megismételni.
Engem azért csak érdekelne, hogy mi az a háromféle összehasonlítási mód. Az ékezettörlés világos, de mi lenne a másik előfeldolgozás? Azt se lehet SQL szinten megoldani?
Mert amúgy például a H2-t is lehet Androidon használni, ha az ember feláldoz 1 MB-ot az app méretéből, és nem nyitogatja olyan gyakran. Cserébe annak nincs lekorlátozva a Unicode támogatása pl.
-
#1549
Karma
félisten
WonderCSabo
#1548
Karma
félisten
válasz
WonderCSabo
#1548
üzenetére
Nekem az IntelliJ közömbös – kísérletezek vele néha-néha desktophoz –, viszont az új build rendszer nagyon elkéne. Mondjuk nem bánnám, ha az ADT is támogatná
-
Karma
félisten
Hát tényleg nem így használjuk, de ennek az Eclipse-hez semmi köze.
Az ARM-os emulátor teljesen halott ügy, felesleges erőltetni, mert még egy erőművön is használhatatlanul lassú. Van viszont Intel System Image, amit ha kombinálsz az Intel HAXM-mel (paravirtualizációs driver), akkor nagyon gyorsan futó emulátort kapsz – cserébe nem használhatsz semmilyen Google szolgáltatást (Play Services, Billing, stb.) vagy API-t, mert azt nem tartalmazza.
De ha van tableted (jól értem?), akkor kapcsold be a fejlesztői lehetőségek alatt az USB hibakeresést, és használd azt! Badarság nem a valódi eszközt használni. Bekapcsolás után a DDMS perspektívánál meg kell jelennie az eszközlistában a tabletnek, és a következő Run/Debug hívásnál is fel fogja kínálni.
Ha még nem tetted volna meg (és Windowson dolgoznál), az SDK-ban található "Google USB Driver" csomagot fel kell raknod az SDK Managerrel, majd megadni az SDK\extras\google\... helyet, hogy ott keressen drivert a rendszer.
És ha a driver felrakása után se jelenne meg a DDMS-ben, akkor megpróbálhatod az USB kapcsolódási módot (státuszsáv) MTP-ről PTP-re állítani. Nekem több Nexusszal is volt ezzel gond.
-
Karma
félisten
Van pár megoldási lehetőség.
Az egyik ami eszembe jutott, hogy csinálsz egy egyedi View osztályt, ahol az onDrawban használod a Canvas forgatás és drawBitmap (src, destes overload) metódusait.
A másik meg, hogy veszel egy ImageViewt, kódból állítod be hogy mit rajzoljon ki - a részlet kivágásához a Bitmap.createBitmapet használod pl. -, majd az egész IV-t forgatod el.
Az előbbi szerintem hatékonyabb memória és sebesség tekintetében is.
-
Karma
félisten
Elvileg igen, gyakorlatban meg ki kell próbálni
Nekem itthon nincs kéznél androidos eszköz.És igen, menteni csak ID-vel lehet, vagy ha megírod kézzel az onSaveInstanceState/onActivityCreated metódusokban.
Ez szerintem egyáltalán nem egy egyszerű kérdés – több szintű állapot, aszinkronitás, kötött interfészek... Igazi Android programozási gyakorlat. Nagyon "jól" megoldható spagettivel is, ha az ember nem gondolkozik rajta, de akkor már miért ne bontaná szét? Mások véleményére azért kíváncsi lennék.
-
Karma
félisten
A FileSelectActivity különválasztása semmiképpen sem volt rossz lépés.
Csinálhatsz olyan Activityt is, amihez nem tartozik UI, ha ezt a témát adod meg neki a manifestben. Ezt indítsa el a Main, az eredményt resultként tudja visszaadni, és egyébként majd akkor finisheli le magát, amikor vagy kimégsézett a felhasználó, vagy mindent kiválasztott.
Szóval valami ilyesmi lehetne a vége:
MainActivity -1-> ImportActivity (translucent) -2-> FileSelectActivity
| ^ | ^ | ^ |
| | | | | \-----3----/
| \----6-----/ | |
| | \-------- 4-> ConfirmationDialogFragment
| | |
| \--------------5-----------------/
|
\--------1*---> ExportActivity (translucent) -2*-> FileSelectActivity... -
Karma
félisten
Az előbb hülyeséget írtam, az onActivityResultot nem tudod külön osztályba kiszervezni, hiszen az mindenképpen ott hívódik meg, akin a startActivityForResult metódust hívod...
Miközben írtam azért derengett, hogy ez az "egy folyamatot összefogó osztály" igazából lehetne egy külön Activity, amit a Main elindít. Talán ez lenne a legközelebb az Androidhoz is.
-
Karma
félisten
Hát, ha csak annyiról lenne szó, mint amit az eredeti hozzászólásban felvázoltál, akkor nem lenne egy annyira bonyolult helyzet. Én ebből indultam ki.
A MainActivitynek abban csak három állapota van: üresjárat, file selectorra vár, dialógusra vár. Az állapotok között lehet egyet előre meg hátra lépni, illetve dialógusnál üresjáratban ugrani. A callbackek miatt még csak tárolnod se kell az aktuális állapotot, hiszen teljesen implicit a rendszer szempontjából (lásd: melyik Activity/Dialog van elől). Az állapotátmenetek meg simán leírhatóak a callbackekben, és még csak nem is spagetti, mivel a két bekérés két külön helyre fut be.
Viszont onnantól, hogy mint mondtad, négy beszélgetős "szál" is van, ezeket ki kéne szervezni külön osztályba. Például csinálhatnál egy olyat, ami kapna egy Contextet, implementálná a résztvevő interfészeket, és csak az adott szálat írná le. A végén meg visszajelez, hogy siker (és átadja az URL-t is), vagy hogy cancelezett mindent a felhasználó, és a MainActivity csak ezzel foglalkozna.
-
Karma
félisten
1) Igen, újra meg kell hívnod. Célszerű ezt egy metódusba tenned a MainActivityn belül. Az elhagyott könyvtárat meg úgy tudod kezelni, hogy a FileSelectorActivityt indító Intentbe beraksz egy extra mezőt, vagy a data tagját is használhatod (ott URL-t tudsz tárolni). Ezt lekezeled onCreate-ben és szevasz. (Ha támogatsz képernyőelforgatást, akkor egy kicsit bonyolultabb, mert az aktuális állást ki kell mentened.)
2) Ha a fájl elérési útját tudod, mindent tudsz: létre tudsz hozni egy új File objektumot az elérési úttal (van ilyen konstruktor), és onnantól minden megy.
-
#1503
Karma
félisten
WonderCSabo
#1502
Karma
félisten
válasz
WonderCSabo
#1502
üzenetére
Ha csak egy képet kéne így megjeleníteni, a TouchImageView nálunk bevált.
Bonyolultabb tartalommal nem foglalkoztam még, de SO-n van sokféle válasz, hátha van benne valami használható: [1][2]
-
Karma
félisten
Alapvetően dialógustípusonként készíts egy osztályt, ne konkrét példányonként, és ezek mind külön fájlba menjenek, hiszen semmi közük egymáshoz. Készítsd fel az osztályt úgy, hogy a szövegek, a gombok feliratai kívülről meg argumentsből is állítható legyen, így mindig be tudod paraméterezni a használat helyén.
Vagy mielőtt feltalálod újra a kereket, nézz rá az AlertDialog osztályra és ha elég, használd azt!
-
Karma
félisten
válasz
RexpecT
#1427
üzenetére
ViewPagerben van ez? Mert ha igen, akkor az lehet a kiváltó ok, hogy a VP mindig előre létrehozza a következő N elemet, hogy simább legyen az átjárás.
Egy próbát megérhet, hogy a setOffscreenPageLimitnek nullát adsz meg, elvileg annak le kéne tiltania ezt a viselkedést, cserébe lassabb lesz.
-
Karma
félisten
válasz
kisguly
#1421
üzenetére
Ettől még nem programozási kérdés
, van nagy tabletes topik és valószínűleg navonos is külön. Persze nem biztos.
Mindenesetre valószínűsítem, hogy valami ilyesmit kéne végigjárnod.A tableten lévő fájl meg ne az eszközön akard megnyitni, inkább másold le és úgy nézz bele desktopon. A név alapján gyanús, hogy nyers pixeladatot tartalmaz tömörítés nélkül -– ha a fájl mérete 2 457 600 byte, vagy ennek fele, szinte biztos.
-
Karma
félisten
válasz
-PLevi-
#1385
üzenetére
Ez inkább az Android alkalmazások topikhoz tartozik, de azért megválaszolom a kérdést ahogy sejtem a helyzetet. Ha megvan az APK, akkor annak visszafejtésével (pl. Virtuous Ten Studio segítségével) és a manifest átírásával elvileg a telepítési korlátot át tudod hágni. Aztán futtatáskor, amint az első magasabb szintű API-t, témát, akármit megpróbál használni, game over.
-
Karma
félisten
válasz
rgeorge
#1369
üzenetére
Nem lenne bonyolult, de nem rendeltetésszerű használat. Az alkalmazásoknak odáig szabadna foglalkozni az üggyel, hogy internal vagy external storage – az API is ezt tükrözi. Ha szembemész a rendszerrel, az mindig ilyen taknyolást hoz.
Amúgy mit csinálnál olyan telefonon, ami nem bővíthető SD-vel?
-
-
Karma
félisten
BROTIP: A bundle-t nem kell telepíteni, csak kitömöríteni.
dmc: Ilyen JNI hibák platformütközéskor szoktak előfordulni leginkább. A biztonság kedvéért vegyük át: 32-bites JDK mellé 32-bites ADT kell, 64-es JDK-hoz meg 64-es ADT. Keverve nem megy.
Egyébként nem szokott általában ez ilyen bonyolult lenni, csak valahol elsiklott valami... Pl. húsz perce raktam az egyik gépemre én is ADT-t, elsőre ment. Az SVN-t több szopás belőni
-
Karma
félisten
Menj be a környezeti változók közé, és vegyél fel két értéket:
1) JAVA_HOME, ami a feltelepített JDK mappájára mutat
2) PATH, ami a JDK-n belüli bin mappára. (Ha már van PATH definiálva, akkor pontosvesszővel elválasztva csapd a végére a JDK bint.)Ezt pl. a Rapid Environment Editorral sitty-sutty meg tudod tenni.
-
Karma
félisten
válasz
half333
#1320
üzenetére
Jé, most hogy kiderült hogy milyen telefonról van szó, egész gyorsan meg lehet találni Google-lel a megoldást. Még csak kernelt se kell forgatni hozzá, csak root jogok kellenek. De ez már tényleg az Active topikba tartozik.
-
Karma
félisten
válasz
half333
#1317
üzenetére
Egyrészt még mindig nem mondtad, milyen telefonról van szó; másrészt bár tényleg lehet az Androiddal kapcsolatos közös dolgot ott állítani, azért gyártófüggő is a fájl tartalma; harmadrészt a kérdésedhez a build.propnak vajmi kevés köze van, inkább a a LED-ek előtét ellenállását kéne kiforrasztani és kisebbre cserélni...
-
#1305
Karma
félisten
lordjancso
#1304
Karma
félisten
válasz
lordjancso
#1304
üzenetére
A ListView addHeaderView metódusa nem jó erre? Az adapter beállítása előtt hívd meg.
-
Karma
félisten
válasz
RexpecT
#1297
üzenetére
Az okozza a félreértést, hogy tettél egy alaptalan feltételezést, ami egyébként elég súlyos is lehet különösen rendszererőforrásokkal kapcsolatban: "az osztály amely implementálja ugye nem adja át a saját interfész referenciáját".
Hogyne tenné? Konkrétan a LocationManagernek kell átadni az interfész referenciát az utolsó paraméterben. Ha megnézed a metódus forrását, az is látszik, ahogy egy HashMapben eltárolja a listenerre mutató hard referenciát. Gyakorlatilag ugyanaz, mint az A-B-C-s példakódod. És ez veszélyes, mert ha nem szünteted meg a regisztrációt, akár Activityk is maradhatnak beragadva a memóriában.
Java alatt "semmi se történik ok nélkül", nincsenek a levegőben röpködő és villámszerűen az objektumaid póznájába becsapódó események (mint lehetne pl. egy JVM szintű publish-subscribe rendszer). Valahol biztosan regisztrálnod kell magad egy konkrét objektumnál.
-
#1299
Karma
félisten
kemkriszt98
#1298
Karma
félisten
válasz
kemkriszt98
#1298
üzenetére
Float és double típusoknál a nullával való osztás Infinityt ad vissza; ellentétben az egész számokkal ahol kivételt dob.
-
Karma
félisten
válasz
bucsupeti
#1292
üzenetére
Regisztrálj Azure fiókot, igényelj ingyenes SendGrid szolgáltatást, és használd a JSON interfészüket az email küldésre. GitHubon van is egy lib hozzá (sendgrid-java). Így teljesen elkerülöd az Androidot és nyomot se hagysz.
Szerk.:
Bocs, nem olvastam végig, hogy nem akarsz külső rendszert bevonni.
Márpedig az email nem így működik, úgyhogy szerintem valamelyik kritériumodból engedni kell. -
#1274
Karma
félisten
SektorFlop
#1272
Karma
félisten
válasz
SektorFlop
#1272
üzenetére
Példám most nincs, de a lehető legegyszerűbb megoldás az, ha van egy vízszintes LinearLayoutod, a két gyereke szélességét 0dp-re állítod, és a layout_weightet 1-re. Ez a szülő LinearLayout pedig match_parent széles.
Dave-11: A MediaPlayerezést inkább felejtsd el, használd helyette a SoundPoolt. Miután betöltötted a hangokat, a play metódus visszaad egy ID-t, amivel leállíthatod a már játszottat az új indításakor.
-
#1271
Karma
félisten
SektorFlop
#1270
Karma
félisten
válasz
SektorFlop
#1270
üzenetére
Igen. Mind a kettővel meg lehet csinálni.
Mi a kérdés? -
#1257
Karma
félisten
kemkriszt98
#1256
Karma
félisten
válasz
kemkriszt98
#1256
üzenetére
Mi lenne, ha a layout XML-t és ezt a Java forrásfájlt megosztanád velünk pl. PasteBinen, és akkor nem kéne vakon találgatni?
-
#1253
Karma
félisten
kemkriszt98
#1249
Karma
félisten
válasz
kemkriszt98
#1249
üzenetére
A nullpointerexception alatti stacktrace minden soránál van egy fájlnév és egy sorszám. Ha kettőt kattintasz rá, még oda is visz az Eclipse. Nézd meg, melyik a felülről legelső sor, ami a te kódod, és javítsd ki.
Pl. egy gyanús lehetőség: a layout XML-ben nem, vagy rosszul állítottad be a TextView-k ID-jét, ami miatt a findViewById null értéket ad vissza.
-
#1239
Karma
félisten
lordjancso
#1238
Karma
félisten
válasz
lordjancso
#1238
üzenetére
Hm. Megpróbálhatnád azt, hogy felüldefiniálod a setBounds metódust az UrlDrawable-ben úgy, hogy a tagváltozóba rakott képre is meghívja azt, ugyanazokkal a paraméterekkel.
Mondjuk célszerű azt az esetet is kezelni, ha még null a kép, és majd a jövőben jön létre. Az előző bekezdésben leírt módosításon túl az onPostExecute-ban fel kell cserélned az urlDrawable.drawable = result sort a setBoundsszal, így az új méret mindkét objektumra hat.
-
#1237
Karma
félisten
lordjancso
#1236
Karma
félisten
válasz
lordjancso
#1236
üzenetére
Az onPostExecute-ban van egy setBounds hívás, azt kell módosítanod úgy, hogy azt csinálja amit szeretnél.
-
#1234
Karma
félisten
lordjancso
#1233
Karma
félisten
válasz
lordjancso
#1233
üzenetére
Bevallom sose használtam az ImageGetter megoldást, ha HTML-t kellett megjeleníteni, mindig a WebView-t preferáltam. Kicsit keresgélve úgy tűnik, hogy az invalidate hívás tényleg nem rendezi újra a tartalmat.
Workaroundot láttam: a WeakReference<View> helyett WeakReference<TextView>, és az invalidate helyett kell egy c.setText(c.getText()) hívás.
-
#1230
Karma
félisten
lordjancso
#1221
Karma
félisten
válasz
lordjancso
#1221
üzenetére
Semmi nagy dologra nem gondoltam, két dolgot változtatnék a példán a rend kedvéért:
1) Ahogy nézem, nem használja fel az URLImageGetter a konstruktorban átadott Contextet, úgyhogy a tagváltozót és a paramétert törölném azonnal. Ha meg mégis kéne, akkor a View-tól kérném el.
2) A container tagváltozója ugyanennek az osztálynak erősen kapaszkodik (hard reference) a View-ba, úgyhogy ha mondjuk a letöltés tíz percig tart, a felhasználó már régen továbbállt mert megunta, akkor se tudja a GC felszabadítani az egész Activityt.
Könnyen elkerülhető, ha a container tagváltozó nem View, hanem WeakReference<View> típusú. Két sort kell módosítani hozzá, és máris nem akadályozza a GC-t – csak le kell ellenőrizni onPostExecute-ban, hogy megvan-e még a View, vagy már vége.public class URLImageParser implements ImageGetter {
WeakReference<View> container;
public URLImageParser(View t) {
this.container = new WeakReference<View>(t);
}
public class ImageGetterAsyncTask extends AsyncTask<String, Void, Drawable> {
URLDrawable urlDrawable;
...
@Override
protected void onPostExecute(Drawable result) {
View c = URLImageParser.this.container.get();
if (c == null) return;
...
// redraw the image by invalidating the container
c.invalidate();
}
...
}
}[ Módosította: doc ]
-
#1220
Karma
félisten
lordjancso
#1219
Karma
félisten
válasz
lordjancso
#1219
üzenetére
Javaslom ezt a StackOverflow kérdést és az elfogadott válaszát megtekintésre. Mivel a TextView adott, csak az ImageGetter interfészt tudnád használni, arra meg ez egy járható megoldásnak tűnik.
Bár én biztosan WeakReference-et raknék el a View-hoz.
-
#1205
Karma
félisten
lordjancso
#1204
Karma
félisten
válasz
lordjancso
#1204
üzenetére
Azt vágod, hogy az onCreate-ben egy lokális változót hoztál létre, miközben az osztályod tagváltozója soha nem kap (az indító nullon kívül) értéket? Vedd ki az "ArticleAdapter" típusnevet az értékadás előtt.
-
Karma
félisten
Pont ellenkezőleg, köszönöm a hosszú okfejtést. Segít jobban kontextusba helyezni a dolgokat
Az utolsó ponton méláztam még egy kicsit, végülis az a leginkább kézzel fogható; nem kell konvertert írnod, ha az OutputStreamWritert felparaméterezed egy encoderrel: Charset.forName("UTF-8").newEncoder()
-
Karma
félisten
Három főbenjáró bűn lebeg a levegőben ennél a történetnél:
1) Fel akarod találni újra a kereket. Rengeteg különböző, de jure vagy de facto szabványos alternatív kódolás van arra, hogy az ilyen karaktereket könnyen olvasható formára hozd, nem kell újon törnöd magad(*). Pl. pofonegyszerű használni az URLEncoder osztályt, vagy a Commons Lang StringEscapeUtils osztályát.
2) Hacsak nem mérési eredményeid vannak arról, hogy a vázolt megközelítésed lassan működik és ez az egykarakteres Stringek miatt van, ne állj neki túlkomplikálni. A premature optimization esete állhat fenn.
3) A Unicode olyan, mint a medve: nem játék. Persze, magyar karakterekkel el tudsz lavírozni akár egy kézi look up table-lel amikor az UTF-8 "konverteredet" írod, de a helyes megoldás bőven meghaladja a "fél délután alatt a garázsban összedobom" szintet. Gondolok pl. a surrogate-ek kezelésére, ami UTF-16-ban két karakter, UTF-8-ban meg pl. három...
(*): Kivéve persze, ha valaki más követte el ezt a hibát egy szerveroldalon, és ahhoz kell idomulnod. Ez esetben tekintsd az első pontot tárgytalannak.
Szóval röviden: ha nincs valami életbevágóan fontos és pontos oka ennek, keress valami más megoldást.
-
#1165
Karma
félisten
SektorFlop
#1164
Karma
félisten
válasz
SektorFlop
#1164
üzenetére
Szerintem azzal nem nagyon tudsz mit csinálni, hiszen a listaelemeket le kell gyártani...
StackOverflow-n mondjuk láttam egy olyat, hogy ha a listának a layout XML-ben adsz egy cacheColorHint attribútomot, akkor sokkal többet GC-zik.Tehát ha esetleg állítottál ilyet be, vedd ki.
-
#1162
Karma
félisten
SektorFlop
#1161
Karma
félisten
válasz
SektorFlop
#1161
üzenetére
Ha esetleg nem így lenne, csináld meg úgy az adapteredet, hogy újrahasznosítsa a View-kat, ne pedig minden egyes lépésnél újat hozzon létre. A getView metódus convertView paraméterében beeső Viewt tudod erre használni.
-
#1148
Karma
félisten
trisztan94
#1147
Karma
félisten
válasz
trisztan94
#1147
üzenetére
Egy ilyen hangfelismerést megcsinálni nem nagy varázslat, csak pár elem kell hozzá: folyamatos hangfelvételt kell csinálni, a beeső hangadaton FFT-t számolni, és figyelni, hogy mikor lesz egyszerre minden frekvencián erős a jel. A taps ugyanis úgy néz ki körülbelül.
Ezek mindegyikére van kész kód StackOverflow-n.
-
#1145
Karma
félisten
trisztan94
#1143
Karma
félisten
válasz
trisztan94
#1143
üzenetére
Keystore, nem keystroke. Privát-publikus kulcsokat tároló fájl.
Kiadáskor az APK-t alá kell írni egy RSA kulccsal, ami a fejlesztőt azonosítja. A Play Store-ba feltöltéskor fontos ez, mert ha egy verzió kikerül, onnantól minden frissítést ugyanezzel a kulccsal kell feltenni, vagy hibát dob.
Egyszer kell ilyet generálnod Play Store fiókonként praktikusan, kitöltve a kulcs adatait pontosan.
Az Alias a kulcs neve lesz ebben a keystore-ban, bármi lehet, de praktikus ha egyszerű és könnyen felidézhető. A validity a kulcs érvényessége, ha lejárna, nem telepíthető az APK. Mivel apponként nem változtatható a kulcs, jó távoli időt kell megadni (25 év+). De lehet erre a Play is figyelmeztet.
A kiterjesztés nem számít amúgy. Az AVA hiba sajnos nem tudom mi lehet.
-
#1079
Karma
félisten
PandaMonium
#1078
Karma
félisten
válasz
PandaMonium
#1078
üzenetére
Azért ez a "semmit se tanul" kijelentés igen erős, tekintve hogy a Unity milyen népszerű és erős. Programozni azzal is kell
.Ha pénz van a dologban, és be van tervezve a licencköltség, akkor mindenképp a Unity. Ilyen esetben saját engine-t írni öngyilkosság; de legalábbis nagyon sötét megrendelőre utal ha belemegy.
Hobbiismerkedésnél persze más a helyzet.
-
Karma
félisten
válasz
negyedes
#1064
üzenetére
Hát, ennyi kód ismeretében csak általánosan megy...
Amikor az adaptert létrehoztad, egy listát adtál neki data gyanánt. Ezt a listát tedd el tagváltozóba, és használd a remove metódusainak egyikét a törlendő elemmel vagy annak indexével.
Mivel ilyen naivan sikerült az adaptert megcsinálni, először meg kell keresned egy ciklussal a helyes indexet...
Erősen javaslom, hogy nézd meg a SimpleCursorAdaptert a kézzel varázslás helyett. Csak több munkát keversz magadnak...
-
-
Karma
félisten
válasz
negyedes
#1043
üzenetére
Ó. Megnéztem a doksit, persze hogy nem jó ez se, hiszen a parent az a ListView.
Amit te inbox_listnek neveztél, az a megnyomott elem... Onnan próbáld meg a findViewById-t.De igazából sokkal jobb lenne, ha az egészet kidobnád a francba, s a parent.getItemAtPosition(position) hívással megszereznéd az adatobjektumodat, és onnan vennéd ki a három mezőt. Tudod, MVC meg ilyenek...
-
Karma
félisten
válasz
negyedes
#1041
üzenetére
Módosítsd a findViewById hívásokat, most valószínűleg az activity-d metódusát hívod. Ha tippelnem kéne, belső nem-static osztályt írtál az adapternek.
TextView send = (TextView) parent.findViewById(R.id.sender);
TextView date = (TextView) parent.findViewById(R.id.date);
TextView subject = (TextView) parent.findViewById(R.id.subject); -
Karma
félisten
válasz
negyedes
#1036
üzenetére
A DB-ben az oszlopodat gondolom Sendernek hívják, a KEY_SENDER csak a tagváltozó/konstans a Java segédosztályodon. Ha tényleg kézzel akarod összerakni a select hívást (amit nem értek miért tennél), a valódi oszlopneveket kell használnod.
Azaz pl.
String selectQuery = "SELECT " + DBConstants.KEY_SENDER + ", " + DBConstants.KEY_RECEIVER + ", " ...;
Cursor cursor = mDb.rawQuery(selectQuery, null); -
Karma
félisten
válasz
negyedes
#1004
üzenetére
Amikor rakod össze a WHERE feltételt, az egyenlőségjel jobb oldalát aposztrófok közé kell tenni. Ez okozza az egészet.
Pl. az idézett querynél: KEY_SENDER + "=" + sender helyett KEY_SENDER + "= '" + sender + "'".
Vagy az egyébként jóval bonyolultabb SQLiteProgram osztályokkal meg tudod oldani, amit hunfatal mond.
-
#977
Karma
félisten
trisztan94
#976
Karma
félisten
válasz
trisztan94
#976
üzenetére
Hogy őszinte legyek, nem egészen értem se a kérdésed, se hogy mit akarsz elérni. A RelativeLayoutnak (mint ahogy bármely más ViewGroup típusnak) megvan a maga helye; és közös bennük, hogy View osztályokat tudnak valamilyen elv szerint rendezni.
Ha most a libGDX-szel saját rajzolásod van, ahhoz semmi köze a VG-knek.
Azt csak nagyon remélni tudom, hogy nem View-k tologatásával készítesz játékot - az se nem gyors se nem jó.Szóval egy kis részletet nem bánnék. Vagy egy vázlatot.
-
#968
Karma
félisten
WonderCSabo
#967
Karma
félisten
válasz
WonderCSabo
#967
üzenetére
Olyan nincs, hogy nem csinál semmit*, maximum tenni kell hogy látszódjon. Debuggerrel a kérdéses résznél akkor is azonnal világítana az exception, ha azt lenyeleti egy üres try-catch-csel (ami gondolom pont így van).
*: egy ilyen komplexitású kód legalábbis
-
Karma
félisten
Ugye nem UI szálon akarod ezt a kódot használni, pl. egy gomb eseménykezelőjében, vagy onCreate-ben?
4.0-tól kezdve ez hibát dob, szigorúan kötelező háttérszálat használni a hálózathoz! Ez lehet AsyncTask, Executor, de akár egy sima Thread is.
Csak legyen külön. Mellesleg ha az exceptiont idemásoltad volna, még csak tippelgetni se kéne.
-
#948
Karma
félisten
trisztan94
#945
Karma
félisten
válasz
trisztan94
#945
üzenetére
A DDMS perspektíván látod az eszközt? Logcatat ír?
Ha nem, a kerneled látja az ADB imterfészt? Bedugás után érdemes lehet megnézni a dmesg kimenetét, hogy mit lát és mihez kezd vele.Linux alatt csak a szopás van az ilyesmivel... Nem írt semmit/mindent megcsináltál, amit a Google oldala írt? Régen volt, hogy az udev konfigurációjába bele kellett piszkolni pl.
-
#941
Karma
félisten
trisztan94
#940
Karma
félisten
válasz
trisztan94
#940
üzenetére
Nem is kötelező parancssorból fordítanod
-
#939
Karma
félisten
trisztan94
#936
Karma
félisten
válasz
trisztan94
#936
üzenetére
Jobbkattolj az alkalmazásprojekteden a Package Explorerben, és ott válaszd a Run as...-t és az Android Applicationt. Akkor megcsinálja a launch configot automatikusan.
Ha nem akarná, akkor File menü Export, és ott tudsz APK-t létrehozni kézzel.
A parancssoros eszközökhöz tényleg a PATH-t kéne beállítani jól, az SDK-d tools, platform-tools mappáinak mindenképp benne kell lennie.
Amit te inbox_listnek neveztél, az a megnyomott elem... Új hozzászólás Aktív témák
- Xbox tulajok OFF topicja
- Projektor topic
- Óra topik
- Kalandor: „Ha engedtem volna a lelkiismeretemnek, az üzlet kevésbé lett volna jövedelmező”
- Vezetékes FEJhallgatók
- AMD Navi Radeon™ RX 9xxx sorozat
- Minden a BlackBerry telefonokról és rendszerről
- Milyen egeret válasszak?
- Kormányok / autós szimulátorok topikja
- Apple iPhone 17 Pro Max – fennsík
- További aktív témák...
- Lenovo L440 laptop - i5-4200M - 4 gb DDR3 ram - 320 gb HDD
- 5 db Konica Minolta bizhub A3 Színes MFP Nyomtató Csomag 1db C258 / 2db C224 / 2db C220
- Zsír DELL XPS 13 Plus 9320 Ultrabook laptop, -70% 13,4" i7-1260P 12Mag 16/512 FHD+ /Millió! Ft/
- AMD Ryzen 5 8500G 6-Core 3.5GHz AM5 Box - PCX garancia 2028.10.06.
- FELÚJÍTOTT (Refubished) Lenovo Thinkpad T14s G2 Üzleti Golyóálló Laptop -50% Ryzen 5 PRO 16/256 FHD
- GYÖNYÖRŰ iPhone 13 Mini 128GB Pink -1 ÉV GARANCIA -Kártyafüggetlen, MS3822
- GYÖNYÖRŰ iPhone 14 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3972
- ÁRGARANCIA!Épített KomPhone i9 14900KF 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Apple iPhone 14 128GB,Kartyafuggetlen,Újszerű,Dobozaval,12 hónap garanciával
- Samsung Galaxy A05s 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopszaki Kft.
Város: Budapest