WAKI: to ne, spis na nej prestali vyvijet. android jako myslenka neni spatna, jen to zpracovani SDK a toolu pro ladeni neni optimalni. Jinak ovce si budou brzo kupovat i WP a BB :)

REDGUY: Já v tom nevidím problém. Xml hlavička definuje kódování (vícebajtové kódování se zjistí jednoduchým přečtením prvních pár znaků, také se případně využívá Content-type z HTTP hlavičky) a u JSON se všechny speciální znaky nad 0x7F escapují přes Unicode zápis \uXXXX.

FUCK FUCK FUCK FUCK FUCKING FUCK.

Zkurveny Unicode mi sezralo tri hodin zivota.

Zasranej debilni kram.

Aaaanway, aspon se pochlubim.

Androidi verze aplikace, kterou prave pisu, pouziva data z iOSovy verze. Tam jsou vpodstate v XML. Parsovat XML je voser (a XPath je pomalej jak ... hmm, neco hrozne pomalyho), takze je nejdriv prekonvertuju do JSON a ten teprv nahravam.

Jenze to fungovalo jen trochu. Diakritika tam byla, ale tu a tam chybela, nekde byly extra mezery, nekde hacek o fous posunutej, proste to bylo blbe.

Tri posrany hodiny jsem hledal kde je problem. V konvertovacim programu, v kodovani streamu, v JSON dekoderu, ve fontu co pouziva TextView... nic.

A pak jsem si nastesti vzpomel, ze utf-8 neni uplne jednoznacny kodovani, ve smyslu ze stejnej logickej text jde zakodovat vice posloupnostma bajtu. Chvile googleni, nalezeni perlovyho modulo Unicode::Normalize, prohnat skrz nej ten json a pak pokus omyl. Na prvni pokus jsem zjistil, ze "Normalization Form D" nefunguje, resp. dava stejny vysledky jako predtim. A na druhej pokus jsem zjistil, ze "Normalization Form C" funguje jako kouzlo.

Cili proste existuje urcitej dialekt utf-8, kterej iOS zkousne, ale Android je z nej vedle sebe 8(

Kdybyste nekdy narazili na neco podobneho, tak mantra je "use Unicode::Normalize; print NFC(...whatever...);".

Zasranej Jan Hus a vsechny jeho pojebany nabodenicka. A to jsem si myslel, ze s utf-8 je problemum s cestinou konec.

tak jsme zjistili, že ten JPEG nesmí být progressive, kdyby někdo taky řešil... potřeba přeuložit jinak

ZACK: pri loadovani. posilam do posty tedy. zbezne jsem na ne koukal v Gimpu, nic zvlastniho jsem tam nevidel, ale prd tem formatum rozumim. dik.

GORG: Nebo mi hod jeden ten obrazek do posty, to zkusim naloadovat do neceho svyho.

GORG: A na cem to pada? Na loadovani nebo zobrazeni?

Setkali jste se s problémem u některých JPEG obrázků? Běžně jich používám celou řadu, ale teď jsou tam dva, které padají při načtení (používám libgdx, tak přímo nevidím žádnou konkrétní chybovou hlášku než "Couldnt load dependencies of asset.. nazev souboru", spíš by mě zajímalo, co na takovém JPEG by mohlo být špatně. Oproti těm, co fungují, mají tyhle dva shodné rozměry (128x128), bar. hloubku 24bit stejně jako obrázky, které fungují. Grafik, co mi je dodal, je pravděpodobně vytvořil i stejným způsobem, tak by se ani hlavička neměla zvlášť lišit co do standartu?

no vsechno fungovalo super az prave do update s jellybean. Tudiz ten update tam neco zkazil. Drivery jsem si stahnul nejnovejsi.

THE_SON_OF_MAN: Jestli jim tvuj telefon v obchode funguje,tak mas asi neco s driverama v PC nebo neco takoveho? Nejake odinstalovani,nainstalovani apod. asi muze pomoct

ARCAO: Hmmmm... to by davalo smysl, az na to, ze obrazky ktery nahradej ten placeholder obrazek mi takhle neleakujou. Znamena to, ze kdyz je ImageView soucasti Activity, tak v ramci jeji likvidace se nekde v nejakem "systemovem" onDestroy() standardne vola to .recycle() (cili to udela Android za me), zatimco kdyz ten ImageView neni soucast aktivity, tak se pochopitelne nezavola a musim to udelat sam?

VIRTUALVOID: Tady jde o to, že mu zůstává alokovaná paměť, kterou nemá pod palce Javový GC, takže WeakReference nepomůže.

REDGUY: Udělej si heap dumpy a zanalyzuj si to v memory analyzeru, určitě nakonec zjistíš, že se ten ďábel skrývá v nějakým detailu, kvůli kterýmu se ta activity neodstraní z paměti.
Memory Analysis for Android Applications | Android Developers Blog
http://android-developers.blogspot.cz/2011/03/memory-analysis-for-android.html

pozeram, ze weakreference by mu asi nepomohol... ci ?

Hmmmm... jsem blbej ja nebo Android?

Mam jednoduchou aplikaci s Master aktivitou, ktera skrz ListFragment ukazuje seznam veci a Detail aktivitou, ktera ukazuje detaily od veci. Detail je blbej formular, s velkym (640x960) obrazkem na pozadi, jednim mensim obrazkem na popredi (300x300) a dvema textama.

Kdyz jsem si delal xml layout pro ten Detail, tak jsem do <RelativeLayout background=...> a <ImageView src=...> dal jmena existujicich resourcu, abych v editoru videl jak to vypada. Pri behu aplikace jsou tam zcela zbytecny, protoze v OnCreate se okamzite pomoci setImageResource prepisou na resourcy odpovidajici veci co se prave zobrazuje.

No... a kdyz jsem to spustil v emulatoru (kterej mam zhruba bajvoko nastavenej na Nexus S), tak to po trech, ctyrech cyklech Master -> Detail a zpet spadlo na out of memory.

Chvili jsem na to koukal jak puk ("Mam GC, bitch, jaktoze out of memory!" 8) ) a pak jsem vyhodil ty placeholder obrazky z xml layoutu. A padat to prestalo. Kdyz jsem koukal na "nastroje" kterejma se v Androidu hledaji memory leaky, dostal jsem vyrazku, takze jsem to moc dal neresil, ale jsem krapet nervozni.

Cili, otazka: je opravdu mozny, ze obrazek, kterej je (jako resource) referencovanej z ImageView v xml layoutu a kterej okamzite nahradim pres setImageResource jinym resourcem, zustane nekde viset referencovanej a GC ho neuklidi? A je to moje chyba, protoze je to nekde zdokumentovany a mel jsem to vedet, nebo buga?

Podotykam ze ty Detail activity v kazdym cyklu hezky sporadane dosly az do onDestroy, takze by po nich nic zustat teoreticky nemelo.

Ahoj mam dotaz, aktualizoval jsem na JB na xperii p. Obcas se mi stane, ze pri hovoru uplne vypadne reproduktor, coz je dost neprijemne, kdyz zrovna volate se sefem... Nevi nekdo co s tim?

kluci, keby ste si nestihli vsimnut, vysiel nyxdroid v2 !