Új hozzászólás Aktív témák
-
-
Sianis
addikt
Amúgy én inkább color resource-ba tenném, tehát XML-be. Utána pedig getColor(). Resource objektumot pedig alkalmazás context-ből is lehet szerezni.
Illetve te is jobban jársz, ha XML-be defniálod a színt, mert az IDE pl simán odarakja mellé egy négyzetbe, hogy milyen szín, valamint rendesen van nevesítve.
-
vlevi
nagyúr
Nem veszíted el.
Pusztán arról van szó, hogy az egész számként tárolt színek között lesznek negatív számok is, de attól még az az információ ott van.
Az, hogy az int előjeles, nem számít.
Az előjeles számok annyiban különböznek az előjel nélküliektől, hogy a bináris számábrázolásban a legfelső bitet előjelként értelmezik, és nem számként. Egy előjel nélkül 1 byteon tárolt érték emiatt lehet 0-255, de ha előjelesként értelmezed, akkor -128 és 127 közti érték lehet.
Ahogy a class leírása is írja, a fekete szín pl. -16777216 (0xff000000).
Tulajdonképpen az összes szín egy negatív szám lesz, (majdnem mind), mert a 4 byteból az első az áttetszőséget jelenti, ahol 0 a teljesen áttetsző, és 0xff a teljesen lefedett. Ebből az is egyenesen következik, hogy ha az áttetszőség értéke 128-at meghaladná, akkor az egy negatív szám (azért, mert akkor az 1 byteon tárolt érték legfelső bitje 1-es lesz). De azon az 1 biten tárolt információ akkor sem vész el.. -
thon73
tag
Sőt, továbbmegyek. Valószínűleg inkább egy Loader-re lenne szükségem, ami a Service inicializálását elvégzi. Találtam egy ilyet Can you use a LoaderManager from a Service?
Van ezzel valakinek tapasztalata? Akár az AsyncTask, akár a Loader nagy segítség lenne... Jelenleg van egy 4-5 mp-es előkészítési idő, amit a rendszer már nem enged meg. ((De csak egyetlen egyszer, amikor a service-t először elindítom.)) Köszönöm! -
LordX
veterán
Az az érték "duplázás" az ARGB4444-re _nagyon_ meredekül hangzik. Felfelé konverziónál mindig 0 bitekkel kell kitölteni / megfelelő 2 hatvánnyal szorozni / x bittel balra shiftelni. (Azaz ARGB4444 -> ARGB8888 esetében az alsó 4 bitek mind nulla.)
Ugyanezért a +5 és +2 is eléggé gyanús, miért kéne úgy működnie. A visszaosztásnál meg persze, hogy visszakapod az eredeti értéket, mert gondolom egész osztás van..
-
thon73
tag
Úgy tűnik, mindig túlságosan elvarázsolt problémákkal találkozom...
Hátha mégis valaki beleütközik ugyanebbe, megválaszolom magamnak.
Megdöbbentő módon az Android valójában csak kétféle módon tudja a bitmap színeket kezelni: ARGB_8888 és RGB_565 kódolással. (Létezik, de nem javasolt az ARGB_4444. Létezik, de nem működik a getPixel() metódussal az ALPHA_8)
(((Nekem még nem okozott problémát, de a megjelenítés ált. RGB_565-tel történik, vagyis valahol az ARGB_8888 mindig átalakításra kerül.)))Egy "térképet" szerettem volna megrajzolni (ezért nem jó egy tömb) 512 különböző színnel. A szinek nem lényegesek, az viszont igen, hogy pont azt a színt "vegyem ki", amit a képbe belerajzoltam. A korlátozott hely miatt arra gondoltam, hogy valamelyik helytakarékosabb kódolást fogom választani.
Ez viszont egyáltalán nem egyszerű, mert a getPixel által visszaadott alapszínek(R,G,B) mindig 256 árnyalat terjedelműek lesznek - nem pedig a kódolással azonosak. Továbbra sem találtam metódust a "raw" színérték megszerzésére.ARGB_8888 alatt persze minden tökéletesen működik, hiszen itt minden alapszín 256 árnyalattal kódolt. Ehhez azonban dupla hely kell...
ARGB_4444 alatt az alapszinek 4 bit terjedelműek, vagyis 16 árnyalatuk van. Ha azonos színt akarunk visszaszerezni, akkor a szinek 4 bites értékét dupláznunk kell: 2->22 8->88 c->cc (hexában). Az ilyen, hexában azonos számjegyekkel bíró színeket megadva (pont 16 van) ugyanazt a színértéket kapjuk a getPixellel, mint amivel rajzoltunk.
Persze, semmi nem elég, nekem az RGB_565 kódolású rajzból kellett azonos színeket kiszednem. A source kód a dithering miatt elég elvarázsolt, nehéz kideríteni, hogy pontosan hogyan kódol, ill. sokkal összetettebben kódol, mint amire ehhez a feladathoz szükség van. Matematikailag a következő összefüggést találtam:
5 bites szinek - R és B, 32 árnyalat: setPixel( árnyalat * 8 + 5 ) beállítás után a getPixel() / 8 visszaadja az eredeti árnyalatot.
6 bites szín - G, 64 árnyalat: setPixel( árnyalat * 4 + 2 ) beállítás után a getPixel() / 4 szintén az eredeti árnyalatot adja vissza. ((Megjegyzem, az első 32 árnyalatra az előző összefüggés is működik))Bocs, ha valakit untattam ezzel, de nekem hosszas fejtörést okozott, hogy megtaláljam azokat a színeket, amiket beállítva ugyanazt az értéket kapom vissza. Megjegyzem, hogy több különböző alapszín árnyalatot ezek a kódolások nem is tudnak tárolni, az összes többi "bemeneti" szín ezen árnyalatok valamelyikére redukálódik.
Még annyit tennék hozzá, hogy amennyi info-t találtam, az Android ebben is elég egyedi. Vannak 565-888 színkódolás átalakítások, de mintha az android egyiket sem követné, hanem valami saját algoritmusa lenne.
-
-
Karma
félisten
Ez a jó megoldás
Azzal a Canvasszal csak onDrawban rajzolhatsz, különben nem lesz hatása. Nem szabad referenciát eltenned arra a példányra.
Viszont nincs akadálya annak, hogy saját Canvast hozz létre egy saját Bitmap köré, mint például ez az átméretezetted, amire akkor rajzolsz amikor akarsz.
Itt van egy kis infomorzsa.
-
thon73
tag
Azt hiszem megoldottam, bár lehet, h. nem ez a legoptimálisabb. A grafikában nem vagyok otthon. (A nem ide tartozó részek hiányoznak a kódból.)
private Bitmap skin;
private Bitmap skinscaled;
private void init()
{
skin = BitmapFactory.decodeResource(getResources(),
R.drawable.portrait);
}
protected void onSizeChanged (int w, int h, int oldw, int oldh)
{
skinscaled = Bitmap.createScaledBitmap( skin, w, h, false);
}
protected void onDraw(Canvas canvas)
{
canvas.drawBitmap( skinscaled, 0f, 0f, null);
}Egy további kérdés még felmerült bennem: az onDraw-ban megkapott canvas-szal csak az onDraw-ban rajzolhatok (invalidate után mindent újra), vagy máshol is rajzolhatok rá, olyat, amit nem kell letörölni a következő rajz előtt? (Az ujj húzásának az útját mutatja; felemelésig)
-
thon73
tag
Bocsánat, még egy kérdés az optimalizálásról.
Van egy - mondjuk 1200x800 pixeles képem, amit az onDraw helyez bele a Viewbe így:
canvas.drawBitmap(skin, null, dst, null);
(Rect dst értékét az onSizeChanged-ben szedem össze, gyakorlatilag a View mérete, a bitmap dekódolása, közelítő átméretezése meg a konstruktorokban van.)Kérdés:
Mivel rajzolok a bitmap felszínén (egy pont követi az ujjamat), ez a drawBitmap() minden alkalommal lefut. És minden alkalommal ismételten átméretezi a bitmap-et. (Hol 798, hol 356 stb a View mérete, pl. ahogy forgatom a készüléket.)Ezt kell-e v. lehet-e optimalizálni? Az inSampleSize segítségével már megközelítőleg ekkora képet csináltam, de nem pontosan ekkorát. Vagy ez nem akkora terhelés? Végül is elég gyorsan fut...
-
Karma
félisten
Semmiképp se mátrixszal! Úgy kiszaladsz a memóriából, mint a huzat!
Helyette a BitmapFactory.Options.inSampleSize lesz a barátod, ezzel csak minden n-edik pixelt dolgozza fel az Android a képből, nagyságrendekkel csökkentve a memóriaigényt.
Ezt elmulasztani a halálfejes hibák egyike.
-
vz12
tag
Az előbb megszámoltam, 48 nagybetű + 47 kisbetű = 95 db ékezetes betű van a Map-omban, és nekem az indexem a unicode-os karakter, '\uxxxx' formában, mert amúgy az Eclipse beszólt, hogy a .java fájlomban "illegális" karakter található.
Nekem kb. 2 éves installációm van, és bevált dolgokon nem változtatok ...
Persze ha valami gond lenne, akkor nyilván rákényszerülnék, de egyrészt tesztelem a szimulátor(ok)on túl 2-3 kütyün, 2-es és 4-es androidon is, másrészt szerintem nagyon extra dolgokat nem használok, harmadrészt van már pár száz letöltésem a Play-en szerte a nagyvilágból mindenféle eszközre, de senki és semmi nem jelzett semmiféle problémát még. -
eastsider
nagyúr
fúha. a második válaszodat még elemzem (annyira nem jött át)
egyelőre számolni nem szeretnék vele (igen lehetne számolni az ISO-Aperture-shutterSpeed párosból. h egyik változtatásakor mi lesz a többi..
viszont ha stringként letárolom nem tudom mennyire számít igénytelennek
egyébként attól függ hány fényértékenként van a beosztást....egyébként a number pickert mennyire illik stringgel feltölteni?
-
eastsider
nagyúr
szerintem is így tiszta, ezzel még nem volt gondom
esetleg a backstack szempontjából nem feltétlenül mindegy, hogy dialog vagy sima fragment. (meg az átláthatóság miatt)más kérdés:
ilyen értékeket hogy tárolnátok db-ben?
[link]
CRUD szempontjából érdekel, nem tudom hogy tudnám megjeleníteni ilyen módon... -
eastsider
nagyúr
-
thon73
tag
No, úgy tűnik, sikeresen beletenyereltem valamibe, ami messze meghaladja a tudományom. Ami megnyugtat: nem csak az enyémet. Tanulás céljából ajánlom a következő cikket: [link]; szerencse h. az említett professzor volt olyan kedves, és a pórnépnak is csinált biztonságos osztályokat...
Kibogoztam az ArrayAdapter source-kódját is. A konstruktorban megadhatjuk a felhasználni kívánt ArrayList-et, melyet = jellel tárol a belső változóban.
Ezt követően a Filter() rész pont azt csinálja, amit én: lock-olja a belső változó hozzáférését, és végigolvassa a tömböt (pontosabban átmásolja egy másikba). Ez azonban NEM szinkronizált cselekedet, uis. időközben egy másik programrész (akár UI szálon,mert a Filter worker-szálon van!) módosíthatja az eredeti tömböt. Vagy összeomlik, vagy exception-t kapunk. A saját változatomban (belassítottam a filtert) sikerült is a hibát produkálni.
Ált. persze nem lesz hiba, egyszerűen azért, mert a Filter (ha egyáltalán használjuk), sokkal gyorsabban lefut, semmint változna közben a tömb. De ha a Filter lassul - akkor máris előjöhet a hiba, még a legegyszerűbb listában is. Az én problémám nyilván szélsőséges (túl nagy a lista), és valójában a filtert nem is akartam használni (pont a lassúsága miatt), de a logikai hiba az akkor is logikai hiba.
Elvi megoldást úgy találtam a magam számára, hogy készítek egy ArrayList leszármazottat, amit a Loader fel tud tölteni, távolról változtatható - de csak akkor, ha a Filter nem állítja le a működését. Pl. úgy, hogy a filter teljesen más metódussal vesz ki elemeket; ha a tömb változik, akkor ez a lehetőség lezárul, úgyis megváltozott a szűrni kívánt anyag.
Gondoltam, megosztom a gondolataimat, hátha mást is érdekel ez a kérdés. De, mint fent írtam, ez kicsit több, mint amit biztonságosan átlátok, így aztán ha hülyeséget gondolk, kérlek, javítsatok!
-
thon73
tag
Egy kis olvasás után jobban meg tudom fogalmazni a kérdésem:
A BaseAdapter legnagyobb része UI szálon fut, tehát használhat a program többi részével közösen egy olyan ArrayList-et, amit a többi rész is csak UI szálon módosít.
A BaseAdapter egyúttal Filterable is lett, vagyis tartalmaz egy Filter.performFiltering metódust, ami viszont egy Worker thread-en dolgozik, ÉS olvassa a fenti ArrayList adatokat.
Én úgy látom, hogy csak a Filter.performFiltering területén kell védenem ezt a közös ArrayList-et a módosítástól.
Mi lenne erre a leghatékonyabb módszer? ((Vehetünk két helyzetet is: kis méretű és extra nagy méretű listák, ahol a filtering is sokáig tarthat))
Vagy valamit teljesen rosszul értek?Természetesen az osztálynevek a felmenőket jelentik, mindegyikből van saját.
-
eastsider
nagyúr
egyelőre simán betöltötte a loader az imageviewekbe
szóval ez tuti fogyaszt...
illetve jelenleg palceholdernek a drawable-ből az app ikonja van benn, ami még fogyaszthat...
ahogy Karma írja UIL ezt mindet intézi, vagyis a seggünk alá rakja
egyébként úgy néztem, hogy háttérfolyamatban evett 200mb-ot az app, de akkor tuti a képek miatt.. mindjárt tolok egy tesztet kikommentezve azt a részt (úgyis törölni kell)
most néztem genymotionben 10mb körül volt a fogyasztása, lehet hogy csak a custom ROM miatt van ez?
jah... fals riasztás volt... genymotionbe akármit csinálok 11mb-ot eszik (4.4.2, N5) (végigmentem az összes listán)VAAGY... telefonomon a futtatási környezet ART-on van..
-
Karma
félisten
Vagy bele se fog, hanem rábízza magát és a képkezelést az UIL-ra, miközben egy jó konfigurációt ír hozzá a GitHub oldal alapján.
eastsider: Azt, hogy a képek okozzák-e a memóriabajt, könnyen ki tudod próbálni a favágó módszerrel. Azaz kommentezd ki azt a sort, ami az ImageViewt tartalommal tölti meg, és úgy mérj még egyet.
-
eastsider
nagyúr
SQLite Debuggerrel mit keressek?
a táblák rendben vannak, csak szöveg van bennükalkalmazás mérete 1.93Mb, Adatok 68Kb.
tuti a kép betöltése a listViewba kavart be
mekkora egy ilyen alkalmazás normális étvágya?
lehet az is gond lehet, hogy (teszt miatt), túl sokszor indítom a loadert -
eastsider
nagyúr
köszi
lehet lesz még kérdésem pofátlanul
közbe kilegoztam, hogy muszáj lesz custom adapter...
godnolom valami példához hasonló:
[link]és a loadernek a saját adapteremet adom át ugye? (a simpleCursorAdapter helyett)
és megint jön az, hogy az adapter konstruktora deprecated...
ez mennyire gázos dolog amúgy?Karma: igen, az imagepath-t tárolom SQLiteban (szerintem ez nem gázos megoldás....
hát igen, úgy megeszi a N4 hw-ét így egy full fellbontású kép betöltése a listába...egyébként az mitől lehet, hogy a content providert implementáló alkalmazásom memóriaigénye nem kicsi?
14-30mb között poroszkált, de ha megnyitok egy olyan listát, ahol több képet is megjelenít a lista (persze nem UIL-el), 170 megát evett
-
#2045
WonderCSabo
félisten
thon73
#2044
-
-
eastsider
nagyúr
lehet nem jól fogalmaztam. telórol írtam..
szóval Te azt mondod, hogy először úgy csináljam meg, hogy egy listFragment, amin csak a képek tábla jelenik meg. szóvel úgymond "független" a másiktól (nem az adatbázisra gondolok).
és itt cisnálok egy dialogot, amin kiválasztom, melyik tekercshez tartozzon a felvivendő kép?
és így már listázni simán tudnám a JOIN-nal. így értetted nem?
a függelten tekercs táblát nem értem, azt hogy érted?azt kellene megoldani, hogy rákatt a tekercsre, átdob a hozzá tartozó képeket tartozó listára.
ekkor, mivel nincs kép, de megvan a tekercs ID-je, létre tudom hozni a képeket, mert megvan az ID, nem jól gondolom? mármint a film ID-je megvan, innentől nincs sok gond, vagy rosszul értem?az összes kép kilistázását későbbre hagynám
nem hiszem, hogy felesleges lenne, ha valaki rákeres erre a topikban, legalább fog valamit találni
-
-
eastsider
nagyúr
nem egészen így lesz a programom
inkább úgy, hogy van egy író, aminek több könyve van, de egy könyvet csak egy ír
szóval rámegyek, hogy Gárdonyi Géza, és kijön az egri csillagok, meg az összes könyve Gárdonyinak, szóval pont fordítva írtad, ahogy én elképzeltemazt tervesztem,
A eset:
hogy alapból az lenne, hogy alapból van ugye két tab, egyiken az összes író, ha átlapozok a másikra az behúzza az összes íróhoz tartozó összes könyvet, ugyanis lehet valaki csak a könyvek között szeretne böngészni, mert pl nem tudjam ki írta, csak a címét.. (nem túl életszerű példa, de a programomnál nagyon is)B eset:
rákattintok egy íróra és behúzza a az ahhoz az íróhoz tartozó könyveket (amiket ő írt). vagyis a JOINolt mezőket.utánanéztem kicsit, és lehet futásidőben cserélgetni a tabok tartalmát, úgy hogy a felhasználó ne vegye észre, csak a tartalom változzon (a fragment, de tabokon ne látszódjon semmi)
[link]
[link]más: foglalkoztál már kamerával készített kép SQLiteban való letárolásával (és lekérdezésével)?
szerintme BLOB helyett az útvonalat fogom letárolni (ahogy néztem ennek egyszerűbbnek kell lennie, meg hasznosabb is, minden fotós alkalmazás ezt használja). persze itt kezelni kell, ha kitörli a júzer a képet, de szerintem ez nem vészes -
eastsider
nagyúr
köszi!
értem mire gondolsz! szerintem így fogom csinálni, mert pont ezen gondolkoztam, hogy fogom megcsinálni a több féle listázást, néztem a metódusokat, de arra jutottam, hogy sehogy (csak simán átgondolva jutottam erre...), nyilván megoldható, csak szívás ahogy írtad. már össze is állt nagyjából a fejemben hogy fogom véghez vinni ezt.illetve mivan akkor, ha rámegyek egy íróra, átugrik a másik fragmentre, akkor ugye a hozzá tartozó (ID-jű) rekordokat hozná be, de mivan akkor, ha az még üres? akkor úgy lenne a jó ha alapból felhozná a dialogot, és az adott Foreign Keyjel létrehozhatna egy képet. bár ez szerintem simán megoldható egy getcount()-al...
illetve szerintem itt megpusztult a tabos elképzelésem, jól értem? mert így már 3 fragment kellene, az meg fura lenne így, vagyis nem lenne funkcionális
-
Karma
félisten
-
thon73
tag
Ilyen nehezet kérdeztem, vagy mindenki békésen szunnyad az ebéd(ek) után?
Saját fejem törésével erre jutottam: Van itten egy olyan, hogy a LoaderManager-től le tudom kérdezni az aktív Loader-eket. Az Activity induláskor megnézi, hogy van-e Loader, s ha igen, akkor beregisztrálja magát (Uis. ilyenkor valaki már létrehozta a Loadert, pontosabban az előző megvalósulásunk hozta létre.) Záráskor szintúgy megnézi, csak éppen kiregisztrálja magát, - kiregisztrálTATja magát a megtalált Loader-rel az obszerválandók közül. Néha elgondolkodom, hogy télleg az Android Way a legegyenesebb-e??
Ha valaki látott már egyszerűbbet, akkor ne habozzon elmesélni...
Teljesen más: Tudja valaki mi az a Samsung File-Stor Gadget? A nem létező UMS kapcsolatom SGSII 4.1.2 alatt ezzel mégis létezik. Ha tudnám, mi ez, rátenném a tabletre is... A szívemhez közel áll a Mass-Storage gyorsasága, és a proxy szerver sem zavarja...
-
#1979
WonderCSabo
félisten
thon73
#1976
WonderCSabo
félisten
A GitHub a nevéből is adódóan git-el működik. Tehát sima git parancsokkal fel tudod nyomni a fájlaidat. Tutorial. Van egy GUIs kliens is (GitHub for Windows vagy GitHub for Mac), amivel talán ez egyszerűbb elsőre, bár sztem borzalmasan rossz, és ha picit is komolyabbat akar az ember úgyis a terminálhoz kell fordulnai.
-
#1960
WonderCSabo
félisten
thon73
#1950
WonderCSabo
félisten
ListViewAnimations lib, ami elég jó és sok mindent tud, ezt a funkciót is támogatja a DynamicListView widgetéjével. (Mielőtt önreklámmal vádolna valaki most mondom, hogy én is toltam bele cár commitot, de nem ezért ajánlom.
) -
-
eastsider
nagyúr
köszi! le is szedtem még régebben
igen, a konstruktor deprecated
@SuppressWarnings("deprecation")
@Override
public void bindView(View view, Context context, Cursor cursor)
{
super.bindView(view, context, cursor);nekem megy így, csak deprecated. nem egy nagy adatbázis... szarni rá, és csináljam így, vagy ha már itt tartok okulásképp érdemes a content providert?
azt olvastam, betöltésnél lehet ez gázos, mert az UI threadben töltődik be az adatbázis is...
-
#1814
WonderCSabo
félisten
thon73
#1813
WonderCSabo
félisten
Nem akarok kikerülő választ adni, de sztem egy bonyolult rajz Fragmentekből való összeállítása egyáltalán nem jó ötlet. A Fragmenteket nem erre találták ki.
A konkrét kérdésedet most hirtelen nem látom át, az onResumeFragments metódust nem használtam sosem, sőt bevallom derekasan picit az egész configuration change kiesett a gyakorlatból, mert a mostani hosszú prokejtemben az egész app álló képes...
-
thon73
tag
Egyszerűsítem a kérdést:
Hová tegyem azokat az (akár nagyméretű) globális adatokat, amiket több fragmentből el akarok érni, de szeretném megtartani őket a konfigurációs változások alatt is?
((Egy ötletem van: Application szintre. Megpróbáltam a retained fragmentet, de sehogyse megy.)) -
Karma
félisten
Ez a kérdés alapján Androidon a FileLock pont az ellen nem véd, amit te csinálsz a fájllal, azaz egy processzen belül két szál között nem csinál semmit...
Szerintem egyébként a teljes elképzelés rossz, a fájlt egyetlen objektumnak szabadna csak írnia, és akkor nem kellene lockolgatni semmit. Például egy háttérszál, akinek van egy BlockingQueue-ja, amibe mindenki más belerakhatja a kiírandó szövegeket, ő meg bedarálja ha van mit, a többi időt meg altatásban tölti.
-
thon73
tag
Még egy utolsó kérdést hadd tegyek fel:
A file írás nem mindig történik meg a záráskor sem (Ezt RandomAccessFile esetén tapasztaltam, még a program bezárása után is hozzányúlt, igaz, csak a metaadatokhoz).
Nem biztonságosabb a FileLock használata az esetemben? Vagy ugyanazt az eredményt érem el, mint a synchronized védelemmel? -
Sianis
addikt
Kicsit egyszerűbre vettem a figurát. Raktam az egész elé egy View-t, ami invisible. Ennek lett egy OnTouchListenere, ami mindig false-t ad vissza, így nem avatkozik bele az alatta lévő bármilyen elem működésébe, ugyanakkor leállítja a postDelayed-del megadott Runnable-t ami megjelenítené a tutorialt. Miután megjelenik a tutorial, elindul ugyanígy egy másik Runnable, ami pedig amint lejár eltűnteti a tutorialt és törli a láthatatlan view-t is így végképp kikerül a zavarási eshetőségek közül.
Sianis
-
Karma
félisten
Az első verzió biztosan nem fog működni, mert a lock objektum példányváltozó, míg a metódusod statikus. A lockot "static final"-ként deklarálva ellenben működhet.
Egyébként a két megoldás között a különbség pont az, amit kifejtettem korábban: ha a synchronized kulcsszót használod a metódus szignatúrájában, akkor vagy a this (példánymetódus esetén), vagy a class objektum (statikus esetben) lesz a lock. Mindkettő elérhető kívülről, így +1 deadlock faktor.
-
Karma
félisten
1) Bevett gyakorlat, hogy a lockhoz használt objektum egy mindentől független, kívülről nem látható, de belül se cserélhető (azaz final) tagváltozó legyen. Ezzel biztosítható, hogy csak ez az egy osztályod lockolhasson az általa védett dolgai körü
l, külső kód véletlenül sem; és hogy nem cserélheted ki másik példányra egy mellényúlással. Vesd össze, ha mondjuk egy ArrayListre lockolsz és van egy gettered a listához, más is rálockolhat és bedeadlockolhatod a programot. Vagy adatok újratöltése után új ArrayListet hozol létre.Más jelentősége tudtommal nincs.
2) Akkor eddig szerencséd volt, hogy az írás és a fájlhandle lezárása gyorsabban lement, minthogy ütközzenek... [link]
-
lac14548
aktív tag
Megnéztem ezt a memento database-t, de nem igazán fogott meg.
Jobb lenne egy kifejezetten arra a célra készült app ami nekem kell.- Küldd el, kérlek, pontosan milyen mezők kellenek!
A már korábban említett 3 mező kellene:
1. Szám (ez maximum 10 jegyű betű és szám vegyesen, kis és nagybetű.)
2. megnevezés (itt több is lehet egy számhoz tartozóan, de a keresésnek bármelyikre tudni kell keresni)
3. leírás (ez egy hosszabb szöveges leírás)A keresés tegyen különbséget az ékezetes karakterekben, viszont a nagy és kisbetűk között ne!
- És milyen "végtermék" kellene? Forrás-project eclipse alá? Vagy csak a kész progi?
A végtermék a kész apk kell, hogy legyen, de ha az adatbázis feltöltéséhez/bővítéséhez/javításához kell a programozási felület, akkor úgy is jó.A továbbiakat szerintem folytassuk privátban, ne terheljük a fórumot.
Kösz,
-
RexpecT
addikt
Köszi, azóta már sikerült megoldani szerencsére.
Hogy lenne érdemes megvalósítani a GPS pozíció folyamatos lekérését úgy hogy külön szálon fusson a lekérés?
Ahogy néztem Handler és a Looper osztályokkal kellene jobban megismerkednem.
Illetve van aki tud valami jó anyagot ajánlani az agilis szoftverfejlesztésről(Scrum)? -
thon73
tag
Elkészültem az első mérésekkel. A szórás ugyan nem változott, de a pufferelt és nem pufferelt beolvasás között több nagyságrendi különbség van. Még file-ban való ugrálás és rövid stringek esetén is, és még utf-8 átalakítással együtt is nyer a pufferelt változat.
Én legalábbis nem gondoltam volna, hogy ekkora különbség van... -
Bozek
nagyúr
Épp ezért nem mertem még én se nekiállni. Bár OOP-t csak Delphi-ben (illetve Lazarus-ban) használtam, de azért van róla fogalmam. Sajnos a C tudásom alap, Java-t meg sose tanultam.
A hibák lekezelése egyik programozási nyelvben sem egyszerű. Anno a tanárom nem is azt nézte, hogy működik-e a program, hanem azt, hogy ki tudja-e akasztani. Mondjuk aki 45 perc alatt bármilyen alkalmazást el tud készíteni hibamentesen, az előtt megemelem a nem létező kalapom.(#1610) WonderCSabo: Én továbbra is tartom a véleményem, hogy 0 programozói tudással inkább ne a Java-val kezdjen. Elég neki a Pascal is, az a legjobb nyelv az alapok megtanulásához. Azt sajnálom, hogy egy csomó algoritmusom volt összegyűjtve, de már nem találom őket sehol. Mondjuk a kétirányú láncolt lista nem épp kezdő szint.
-
#1610
WonderCSabo
félisten
thon73
#1609
WonderCSabo
félisten
Szerintem ez koránt sem így megy. Nulla programozás tudással a ember még az Android Traininget se nagyon fogja fel szerintem.
Már a fogalomrendszer hiányzik. Először én a programozást tanulnám meg, akár a Javán keresztül és utána az Androidot, de ha értelmes tudást akar valaki szerezni akkor legalább félévet csak Javázik előtte szvsz. -
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.
-
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.
-
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!
-
thon73
tag
Ezt (az animációs kérdést) még nem tudtam megoldani, addig is kihagytam az animációt.
Lenne viszont egy egyszerűbb kérdésem: nagy mennyiségű (6-8 db) DialogFragment-et használok/nék. Mi erre a jó megközelítés, hogyan érdemes ennyit beépíteni a programba (egyetlen activity, két fragmenttel)? Van erre egy jó tutorial?
((Pontosítom: A DialogFragment-ek - önmagukban - prímán működnek, a kérdés nem A dialogus létrehozására, hanem SOK dialogus ésszerű kezelésére vonatkozik.))
Köszönöm! -
#1476
WonderCSabo
félisten
thon73
#1475
WonderCSabo
félisten
Meg tudod csinálni programatikusan is, a custom View kosntruktorában:
class CustomEditText extends EditText {
public CustomEditText(Context context, AttributeSet attrs) {
super(new ContextThemeWrapper(context, R.style.your_style), attrs);
}
}Így minden CustomEditText példány a te stílusoddal fog rendelkezni alapból.
-
#1474
WonderCSabo
félisten
thon73
#1473
WonderCSabo
félisten
Hmm, ezt még nem próbáltam ki. Itt a styles.xml. Az EditText stílusát a Widget.TextView style adja meg. Csinálsz egy style-t, ami defeniálja ezek közül azt, amit kell, és beadod a custom view-dnak az android:style propertyn keresztül.
-
#1462
WonderCSabo
félisten
thon73
#1460
WonderCSabo
félisten
Nem, hiszem, hogy jó ötlet a VIew-t így az adatbázishoz kötni. A hivatkozást magát a programkódból változtatod meg, miért nem frissíted kódból egyszerűen a View-idat? Vagy egyszerűen hívsz rajtuk egy update-et, ami majd megint queryzik az adatbázisból a db modulodon kereszütl.
-
#1455
WonderCSabo
félisten
thon73
#1454
WonderCSabo
félisten
Mi ezzel a probléma? Csinálsz mondjuk egy custom view-t, ami mondjuk LinearLayoutból származik. Egy layout fájl tetejére berakoda custom view-t. Mindegyik Fragment ezt a layout filet inflateli, és a custom view alá berakja a saját űrlapját. Ezt még megdobhatod azzal, hogy csinálsz egy ősfragmentet, ami megcsinálja az előzőeket, és az eventekre is ráakaszkodik. A gyerek Fragmentek pedig berakják alá a saját űrlapot, az eventes függvényeik (add, update) pedig meghívódnak mivel az már az ősben kezelven van.
-
#1453
WonderCSabo
félisten
thon73
#1452
WonderCSabo
félisten
Igen, ebben az esetben ez egy járható út. A Builderben az opcinoális paramétereket is beállíthatod, hiszen részben ez is az előnye a konstruktorral szemben. [link] Egyébként nagyon sokan helytelenül hívják ezt Buildernek, ez valójában a Fleunt interface és a Builder egyfajta keveréke.
-
#1451
WonderCSabo
félisten
thon73
#1450
WonderCSabo
félisten
Ha egy Fragment állapotát vissza kell állítani, akkor a következő a szokásos:
public class MyFragment extends ListFragment {
...
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if (savedInstanceState != null) {
// visszaállítod az állapotot
}
}
@Override
public void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
// kimented az állapotot
}
}Ha az allápotot manuálisan kell kimenteni/visszaállítani, azt is megteheted:
Fragment.SavedState state = getFragmentManager.saveFragmentInstanceState(yourFragment);
// ez csak akkor műküdik, ha a FragmentManagerhez éppen csatolva van a Fragment
...
MyFragment fragment = MyFragment.newInstance();
fragment.setInitialSavedState(state); -
#1442
WonderCSabo
félisten
thon73
#1441
WonderCSabo
félisten
Na, én pont ebbe a hibába estem bele mielõtt kérdeztem.
A hszeidből sejtettem, hogy ezt szeretnéd, nem véletlenül írtam ezt a példát.
Illetve estem volna, ha az Eclipse engedi...
Már hogy ne engedné? Ez teljesen szabványos Java kód:
A.java
public class A {
public static A newInstance() {
return new B();
}
}B.java
public class B extends A {
} -
#1440
WonderCSabo
félisten
thon73
#1439
WonderCSabo
félisten
Szia!
Az absztrakt osztály a tervezés eszköze. Nyilván az absztrakt metódus egy előírás a gyerekek számára, amelyet teljesíteniük kell. De itt nem is erről van szó. Itt arra gondoltam, ha úgy írod meg az ősosztály implementációját, hogy számít arra, hogy ezt a gyerek a majd így fogja csinálni. Vagy még rosszabb, az osztály hívatkozik a gyerekire - például a newInstance egy gyerek példányt ad vissza.
-
#1438
WonderCSabo
félisten
thon73
#1437
WonderCSabo
félisten
A newInstance nehezen lehet közös, hiszen ha jól értem abból egy Fragment példánnyal térsz vissza. Továbbá a newInstance egy példányt ad vissza, méghozzá az adott osztályból egy példányt, akkor hogy lehetne az ősben, vagy bárhol máshol, mint a saját osztálya? Illetve még egy dolog: az OO szemléletben egy fontos dolog, hogy a szülőnek nem nagyon szabad tudnia a gyerekeiről... Ha valami közös működést akarsz a Fragment legyártása során, akkor azt tedd meg az ősosztály konstruktorában, és hívjál rá a gyerekekben super hívással. Ha ennél bonyolultabb kell, akkor válaszd az egyik linkelt megoldást, a statikus fv-t meg feletjtsd el ebben az esetben.
-
#1436
SektorFlop
aktív tag
thon73
#1434
SektorFlop
aktív tag
Igen működik, mikor megtaláltam a hibát. megnéztem az onFocus-al is és úgy is frissíti a listát, nem azzal volt a baj, hogy az outFragment-em nem kapott értesülést róla. Az array adapteremet rontottam el egy csöppet.
És azt hiszem még nem köszöntem meg a segítséget, szóval nagyon szépen köszönöm . Megpróbálom valahogy viszonozni, a segítséget és a rám szánt időt.
szóval ez tuti fogyaszt...
ez mennyire gázos dolog amúgy?
Új hozzászólás Aktív témák
- Milyen légkondit a lakásba?
- WoW avagy World of Warcraft -=MMORPG=-
- iPhone topik
- Melyik tápegységet vegyem?
- PlayStation 5
- Allegro vélemények - tapasztalatok
- Nem indul és mi a baja a gépemnek topik
- MWC 2026: Kezünkben a Vivo V70, megvan a magyar ára is
- Xbox Series X|S
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...
- ÚJ Apple Macbook Air 15,3 M4 10C CPU/10C GPU/16GB/256GB - Ezüst mw1g3mg/a - 3 év gari - MAGYAR
- ÁRGARANCIA!Épített KomPhone i5 14400F 32/64GB RAM RX 9060 XT 16GB GAMER PC termékbeszámítással
- 206 - Lenovo Legion Slim 7 (16IRH8) - Intel Core i7-13700H, RTX 4060
- Eladó Pixel 7 obszidián 128/8 és egy fehér Pixel 7 128/8
- Telefon felvásárlás!! iPhone X/iPhone Xs/iPhone XR/iPhone Xs Max
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest