ROTTWEILER: Psal to Hulán.

SIRLOON: Můžeš to podložit nějakými podklady? Nebo to pouze vychází z toho, že ty a tvůj kamarád jste se na to vykašlali?

REDGUY: To ale není problém Unicode, ani Androidu. IMHO použitý font nejspíš nebude podporovat COMBINING CARON.

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?