van esetleg itt valaki aki Androidos appot fejleszt SDL2-vel?

Semmi az égvilágon, de csak akkor írja ha az én launcherem van beállítva.

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."

És más launcherrel nem ír ilyet?

Sianis

Közben megnéztem, más készülékeken is. Úgy nézz ki csak ezen az egyen csinálja. Kíváncsi lennék, hogy miért.

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."

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!

[link]

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.

[ Szerkesztve ]

Ezt a mondatot emelném ki rendkívül: "This Bundle will be available even if the Fragment is somehow recreated by Android.". Minden Fragmentnek kell lennie egy default konstruktornak, mert a rendszert azt fogja hívni bizonyos esetekben. És ha a fragment fel van készítve arra, hogy az argumentsből fel tudjon állni, no akkor van jól megírva a dolog.

Sianis

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)

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.

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 97ms

Ezekkel tudok valamit, csinálni? Amikor megnyitok egy ListView, vagy elkezdem azt görgetni akkor dobálja.

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."

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.

“All nothings are not equal.”

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

Átalakítottam az adapter, most már görgetésnél nem dobálja, de megnyitásnál maradt változatlan.

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."

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.

“All nothings are not equal.”

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;
}

[ Szerkesztve ]

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."

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!

[ Szerkesztve ]

No, kiteszteltem, hogyan működik. Ha a Frgamentben egy View objektum értéket kap, akkor a hozzá tartozó View mögötti objektum megmarad az életciklus végéig, tehát írható. A TextView-t még az onDestroy-ban is tudtam írni.
Az más kérdés, hogy az onDestroyView magasságában a rendszer elbontja az egész View struktúrát, tehát írhatom az egyes objektumokat, csak megjelenni nem fog semmi.
Az onCreateView viszont újraindul az életciklus elején, és - normál megoldás esetén - minden View objektumnak újra (new használatakor új) értéket ad.

A lényeg, hogy nem kell külön ellenőrzés, a Fragment View objektumai az első onCreateView után bármikor írhatóak (az UI threadról), bár néha (onDestroyView és onCreateView között pl.) a kiírt érték nem jelenik meg; ill. egy adott View-ra hiavtkozó objektum megváltozhat (az onCreateView ismételt lefutásakor).

Ez némileg egyszerűsítette a kódomat...

Közbe rájöttem, nem az adapterrel volt baj, hanem a layout-ban nem adtam meg fix széllességet a elemeknek.

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."

Kérdés: A FragmentManager-ben tárolt Fragmentek megjelenési sorrendjét miként lehet megváltoztatni?

Issue 31116 problémába futottam bele. A készülék elfordítása után az átfedő Fragmentek nem a megfelelő (eredeti) sorrendben jelennek meg, ezért az utolsó, DialogFragment "alulra", a többiek mögé kerül.

Megpróbálkoztam a getChildFragmentManager() használatával, vagyis a DialogFragment-et is egy Fragment nyitná meg, de ebben az esetben elforgatáskor a DialogFragment - hibaüzenet nélkül - eltűnik. Ettől eltekintve ez működik.

A másik ötletem, hogy minden Fragment-et az Activity kezel, és minden alkalommal újra felépíti a teljes miskulanciát. Ez csak azért rossz, mert eddig mindent meg tudott oldani maga a rendszer, csak az utolsó, Igen/Nem kérdés kezelését nem.

A harmadik - és eddig legjobbnak tűnő módszer -, hogy egy hagyományos Dialog ablakot nyitok meg a Fragment-ből. Kétségtelenül ez a legegyszerűbb. Az elforgatáshoz viszont itt is külön kód kell.

Nem tudtok vmi. ennél egyszerűbb megkerülő módszert erre a hibára? Köszi!

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ó.)

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ó.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

(Zárójelben: a Java a háttérben UTF-16-ot használ a String tárolására, szerintem erre gondolt.)

[ Szerkesztve ]

“All nothings are not equal.”

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?

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.

[ Szerkesztve ]

“All nothings are not equal.”

((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()

“All nothings are not equal.”

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.

“All nothings are not equal.”

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ó...)

[ Szerkesztve ]

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.))

[ Szerkesztve ]

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.

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.

JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...

Az előző hozzászólások alapján megpróbálom átalakítani az egész osztályt stream alapúra. Jelenleg a getChannel.position()-nal küzdök, amit a hozzászólásod alapján találtam lehetséges megoldásnak.

A RAF - C-s hasonlóságok miatt - nagyon szimpatikus volt, és eddig jól is működött. Én ugyan a RAF-ot "byte" alapon használtam - vagyis se nem küldtem, se nem olvastam semmit, ami 255 felett van. A teljes kódolást/dekódolást ebből a kvázi "byte" alapú folyamból végeztem el. Amúgy:
int read()
Reads a single byte from the current position in this file and returns it as an integer in the range from 0 to 255.

Így nem lesz persze hiba, de logikailag valóban helyesebb byte-folyamként fogadni, és a rendszerrel átalakíttatni az UTF8 szöveget. És a RAF másik hátránya: tapasztalom, hogy pufferelt, csak sehol nem látom, hogy mekkora pufferrel, és az hogyan állítható be.

Úgyhogy fájó szívvel búcsút mondok a RAF-nak (és a C-s emlékeknek), és igyekszem Java-style I/O-t használni...

Egy szokatlan témával fordulok hozzátok, esetleg valaki tud olyan megoldást ahol az alkalmazás Safe mode-ban is elinduljon?

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."

A Safe mode lényege az (is), hogy ne indulhasson el third-party alkalmazás, így nemigen hiszem, hogy megvalósítható.

https://heureka-kreativ.hu

valaki esetleg tudna segiteni AdMob ugyben?

Van egy C++ -ban megirt appom, es szeretnem valahogy odabiggyeszteni az AdMob reklamot.
Addig sikerult eljutnom, hogy a fokepernyom helyett egy fekete kepernyot kapok, alul egy pici szurke teglalappal a reklam helyen. Sajna Javaban nagyon gyer vagyok, szoval eleg nehezen haladok.

Eddig ennyim van:

C++:

#ifdef __ANDROID__
#include "jni.h"
#include "android_native_app_glue.h"

void showAds()
{
JNIEnv *env = static_cast<JNIEnv*>(SDL_AndroidGetJNIEnv());
jobject activity = static_cast<jobject>(SDL_AndroidGetActivity());
jclass cls = env->GetObjectClass(activity);
jclass localcls = reinterpret_cast<jclass>(env->NewGlobalRef(cls));
jmethodID showAds = env->GetStaticMethodID(localcls, "showAdPopup", "()V");
env->CallStaticVoidMethod(localcls, showAds);
}

#endif

Java:

// Our popup window, you will call it from your C/C++ code later
public static void showAdPopup()
{
//if(adsinited)
//{
// return;
//}
if(adView!=null) {
_activity.runOnUiThread(new Runnable() {
@Override
public void run() {
adsinited = true;
// Out popup window
popUp = new PopupWindow(_activity);
// This is the minimum size for AdMob, we need to set this in case our target device run at 320x480 resolution (Otherwise no ad will be shown, see the padding kill below)
popUp.setWidth(320);
popUp.setHeight(50);
popUp.setWindowLayoutMode(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT);
popUp.setClippingEnabled(false);
layout = new LinearLayout(_activity);
mainLayout = new LinearLayout(_activity);
// The layout system for the PopupWindow will kill some pixels due to margins/paddings etc… (No way to remove it), so padd it to adjust
layout.setPadding(-5, -5, -5, -5);
MarginLayoutParams params = new MarginLayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT);
params.setMargins(0, 0, 0, 0);
layout.setOrientation(LinearLayout.VERTICAL);
layout.addView(adView, params);
popUp.setContentView(layout);
_activity.setContentView(mainLayout, params);
AdRequest adRequest = new AdRequest();
// Enable this if your are testing AdMob, otherwise you'll risk to be banned!
adRequest.addTestDevice(AdRequest.TEST_EMULATOR);
_activity.adView.loadAd(adRequest);
// Show our popup window
popUp.showAtLocation(mainLayout, Gravity.BOTTOM, 0, 0);
popUp.update();
}});
}
}

Sziasztok!

Az mitől lehet, hogy csak "Run" indításkor jelenik meg a stacktrace a LogCat-ben? "Debug" esetén pedig nem és így nem látom a kivételhez tartozó üzenetet.

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

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.

https://heureka-kreativ.hu

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.

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ő.

https://heureka-kreativ.hu

É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

https://heureka-kreativ.hu

Igen tudom, csak gondoltam hátha van mégis valami elmebeteg megoldás. Bár eddig nem találtam semmit, és úgy hiszem nem is nagyon fogok:S

"Amikor már azt hittem kint vagyok, ezek mindig visszarántottak..."