- Kormányok / autós szimulátorok topikja
- Speciális kiadású AMD-s alaplapot villantott az ASUS a 20 éves ROG-jubileumra
- AMD Navi Radeon™ RX 9xxx sorozat
- Milyen ÚJ notebookot vegyek?
- Milyen monitort vegyek?
- Napokon belül váratlan versenyzővel bővül a VGA-piac
- E-book olvasók
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Fejhallgató erősítő és DAC topik
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
Új hozzászólás Aktív témák
-
SektorFlop
aktív tag
A Safe mode lényege az (is), hogy ne indulhasson el third-party alkalmazás, így nemigen hiszem, hogy megvalósítható.
-
trisztan94
őstag
Én erre gondolok.
Ezt úgy tudom elképzelni, mint egy csúszkát egy amd vagy nvidia driverben, ahol a standard a 0 a dynamic a +50 a movie pedig a -50 érték. Mivel kipróbáltam, standardon tényleg sokkal fakóbb, színtelenebb, mellé téve a saját nem s amoledes készülékemet a fehéregyensúlyon kívül számottevő különbség nem volt.Értem amit próbálsz leírni, de sajnos nem lelek válaszra hozzászólásaidban. Azért köszi
Szerintem ez is az Amoled saját cucca, bár lehet, hogy most hülyeséget írok.
Fentebb is írtam, de próbálj meg felrakni egy CyanogenMod-ot, nekem Galaxy Nexus-on az volt és ott tényleg lehetett állítani ezeket, de az is Amoled kijelzős volt.
Más kijelzős mobilon még nem láttam iylet, de nem is nyomkodtam sok mást
-
Pecc
őstag
Szerintem valamit nagyon elnéztél, vagy nem arra gondolsz amit írsz.
Itt egy összehasonlító videó. Super Amoled Wikipedia.
Az amoled kijelzők fő lényege a fentebb leírt élénkség és kontraszt + jó betekintési szögek. Nem driver függő.
Én erre gondolok.
Ezt úgy tudom elképzelni, mint egy csúszkát egy amd vagy nvidia driverben, ahol a standard a 0 a dynamic a +50 a movie pedig a -50 érték. Mivel kipróbáltam, standardon tényleg sokkal fakóbb, színtelenebb, mellé téve a saját nem s amoledes készülékemet a fehéregyensúlyon kívül számottevő különbség nem volt.Értem amit próbálsz leírni, de sajnos nem lelek válaszra hozzászólásaidban. Azért köszi
-
trisztan94
őstag
Nem az teszi, mert ha "normálra van állítva" nincs bekapcsolva ez a dynamic valami, akkor teljesen megegyezik egy "átlagos" kijelzővel, kipróbáltam. Pl, ott a galaxy s3 mini, abban nincs ez a mód, és az is super amoled mégsem olyan színes, hanem ugyanolyan, mint a többi. Ezért érdekelne, hogyan lehet ezt elérni akár a driverben vagy valami apkval, amit a samsung csinál.
-
Pecc
őstag
A Super Amoled (Plus) kijelző teszi, ami a Samsung védjegye már a Galaxy S óta.
Magas kontraszt, élénk színek jellemzik.
Cyanogenmod-on Nexus 3-mon én tudtam állítani a kontrasztot, meg ezeket, de az is Amoled-es, szóval lehet, hogy csak annak lehet.
-
trisztan94
őstag
Sziasztok!
Jópár topicban érdeklődtem már de senki nem tudott érdemi választ adni.
Megfigyeltem, hogy a samu galaxy s tipusú készülékei kijelzője sokkal színesebbek, mint a "többi". Gyakorlatilag ha egymás mellett van egy mezei kijelzős és egy samu s2 az előbbiek szinte olyanok, mintha fekete fehérek lennének. Van a menüben a megjeleitésnél olyan mód, a neve nem jut eszembe ami rettentően megnöveli a kotrasztot és a színtelítettséget, ha ez ki van kapcsolva és alapállásban van ugyanolyan, mint a "többi" kijelző képe. Valoszinüleg olyan dolog történhet, mint egy pc-n a vga driverben való színállítás, kontrasztnövelés stb. Kérdésem van e lehetőség, ilyen beállítás megváltoztatására bármilyen módon, mint amit ez a gyártó eszközöl a romokon?Köszi
-
Pecc
őstag
Sziasztok!
Jópár topicban érdeklődtem már de senki nem tudott érdemi választ adni.
Megfigyeltem, hogy a samu galaxy s tipusú készülékei kijelzője sokkal színesebbek, mint a "többi". Gyakorlatilag ha egymás mellett van egy mezei kijelzős és egy samu s2 az előbbiek szinte olyanok, mintha fekete fehérek lennének. Van a menüben a megjeleitésnél olyan mód, a neve nem jut eszembe ami rettentően megnöveli a kotrasztot és a színtelítettséget, ha ez ki van kapcsolva és alapállásban van ugyanolyan, mint a "többi" kijelző képe. Valoszinüleg olyan dolog történhet, mint egy pc-n a vga driverben való színállítás, kontrasztnövelés stb. Kérdésem van e lehetőség, ilyen beállítás megváltoztatására bármilyen módon, mint amit ez a gyártó eszközöl a romokon?Köszi
-
trisztan94
őstag
Egy szokatlan témával fordulok hozzátok, esetleg valaki tud olyan megoldást ahol az alkalmazás Safe mode-ban is elinduljon?
-
SektorFlop
aktív tag
-
Amúgy hozzáadásképp, a Random Access (DataInput) nem hagyományos UTF-et használ, hanem MUTF-et - persze ez is csak a 4 karakteres (extended) set-re vonatkozik - erre is érdemes figyelni: [link]
De amúgy szerintem van belső parsere valahogy az kellene rávenni, hogy feldolgozza a szövegedet.
Ja és ha indexelsz, akkor eltárolhatod a szöveghosszt is (vagy kivonod a következő indexből) és tudni fogod, mekkorának kell lennie maximum a buffernek. -
A RandomAccess akkor is nagyon jól használható, ha a file tartalma indexelve van. Itt pont ez a helyzet: az első olvasás után minden bekezdés pozíciója ismert, a programnak csak a megjelenő bekezdéseket kell feldolgoznia.
A Stream-ek között nem találtam könnyen pozícionálható megoldást, csak a reset/skip párost. RAF esetén viszont rögtön adott ez a lehetőség; ráadásul a C-hez (és én C-ből akartam áthozni a programot) nagyon hasonló módon.
Csak az utf-8-on akadtam el (pontosabban indultam a fenti szálakon). ((Az eredeti adatok pdb-ben voltak))A pozícionálható Stream az kiváló megoldás lenne. ((A jelenlegi megoldás egy olyan "stream" osztály lett, ami háttérként RAF elérést használ, így pozícionálható is, meg a read() révén "stream" is. Ráadásul Utf8-at olvas.))
(((Az UTF-8-ról annyit érdemes megemlíteni, hogy az első közel 65 ezer karakter a Basic Multilingual Plane. Ez nem csak az összes ékezetes betűt, hanem az összes ismert nyelv betűit tartalmazza. Ebben az a nagyszerű, hogy 16 biten tárolható, vagyis épp egy karakteren. Ami ezen felül van, ahhoz UTF-16-on már két karakter kell. Az UNICODE saját dokumentációja állítja, hogy ez a rész nem kellőképpen tesztelt és megvalósított. Az ANDROID sem következetes, uis. ezt néha egyetlen 4 byte-os int-en ábrázolja, néha két egymás utáni karakteren. Mivel nekem még a beszélt nyelvek közül sem kell az összes, ezért a dekódoló algoritmus figyeli a non-BMP karaktereket, de helyettük egy sima '*' hibajelölést tesz, ami bármilyen kódolásban ábrázolható. Nem lenne nehéz egyébként a dekódolást erre a részre sem kiterjeszteni, csak akkor az egész program működését is ki kellene terjeszteni. ASCII-ról nem volt nehéz ITF-16-ra áttenni, de ha néhol két karakternyi ábrázolással kellene számolnom, az megnehezítené a dolgot.)))
Bocsánat egyébként, ha nagyon triviálisakat kérdezek, de az Android/Java párost csak most tanulom. Némely. engem érdeklő részbe már mélyen beleástam magam, de a legtöbb részt egyáltalán nem ismerem. Ezért örültem az előző tanácsoknak is, mert így új koncepcióban készítettem el a megfelelő részt.
-
Random access-t nem erre találták ki, hanem jól strukturált fájlokra, ahol a mező/rekord-szélesség ismert.
BTW, Stream-ben is tudsz pozicionálni.Más: Ha UTF-et használsz, akkor ne legyenek olyan prekoncepcióid, hogy nem fogsz nem base charset-et használni, mert ha később mégiscsak szeretnéd, akkor aztán igazán szívás lesz az ékezetes karaktereket belehackelned a saját algoritmusodba...
-
Hadd folytassam még az elmélkedést:
Mi a helyzet a RandomAccessFile() eléréssel? Ott nem tudok stream-et használni, vagy nem tudok ugrálni a file-ban.
Vegyünk egy egyszerű példát: sd-kártyára mentett, UTF-8 kódolású, de igen hosszú szöveg egy részét szeretném beolvasni, és a képernyőre írni. (Vagyis egy egyszerű olvasóprogram.) Korábbi olvasásból tudom, hogy hol vannak a bekezdéshatárok, így a feldolgozást tudom a szöveg "közepén" kezdeni.Ha az előző logikát követem, akkor kell készítenem egy saját byte-stream-et, mely a bemenetét a raf.read()-ből veszi, és azt az előző módon adja a konverternek. Ennek az az előnye, hogy minden, android által ismert dekódolást elvégeztethetek.
Vagy - ha biztos vagyok abban, hogy csak BasicMultilingualPlane-t használó Utf8 szövegem van - mégiscsak egyszerűbb magát a decoder-t megírni. Az pont a szükséges byte mennyiséget olvassa ki a forrásszövegből, és karakterenként visszaadja.
Vagy (ezt még nem csináltam): beolvasok egy buffernyi byte-ot, majd valamekkora részt feldolgozok belőle. A végén szinte biztosan egy félbevágott karakter lesz. Átpozícionálom a beolvasást a feldolgozott rész végére, és megyek tovább. Vagy a levágott részeket beteszem a puffer elejére, és onnét folytatom az olvasást.
Mindegyik esetben egy jelentős saját részt kell alkotni, holott egy igen triviális feladatról van szó. Ezt meg tudom kerülni valahogy szabványos rutinokkal?
Ill. a fenti megközelítések közül melyik lenne szerintetek a legeffektívebb/legegyszerűbb??((Az előzőekben egy backup-ként szereplő exportról beszéltünk, ahol a stream kiváló megoldás, mert nem kell benne ugrálni. Az utóbbi egy korábbi probléma, ahol nem ez a helyzet. De kíváncsi lennék a véleményetekre.))
-
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()
-
Remélem működött
Amúgy a stringen belüli többes cserélgetésre meg ismét a Commons Langot javasolnám, csak most a StringUtils.replaceEach metódust. Amúgy is hatékonyabban implementálták, mint a String.replace-t a JVM-ben.
Hátha mást is érdekel, itt a rövid logikája a próbának; egyszerűség kedvéért file helyett stringek, hibakezelés és optimalizálás nélkül. 'c' átalakítása az első ciklusba, a kiírás elé kerülhet. (ed1-ed2-ed3 egyszerűen három EditText. ed2 csak azért kódol ISO-8859-1-et, hogy lássam, hogyan is kerülnek kiírásra a byte-ok.)
Kifelejtettem a lényeget: ed1 (UTF-16 String) -> outputStream==inputStream (UTF-8 byte-array) -> ed3 (UTF-16 String). Tehát oda-vissza elvégzi az átalakítást, és nem String-gel (bár abból indul), hanem Character-folyammal dolgozik.int c;
ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
OutputStreamWriter outputStreamWriter = new OutputStreamWriter(outputStream, "UTF-8");
StringReader stringReader = new StringReader( ed1.getText().toString() );
while ( (c=stringReader.read()) != -1 )
{
outputStreamWriter.write( c );
}
outputStreamWriter.close();
ed2.setText( outputStream.toString("ISO-8859-1") );
ByteArrayInputStream inputStream = new ByteArrayInputStream( outputStream.toByteArray() );
InputStreamReader inputStreamReader = new InputStreamReader(inputStream, "UTF-8");
StringWriter stringWriter = new StringWriter();
while ( (c=inputStreamReader.read()) != -1 )
{
stringWriter.write( c );
}
stringWriter.close();
ed3.setText( stringWriter.toString() );Érdekes, hogy keresgélés közben StraemReader/Writer osztályokat is átfutottam, de nem ugrott be, hogy erre van szükségem. ((Hát, látszik, hogy nem a javaba "nőttem bele", ráadásul évekig nem írtam semmi komolyat.
))A replaceEach is jó ötlet, (és ezzel visszajutottunk a túloptimalizáláshoz.) Ha legyártok egy új string-et, ami már az átalakított részeket tartalmazza, akkor áttekinthetőbbé válik a kód, ill. a fenti helyett a mentést is egy sorban meg tudom oldani. Nem nagy ár ezért az új string létrehozása, akkor sem ha több ezerszer történik meg.
Köszönöm a segítséget, az eredetitől gyökeresen eltérő logikájú kód született, de sokkal szebb, és jobb. Nem végeztem még méréseket, de nem tűnik nagyságrendekkel lassúbnak. (Gondolom, az SD kártya sebessége lesz a meghatározó...)
-
Ez az!! Tudtam én, hogy léteznie kell valami ilyesminek!
Hála és köszönet!
És az OutputStreamWriter konstruktorában már be is állítható az encoding. Rögvest kipróbálom!Remélem működött
Amúgy a stringen belüli többes cserélgetésre meg ismét a Commons Langot javasolnám, csak most a StringUtils.replaceEach metódust. Amúgy is hatékonyabban implementálták, mint a String.replace-t a JVM-ben.
-
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()
Ez az!! Tudtam én, hogy léteznie kell valami ilyesminek!
Hála és köszönet!
És az OutputStreamWriter konstruktorában már be is állítható az encoding. Rögvest kipróbálom! -
((A new line/tab átalakítást csak példának írtam, (és ebben az esetben az első pont teljesen jogos) Esetemben egy kicsit összetettebb dologról van szó: tényleges szövegfeldolgozás történik, a mentett oldalon - értelmezést könnyítendő - a rövid bejegyzéseket mintegy kibontja a program, és egy hosszú file-ban tárolja. Igazából ez is egy decoder, csak épp elég speciális. De ez a programozási probléma szempontjából lényegtelen.))
A röviden pont történt meg most (vagyis megoldást kerestem), és a választ is köszönöm: És meg is fogadom, (2. pont), mert igazad van: nem foglalkozok a teljesítménnyel. Én is gondoltam arra, hogy ha a teljesítmény ilyen fontos tényező, akkor ezt a részt natívan kellene elkészíteni, de ebben (még) nincs tapasztalatom. Egyébként nem olyan félelmetesen hosszú a feldolgozás: vmivel több, mint 200e bejegyzésre 20-40 perc jelenleg
((Arra az indiszkrét kérdésre, hogy akkor miért a telefonom csinálja, csak azt tudom mondani: az mindig nálam van. De egyébként a teljes adatbázist csak egyszer kell megcsinálni, a többi meg már rövid...))((A 3. pontban is nagy igazság van, bár egyszer beleástam magam az unicode-ba, és írtam konvertáló algoritmust is, tehát az van. Az UTF16->UTF8 irány elég egyszerű, hiszen ott (felső részek kivételével) minden karakter létezik. A fordított irány az érvénytelen szekvenciák miatt egy kicsit izgalmasabb.
A gond egyébként pont abban van, hogy az UTF8 nem egyforma hosszú részekből áll (na persze ez az előnye is), és ez - saját kód nélkül - megnehezíti a szövegfeldolgozást. A legegyszerűbb példa: nagyon nehéz effektív UTF8 beolvasást csinálni, mert nem tudod, hogy pontosan hány byte-ot kell/lehet a pufferbe olvasni, és ezért pl. vagy "görgetni" kell a puffert, vagy figyelni a végén az eltört karakterekre. Ezért is gondoltam, hogy egyfajta stream-szerű beolvasás (szerű, mert UTF8 karakterenként olvas/ír) egyszerűsíteni az életet, de még nem találtam ilyet készen. Ettől függetlenül masszívan igaz, hogy meglehetősen túlkomplikálja a programot. Bocs a hosszú okfejtésért.))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()
-
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.
((A new line/tab átalakítást csak példának írtam, (és ebben az esetben az első pont teljesen jogos) Esetemben egy kicsit összetettebb dologról van szó: tényleges szövegfeldolgozás történik, a mentett oldalon - értelmezést könnyítendő - a rövid bejegyzéseket mintegy kibontja a program, és egy hosszú file-ban tárolja. Igazából ez is egy decoder, csak épp elég speciális. De ez a programozási probléma szempontjából lényegtelen.))
A röviden pont történt meg most (vagyis megoldást kerestem), és a választ is köszönöm: És meg is fogadom, (2. pont), mert igazad van: nem foglalkozok a teljesítménnyel. Én is gondoltam arra, hogy ha a teljesítmény ilyen fontos tényező, akkor ezt a részt natívan kellene elkészíteni, de ebben (még) nincs tapasztalatom. Egyébként nem olyan félelmetesen hosszú a feldolgozás: vmivel több, mint 200e bejegyzésre 20-40 perc jelenleg
((Arra az indiszkrét kérdésre, hogy akkor miért a telefonom csinálja, csak azt tudom mondani: az mindig nálam van. De egyébként a teljes adatbázist csak egyszer kell megcsinálni, a többi meg már rövid...))((A 3. pontban is nagy igazság van, bár egyszer beleástam magam az unicode-ba, és írtam konvertáló algoritmust is, tehát az van. Az UTF16->UTF8 irány elég egyszerű, hiszen ott (felső részek kivételével) minden karakter létezik. A fordított irány az érvénytelen szekvenciák miatt egy kicsit izgalmasabb.
A gond egyébként pont abban van, hogy az UTF8 nem egyforma hosszú részekből áll (na persze ez az előnye is), és ez - saját kód nélkül - megnehezíti a szövegfeldolgozást. A legegyszerűbb példa: nagyon nehéz effektív UTF8 beolvasást csinálni, mert nem tudod, hogy pontosan hány byte-ot kell/lehet a pufferbe olvasni, és ezért pl. vagy "görgetni" kell a puffert, vagy figyelni a végén az eltört karakterekre. Ezért is gondoltam, hogy egyfajta stream-szerű beolvasás (szerű, mert UTF8 karakterenként olvas/ír) egyszerűsíteni az életet, de még nem találtam ilyet készen. Ettől függetlenül masszívan igaz, hogy meglehetősen túlkomplikálja a programot. Bocs a hosszú okfejtésért.)) -
Igen, ez világos. Igyekeztem a kérdést a problémás részig egyszerűsíteni, ebből a félreértés. De a szélesebb problémára is szívesen fogadok ötleteket:
Adott egy String, ami EditText-ből, vagyis a felhasználótól származik (és egy adatbázis tárolja). Ezt a Stringet szeretném UTF-8 kódolású txt file-ba menteni. Ez idáig egyszerű, és két sorban megoldható.
DE!
Mentés előtt a String-en utólagos feldolgozást végez a program, néhány részét cseréli. (Gondoljunk pl. arra, hogy pl. tab-ot \\t-re, new-line-t \\n-re, vagy esetemben speciális, de olvasható tag-okat szúr be.) Erre a legegyszerűbb mód, ha StringReader-ként kiveszem a karaktereket, átalakítom, és az eredményből egy új folyamot hozok létre. A karakterek 99%-a változatlanul (vagyis egy karakterként) fut tovább, de néha a karakter helyett egy rövid szövegrész megy ki. Nem akartam új String-et készíteni, hanem azonnal az UTF-8 típusú kimenetre küldeném az adatokat.
Eddig csak olyan megoldást találtam, ami String-et, vagyis hosszabb szöveget alakít UTF-8-ra. Az 1%-nyi részben ez tökéletes, de 99%-ban ez a String csupán egyetlen karakter hosszú lesz. Van vajon erre frappáns megoldás, vagy egyszerűbben járok egy UTF-8 kódoló megírásával?
Vagy esetleg lehet-e az egész gondolatmenetet előnyösebben elrendezni? -
UTF16-ról nincs értelme karakterenként UTF8-ra konvertálni, mert a két formátum teljesen különbözik egymástól.
Ha az egész string-re szükséged van, akkor az egészet úgy ahogy át kell konvertálni, mert az utf16 2-byte-os (illetve 2*2 byte-os a kiegészítő karakterkészletekre) reprezentáció, az utf8 pedig dinamikusan változó 1-4 byte hosszú reprezentáció. -
UTF16-ról nincs értelme karakterenként UTF8-ra konvertálni, mert a két formátum teljesen különbözik egymástól.
Ha az egész string-re szükséged van, akkor az egészet úgy ahogy át kell konvertálni, mert az utf16 2-byte-os (illetve 2*2 byte-os a kiegészítő karakterkészletekre) reprezentáció, az utf8 pedig dinamikusan változó 1-4 byte hosszú reprezentáció. -
Még egy kérdés. más témában:
EGYETLEN karaktert kell Character típusról (UTF-16) UTF-8-ra konvertálnom (mármint egyszerre egyet, de nem teljes stringet). Mi szerintetek erre a leggyorsabb/legegyszerűbb módszer?
(A String konvertálása ok, csak szerintem az nagyon pazarló, ha csak külön karakterek átalakításáról van szó.) -
szarkazsolt
csendes tag
-
SektorFlop
aktív tag
Hagyom is, nem találtam én se semmit a neten.
Viszont még egy dolog, van egy GridView, ami néha a görgetés után furán viselkedik. pl. legörgetem majd miután vissza görgetem eltűnik az egyik elem, vagy túl lehet görgetni, mintha "leszaladna" róla minden(bár elég látványosan csinálja, de még nem kellene
).public View getView(int position, View convertView, ViewGroup parent) {
if(convertView == null) {
LayoutInflater inflater = LayoutInflater.from(parent.getContext());
convertView = inflater.inflate(layout, parent, false);
}
tvAppLabel = (TextView) convertView.findViewById(R.id.tvAppName);
ivAppIcon = (ImageView) convertView.findViewById(R.id.ivAppIcon);
ivAppStatus = (ImageView) convertView.findViewById(R.id.ivAppStatus);
int id = Integer.parseInt(Ids[position]);
try{
tvAppLabel.setText(ApplicationModel.GetbyId(id).AppLabel);
if (ApplicationModel.GetbyId(id).AppSatus != null) {
if (ApplicationModel.GetbyId(id).AppSatus == true)
ivAppStatus.setBackgroundResource(R.drawable.app_disabled);
else
ivAppStatus.setBackgroundResource(R.drawable.app_enabled);
}
if (ApplicationModel.GetbyId(id).AppIcon != null) {
ivAppIcon.setImageDrawable(ApplicationModel.GetbyId(id).AppIcon);
}
}catch(Exception ex){
CatchError(ex.toString(), context);
}
return convertView;
} -
Időközben megtaláltam miért kell konstruktort készíteni DialogFragment-hez. A rendszer készít default konstruktort, de az érvényességi tartománya az osztályéval fog megegyezni. Itt viszont public konstruktor KELL. Másrészt, ha van paraméterezett konstruktor, akkor nem készül üres.
Vagyis:
public osztályban, ahol nincs konstruktor, ott nekünk sem kell készíteni.
Nem public DialogFragment-nél, vagy ha van paraméterezett konstruktor, akkor kell készíteni public jelzővel és paraméter nélkül.
Talán másnak is segít ez.De van egy másik elméleti kérdésem: Van egy Fragment (az egyszerűség kedvéért onRetainInstance(true), és ebben van egy TextView. Egy háttérszálon futó folyamat időnként kiüzen az UI szálra, és innen írja a TextView-t. Mikor lehet ezt büntetlenül megtenni? Melyik életciklusok között, vagy mit kell ellenőrizni? Vagy teljesen mindegy, akkor is írhatja, ha pl. a Fragment nem is látszik, vagy dettach-olva van? Van erre valami szabály?
Köszi! -
thon73
tag
De akkor miért készít egy csomó példa expliciten public konstruktort? Az üres, public, alapértelmezett konstruktor nem készül el automatikusan az osztályhoz?
Amennyiben te magad deklarálsz konstruktort, akkor a default nem fog generálódni. Amennyiben nem deklarálsz semmilyen konstruktort, akkor igen.
-
SektorFlop
aktív tag
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.
Hagyom is, nem találtam én se semmit a neten.
Viszont még egy dolog, van egy GridView, ami néha a görgetés után furán viselkedik. pl. legörgetem majd miután vissza görgetem eltűnik az egyik elem, vagy túl lehet görgetni, mintha "leszaladna" róla minden(bár elég látványosan csinálja, de még nem kellene
).public View getView(int position, View convertView, ViewGroup parent) {
if(convertView == null) {
LayoutInflater inflater = LayoutInflater.from(parent.getContext());
convertView = inflater.inflate(layout, parent, false);
}
tvAppLabel = (TextView) convertView.findViewById(R.id.tvAppName);
ivAppIcon = (ImageView) convertView.findViewById(R.id.ivAppIcon);
ivAppStatus = (ImageView) convertView.findViewById(R.id.ivAppStatus);
int id = Integer.parseInt(Ids[position]);
try{
tvAppLabel.setText(ApplicationModel.GetbyId(id).AppLabel);
if (ApplicationModel.GetbyId(id).AppSatus != null) {
if (ApplicationModel.GetbyId(id).AppSatus == true)
ivAppStatus.setBackgroundResource(R.drawable.app_disabled);
else
ivAppStatus.setBackgroundResource(R.drawable.app_enabled);
}
if (ApplicationModel.GetbyId(id).AppIcon != null) {
ivAppIcon.setImageDrawable(ApplicationModel.GetbyId(id).AppIcon);
}
}catch(Exception ex){
CatchError(ex.toString(), context);
}
return convertView;
} -
Karma
félisten
Átalakítottam az adapter, most már görgetésnél nem dobálja, de megnyitásnál maradt változatlan.
-
SektorFlop
aktív tag
-
#89874944
törölt tag
Sziasztok!
Használja itt vki az SL4A-t pythonhoz? Feltettem a python 2.6.6-ot, eclipse-hez a python plugin-t, de amikor importálnám az android-ot azt írja unresolved import: android
Egy leírásban az van, hogy tegyük path-ra a python-t (android debug bridge - path). Mit jelenthet ez?
Eddig amiket csináltam:
A parancssoron python - hello world ment.
Android Device Manager fut.
Eclipse PyDev plugin -> OK.
Eclipse phyton module "hello world" -> OK.
SL4A phyton interpreter -> OK.és akkor itt van a gond...
Eclipse azt mondja Unresolved import:android
pydev debugger: starting
Traceback (most recent call last):
File "C:\Users\Tibi\Desktop\adt-bundle-windows-x86_64-20130917\eclipse\plugins\org.python.pydev_2.8.2.2013090511\pysrc\pydevd.py", line 1446, in <module>
debugger.run(setup['file'], None, None)Előre is köszi a segítséget.
Üdv Tibi
-
Karma
félisten
09-28 12:48:05.610: E/dalvikvm(13194): GC_FOR_ALLOC freed 350K, 43% free 9531K/16519K, paused 2ms+2ms, total 26ms
09-28 12:48:05.660: E/dalvikvm(13194): GC_CONCURRENT freed 11K, 29% free 11823K/16519K, paused 12ms+2ms, total 38ms
09-28 12:48:07.170: E/dalvikvm(13194): GC_CONCURRENT freed 490K, 27% free 12224K/16519K, paused 14ms+6ms, total 68ms
09-28 12:48:07.900: E/dalvikvm(13194): GC_CONCURRENT freed 459K, 24% free 12681K/16519K, paused 13ms+16ms, total 72ms
09-28 12:48:08.420: E/dalvikvm(13194): GC_CONCURRENT freed 580K, 23% free 12850K/16519K, paused 16ms+26ms, total 104ms
09-28 12:48:13.250: E/dalvikvm(13194): GC_CONCURRENT freed 455K, 21% free 13101K/16519K, paused 14ms+14ms, total 71ms
09-28 12:48:35.120: E/dalvikvm(13194): GC_CONCURRENT freed 451K, 20% free 13303K/16519K, paused 13ms+24ms, total 75ms
09-28 12:48:37.510: E/dalvikvm(13194): GC_CONCURRENT freed 282K, 18% free 13618K/16519K, paused 15ms+14ms, total 97msEzekkel tudok valamit, csinálni? Amikor megnyitok egy ListView, vagy elkezdem azt görgetni akkor dobálja.
-
SektorFlop
aktív tag
-
WonderCSabo
félisten
Köszönöm, rengeteget tanultam! Sok példát elolvastam, de a static factory method kifejezést egyik sem említette, (csak használta.) De én nem ismertem, úgyhogy köszönöm!
Még egy kérdés: Ha jól látom, akkor általában static factory method esetén érdemes "elrejteni" a konstruktort. Fragment-nél ezt nem tehetjük meg, mert újraindításnál a rendszer a public konstruktoron keresztül indítja újra a Fragment-et.
De akkor miért készít egy csomó példa expliciten public konstruktort? Az üres, public, alapértelmezett konstruktor nem készül el automatikusan az osztályhoz? Tényleg ki KELL írni, vagy ez csak didaktikailag szerepel ott? (speciel nekem külön odaírás nélkül is működött) -
thon73
tag
Bocs kicsit elkapkodtam a választ és lejárt a szerkesztési idő. A linkelt cikk ugyanazt a célt szolgálja, de nem teljesen egyezik az általad mutatott mintával. Ez igazán pontosan a static factory method pattern. Ez a SO válasz szépen leírja az általános használatát. Ha picit mélyebbre akarsz menni, akkor olvasd el az Effective Java erre vonatkozó részét.
Fragmentekre levetítve pedig itt és itt magyarázat. -
Sianis
addikt
Bocs kicsit elkapkodtam a választ és lejárt a szerkesztési idő. A linkelt cikk ugyanazt a célt szolgálja, de nem teljesen egyezik az általad mutatott mintával. Ez igazán pontosan a static factory method pattern. Ez a SO válasz szépen leírja az általános használatát. Ha picit mélyebbre akarsz menni, akkor olvasd el az Effective Java erre vonatkozó részét.
Fragmentekre levetítve pedig itt és itt magyarázat. -
WonderCSabo
félisten
-
WonderCSabo
félisten
Bocsánat előre a kezdő kérdésért.
DialogFragment készítésénél minden útmutató készít egy newInstance() metódust, sőt az arg-okat is ezen keresztül adja át. ((Amúgy én is ezt használtam.)) A google útmutatóban is ez szerepel.
Arra nem jövök rá, hogy ez miért jobb, mint ha a DialogFragment elkészítését (new) a show() hívás előtt végzem el (mint egy sima Fragmentnél). Ugyanúgy egy sor, ugyanúgy működik.
Csak izlések és pofonok? Vagy van valami, ami elkerülte a figyelmemet? Még egyszer: értem, hogy hogyan működik, használtam is, csak az zavar, hogy magamtól teljesen más módszert alkalmaznék/alkalmaztam volna. Viszont kivétel nélkül mindenki más a fenti módszert írja le, de senki nem említi, hogy miért pont ezt.
Bocs, ha nagyon stupid a kérdés; hálás köszönet, ha valaki mégis veszi a fáradtságot, és elmagyarázza, hogy mit nem vettem észre. Köszi!
-
SektorFlop
aktív tag
-
Sianis
addikt
Semmi az égvilágon, de csak akkor írja ha az én launcherem van beállítva.
-
SektorFlop
aktív tag
-
Sianis
addikt
Készítettem egy launchert, de készülék újraindításánál figyelmeztet, hogy a memóriából elvesznek az adatok.
"Restarting your phone will clear temporary files out of memory. Would you like to restart your phone now?"
Tudnátok mondani, egy két dolgot aminél előjöhet ez az üzenet? Én már napok óta ezzel harcolok, de sajnos nem jutottam előrébb.
-
SektorFlop
aktív tag
-
Karma
félisten
Sziasztok!
Mennyire bonyolult egy "hangfelismerőt" implementálni alkalmazásban? Valami olyasmi kellene, hogy ha tapsol a felhasználó, akkor bekapcsol a vaku, stb.
-
trisztan94
őstag
-
SektorFlop
aktív tag
-
Karma
félisten
"tap to restart" funkció, tehát, hogy akárhova nyom a képernyőn, azt nézze.
Végül megoldottam, nem a textúrára kellett az inputListener. Szimplán implementálni kellett az InputProcessor osztályt az osztályomban, kigenerálni a metódusokat (touchDown, mouseMoved, stb) és akkor az egész képernyőre megy a listener.Itt van ezzel kapcsolatban a SO kérdésem, amit meg is válaszoltam.
Más:
Exportálni akarom a játékot, mint apk. Kér valami Keystroke-ot. Az micsoda? Mire való?Illetve kér még több adatot, ha új keystroke-ot akarok csinálni, azok micsodák?
Alias - ez gondolom az app neve, nem?
Validity?Amikor kitöltöttem ezt az oldalt is, akkor viszont egy ilyen hibát dob:
"keytool error: java.io.IOException: Incorrect AVA format."Ez gondolom a kiválasztott keystroke formája lesz, mert nem volt kiterjesztés amikor mentettem a fájlt. MIlyen kiterjesztés kell neki?
-
moli.hu
őstag
Mégis mire kell ez Neked?
-
trisztan94
őstag
Mégis mire kell ez Neked?
"tap to restart" funkció, tehát, hogy akárhova nyom a képernyőn, azt nézze.
Végül megoldottam, nem a textúrára kellett az inputListener. Szimplán implementálni kellett az InputProcessor osztályt az osztályomban, kigenerálni a metódusokat (touchDown, mouseMoved, stb) és akkor az egész képernyőre megy a listener.Itt van ezzel kapcsolatban a SO kérdésem, amit meg is válaszoltam.
Más:
Exportálni akarom a játékot, mint apk. Kér valami Keystroke-ot. Az micsoda? Mire való?Illetve kér még több adatot, ha új keystroke-ot akarok csinálni, azok micsodák?
Alias - ez gondolom az app neve, nem?
Validity?Amikor kitöltöttem ezt az oldalt is, akkor viszont egy ilyen hibát dob:
"keytool error: java.io.IOException: Incorrect AVA format."Ez gondolom a kiválasztott keystroke formája lesz, mert nem volt kiterjesztés amikor mentettem a fájlt. MIlyen kiterjesztés kell neki?
-
WonderCSabo
félisten
-
trisztan94
őstag
-
trisztan94
őstag
-
thon73: Ha betölteni akarsz akkor célszerű, hogy nem használod az adatbázist másra... És vagy az alkalmazás inicializálásakor töltöd be az adatokat, vagy leállítod azokat az activityket, amik piszkálják az adatbázist.
In-app exportra ezt találtam:
http://bloggerinme.wordpress.com/2011/12/05/android-database-table-export-to-csv-part-3/Importálni is - szvsz - csak full lekódolva lehet... Pl:
http://stackoverflow.com/questions/16672074/import-csv-file-to-sqlite-in-android -
-
sqlite command line kliens:
Import
sqlite3.exe database.db
>
.mode csv
.import [fájlnév.csv] [táblanév]
.exitImportnál a táblának már léteznie kell és azonos struktúrájunak lenni, mint a CSV fájlnak. CVS fájlból a header-t (1. sor) törölni kell import előtt.
Export
sqlite3.exe database.db
>
.mode csv
.header on
.output fájlnév.csv
.dump [táblanév]
.exitexe? Androidon?
-
Konair
csendes tag
Ne a rotation matrixot használd, hanem az getOrientation() metódust. Ez sokkal könyebben értelmezhető, lásd javadoc.
-
WonderCSabo
félisten
Sziasztok!
Programomban szeretném lekérdezni a függőleges gyorsulás mértékét.
Ha a telefon fektetve van, akkor a gyorsulásmérő szenzorral ezt szépen ki is írja a Z tengelyre. Amint a telefont elforgatom, akkor már változnak a tengelyek, és nem tudom miként lehetne lekérdezni.
Olyan megoldás kéne, mint a linear acceleration, csak függőlegesen.
Nézegettem a rotation matrix-ot, de nem sikerült rájönnöm a működésére.Köszi a segítséget előre is!
-
WonderCSabo
félisten
Igen ezt én is megtaláltam, de ettől még fel lehet telepíteni.
android:required:
Boolean value that indicates whether the application requires the feature specified in android:name.
When you declare "android:required="true" for a feature, you are specifying that the application cannot function, or is not designed to function, when the specified feature is not present on the device.
When you declare "android:required="false" for a feature, it means that the application prefers to use the feature if present on the device, but that it is designed to function without the specified feature, if necessary.
The default value for android:required if not declared is "true". -
Igen ezt én is megtaláltam, de ettől még fel lehet telepíteni.
android:required:
Boolean value that indicates whether the application requires the feature specified in android:name.
When you declare "android:required="true" for a feature, you are specifying that the application cannot function, or is not designed to function, when the specified feature is not present on the device.
When you declare "android:required="false" for a feature, it means that the application prefers to use the feature if present on the device, but that it is designed to function without the specified feature, if necessary.
The default value for android:required if not declared is "true". -
Igen ezt én is megtaláltam, de ettől még fel lehet telepíteni.
android:required:
Boolean value that indicates whether the application requires the feature specified in android:name.
When you declare "android:required="true" for a feature, you are specifying that the application cannot function, or is not designed to function, when the specified feature is not present on the device.
When you declare "android:required="false" for a feature, it means that the application prefers to use the feature if present on the device, but that it is designed to function without the specified feature, if necessary.
The default value for android:required if not declared is "true".Mármint megjelenik a Playben olyan telefonon, aminek nincs az adott szenzora?
-
thon73
tag
Jól tudod, az onPause az a metódust, amire utoljára lehet számítani, hogy lefut, a többi nem garantált. Én most kipróbáltam a HTC Sensationömön, ott lefut kikapcsoláskor. Emulátoron is megnéztem, ott szintén.
Mindkettőtöknek nagyon köszönöm a segítséget; továbblökött a mélypontról. Ennyire nehéz hibakeresést még soha nem csináltam, ugyanis minden próbálkozás között újra kellett indítani a telót (ami kb. fél perc).
Bocsánat, az onPause irány véletlen volt (de egy fél nap keresés után már nem találtam más okot) ,valóban úgy tűnt, hogy az marad ki: a hiba CSAK leállításkor jelentkezett; az eclipse debugger nem követte ilyenkor az onPause-t (mint utóbb rájöttem: hiszen leállt), a Log-ot meg én bénáztam el. De a hozzászólásotok után végig belogoltam, és akkor kiderült, hogy onPause van, csak ami benne lenne - no az nincs.A tanulság kedvéért a hiba (egyébként utólag pofon egyszerű, de csapdás):
A program egy gigantikus RandomAccessFile-t ír/olvas az sd-n. (Ennyiben a felhasználói adatok azonnal kikerülnek.)
Az onPause részben (többek között) azt kell elmenteni, hogy valaki nem piszkál-e bele a RAF file-ba, amíg távol vagyunk. Ehhez mentem (név mellett) a méretét (File.length()) és az utolsó módosítás időpontját (File.lastModified()). Újraindításkor ezt ellenőrzi.
Ez a módszer prímán működik, amíg ki nem kapcsoljuk a telót.A gondot az jelentette, hogy a RandomAccessFile NEM szinkron írást csinál, sőt a close() után sem írja ki az adatokat! (Ezt bizonyára mindenki tudja, valószínűleg én is, csak nem gondoltam rá.) Véletlenül "rw" módot adtam meg az "rws" helyett.
Az érdekesség, hogy több hetes próbálgatás alatt is a nem-szinkron kiírás MINDIG bekövetkezett az onPause előtt, ha szabványosan léptem ki. Ha a telefont kikapcsoltam akkor SOHA nem következett be az aszinkron írás az onPause előtt (ezt két napja tudom).
((Megjegyzem, sehol nem találtam részletes dokumentációt arról, hogy pontosan mi és milyen sorrendben történik a kikapcsoláskor.))Van még egy probléma, ami komoly fejtörésre adhat okot: RandomAccessFile "rws" írásakor SEM stimmel a lastModified() érték a visszaolvasáskor!! Az esetek 90%-ban pontosan EGY másodperc (1000 ms) különbség van a két külön alkalommal visszaolvasott érték között!! Mivel a lastModified() érték MINDIG három 0-val végződik (vagyis nem ms, hanem másodperc pontos) valószínűleg a kerekítésnél lehet gond; de ezt nem tudom, csak gondolom. Hivatkozást nem találtam SGS2 és Note gépeken próbáltam.
Köszönöm, hogy kipróbáltátok, teljesen fals útról térítettek vissza; így jópár további óra alatt meglett a hiba!
-
Sziasztok!
Az onPause metódusban van egy fontos mentésem. Próbálgatás közben az derült ki, hogy amikor kikapcsolom (úgy értem teljesen, android logo meg minden) a gépet, akkor NEM fut le az onPause, és következményesen NEM történik meg a mentés.
Az onPausenek nem kellene mindig lefutnia?? Hová lehet még tenni a mentést, hogy biztosan megtörténjen?? (Jó, mondjuk akksi kivétel ellen nincs orvosság, de ez egy "tervezett" leállítás!)
Találkoztatok már ezzel a problémával? Minden segítséget hálásan köszönök!
-
WonderCSabo
félisten
Sziasztok!
Az onPause metódusban van egy fontos mentésem. Próbálgatás közben az derült ki, hogy amikor kikapcsolom (úgy értem teljesen, android logo meg minden) a gépet, akkor NEM fut le az onPause, és következményesen NEM történik meg a mentés.
Az onPausenek nem kellene mindig lefutnia?? Hová lehet még tenni a mentést, hogy biztosan megtörténjen?? (Jó, mondjuk akksi kivétel ellen nincs orvosság, de ez egy "tervezett" leállítás!)
Találkoztatok már ezzel a problémával? Minden segítséget hálásan köszönök!
-
SektorFlop
aktív tag
-
WonderCSabo
félisten
-
negyedes
addikt
Pl. a View.setBackgroundXXX metódusok valamelyikével.
Koszi megvan.
Azt hogy tudnam elerni hogy az email appom egy resze mindig fusson es 10 percenkent megnezne hogy jott-t uj email attol fuggetlenul hogy az app fut vagy nem.
-
WonderCSabo
félisten
-
trisztan94
őstag
Miért nem vált át a GameOver screen-re a game? (libgdx)
if(catched == 1){
setScreen(new GameOver(true));
}Nincs külön class-ekre bontva az app (nagyon egyszerű, nincs rá szükség), a MainGame.class így néz ki:
public class MainGame extends Game {
create metódus(),
render metódus(),
... stb
}A render metódusban amikor "elkapok egy vízcseppet", akkor a catched 1-el növekszik, de ez működik is, mert a fenti elágazásba egy log-ot is raktam, és szépen kiírja, hogy nyertél.
a setScreen(new GameOver(true)); átal átadott boolean érték azt mondja, hogy nyert-e a játékos, vagy veszített-e.
A GameOver class egy másik mappában van (Screen/GameOver.class) és az így néz ki:
public class GameOver implements Screen{
boolean win;
Texture bucketTexture;
Texture dropTexture;
SpriteBatch batch;
OrthographicCamera camera;
public GameOver(boolean win)
{
this.win = win;
}
@Override
public void render(float delta) {
Gdx.gl.glClearColor(0, 0, 0, 1);
Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);
batch.begin();
if(win == true){
batch.draw(bucketTexture, camera.viewportWidth / 2, camera.viewportHeight / 2);
}
else{
batch.draw(dropTexture, camera.viewportWidth / 2, camera.viewportHeight / 2);
}
batch.end();
}
//... satöbbiAmikor át kéne váltania a Screen-t, akkor semmi sem történik, csak egy másodpercre befagy a játék és folytatódik tovább
-
fatal`
titán
Igen keves, de milyen szep lista. Kenyaban, mexikoban, oroszoknal, indiaban, braziloknal, argentinoknal, portugaloknal, lengyeleknel es cseheknel is lehet. Csodalatos
-
szabi__memo
nagyúr
Fizetős appok feltöltése országonként: [Google Play @ Wikipedia]
A Developers can sell oszlopot tessék nézni.
-
fatal`
titán
Magyarország kis ország, kevés fejlesztővel, így rohadtul nem érdekli a Googlet.
-
szabi__memo
nagyúr
-
PandaMonium
őstag
Magyarország kis ország, kevés fejlesztővel, így rohadtul nem érdekli a Googlet.
Ez sajnos nem mentség arra a nem éppen maroknyi emberre nézve aki szeretne ilyesmiből élni (köztük én is). Persze, lehet, hogy csak pár százan lennénk ilyen magyarok és ez a Google-nek nem nagy szám, de nekünk már elég komoly probléma, 1 platformal kevesebb amire fejleszthetünk. Ha meg iOS-re akarok fejleszteni akkor mindenképp Apple OSX (laptop, iMac vagy Mac Mini) cuccomnak kell lennie (vagy Hackintosh-ozni, ami elég felejtős), mert hivatalosan ugye csak arról lehet iOS-re publikálni. Hihetetlen, hogy ezek a mobil platformok milyen feltételekkel léteznek...
Marad a Steam, ahol a Greenlight-on már utcahossznyi tumultus van, az Xbox Live és még esetlegesen a Playstation Network ha ki tudja imádkozni az ember a Sony-ból, hogy regisztrált fejlesztő legyen és egyáltalán hozzáférést kapjon az SDK-hoz.
Ha már itt lyukadtam ki megkérdezem: Nem tudjátok, hogy az OUYA marketjére lehet-e fizetős cuccokat felrakni M.o. -ról? Mert ugye elvileg az is Android, de közben van saját marketplace-e.
))
Bár az lehet csúnyább volt.xd
Marad a Steam, ahol a Greenlight-on már utcahossznyi tumultus van, az Xbox Live és még esetlegesen a Playstation Network ha ki tudja imádkozni az ember a Sony-ból, hogy regisztrált fejlesztő legyen és egyáltalán hozzáférést kapjon az SDK-hoz.
Új hozzászólás Aktív témák
- Kormányok / autós szimulátorok topikja
- Diablo IV
- Speciális kiadású AMD-s alaplapot villantott az ASUS a 20 éves ROG-jubileumra
- Mesterséges intelligencia topik
- AMD Navi Radeon™ RX 9xxx sorozat
- Magisk
- Gyúrósok ide!
- Okosóra és okoskiegészítő topik
- One otthoni szolgáltatások (TV, internet, telefon)
- Arc Raiders
- További aktív témák...
- 27% - Sapphire PULSE Radeon RX 7800 XT 16GB GDDR6 Videokártya!
- Dell Latitude 3380 - Core i3 6006U, 4-8GB DDR4 RAM, gyári töltő, számla, 6 hó gar
- 27% - ÚJ Kingston FURY Beast 64GB (2x32GB) DDR5 5600MHz KF556C36BBEK2-64
- Apple iPhone 15 Pro 128GB eladó! 86% akku, Patika állapot, 12 hónap garancia
- Apple iPhone 16 Pro Max 256GB eladó! 94% Akku, Szép állapot, 12 hó gar
- LG 32GS95UV-B OLED Monitor! 3840x2160 / 480Hz / 0.03ms / FreeSync / G-Sync
- Dell M4500 Intel core i7-640M / 4GB RAM
- Alienware Aurora R13 Gaming! i7-12700KF / RTX 3080 Ti / 32GB DDR5 / 1TB NVMe / 1TB HDD! BeszámítOK
- Akció! Gamer PC-Számítógép! Csere-Beszámítás! I9 13900 / RTX 3090 24GB / 32GB RAM / 1TB SSD
- Samsung Galaxy A21s 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest