Načítání map

[tprochazka]

Chtěl jsem se zeptat, nešlo by upravit načítání mapových dlaždic tak, aby se jako první načítala středová (ta pod kurzorem) a pak teprve postupně ty kolem? Teď se začne načítáním někde mimo mapu a v místech, kde není ani 3G síť, je nutné čekat velmi dlouho než se zobrazí to, co mě opravdu zajímá :-(

Pak jsem ještě v poslední verzi objevil maličkou chybičku. Pokud je otevřeno dialogové okno s výběrem vrstev WMS mapy a otočím displejem, což je nutné, protože některé názvy se v portraitu nezobrazí celé, tak se dialogové okno zavře a já ztratím nascrollování.

[Menion]

akorát jsem to opravil do poslední verze 1.10.0 co je od včerejška na marketu

ad 2. ... s tím toho teď moc nesvedu ... zkusím na to kouknout

[tprochazka]

Díky za odpověď, ale jsem zmaten. Takže načítání středové dlaždice jako první je opraveno a neotevření dialogového okna s WMS vrstvami map je problém? Čekal bych to spíše naopak :-) Nicméně jak to teď zkouším, zdá se že se fakt načítá středová dříve...

A chci ještě zeptat, proč někdy trvá změna mapy tak dlouho, jindy je hned. Někdy i 10s.

A ještě jeden dotaz, neuvažuješ o přesunu datových souborů na SD kartě do složky kam patří, tedy do sdcard/Android/data/<package>/, minimálně u cache souborů a do složky Locus samotné automaticky přidat prázdný .nomedia soubor aby nedocházelo k jejímu indexování.

Bohužel to není jen Locus, mám na SD kartě desítky složek fungujících jako cache některé aplikaci, kterou třeba už ani nemám jen proto, že to autoři nedávají na správné místo a pak se to nesmaže společně s aplikací :-(

[Menion]

no s dialogy je obecně docela problém - s tou rotací to prostě docela zlobí a stále jsem nepřišel na ěnjaké jednoduché funkční a elegantní řešení.

přesun souborů ... o tom jsem neuvažoval. K tomu myslím ani není důvod. Takhle máš komplet vše co k locusu patří, v adresáři Locus. A .nomedia ... do cache adresářů s ikonami by to asi šlo, máš recht ...

[tprochazka]

Já jsem tedy s dialogovým oknem při rotaci zatím nikdy nenarazil na žádný problém. Android si při rotaci sám zapamtuje které ID okna bylo otevřeno a znova zavolá onCreateDialog() se stejným ID takže se po rotaci otevře opět znovu. V pozdějí API verzi, myslím že od 9 je možné předat i Parcelable bundle, který se rovněž uloží při rotaci a předá znovu, ale to je možné řešit ruční persistencí na úrovni aktivity.

No, důvod k tomu je hlavně takový, že to porušuje oficiálně doporučenou cestu pro ukládání dat aplikací (http://developer.android.com/guide/topi ... esExternal), dělá to bordel na na SD kartě a hlavně komplikuje zálohu a čištění cache. Chápu, že pro uživatelem vytvářené soubory je možná někdy vhodné aby byly přímo ve složce Locus na sd kartě. Ale cache soubory a vše ostatní, co si vytvoří sama aplikace by mělo být na standardní doporučené cestě. Například se pak dá přímo přes správu aplikací smazat cache a ušetřit tak místo na SD kartě a hlavně se vše co aplikace vytvořila smaže samo při jejím odinstalování. Ale chápu, že je komplikace toto měnit u již zaběhlé aplikace.

[Menion]

jo ta tvoje práce s dialogy funguje pokud voláš dialog přes onCreate nebo víš přesně aktivitu na které se dialog zobrazí. Jenže moje dialogy jsou většinou dělané obecně a můžou být zavolané přes nějaké statické funkce takže nikdy pořádně nevím na jaké aktivitě jsou volané a rozhodně je nevytvářím přes onCreateDialog ...

s tou keší. Podívám se co nám píšou ale moc bych s tím nepočítal. Do keše se ukládá docela dost věcí a rád bych to měl tak nějak pohromadě (například klidně celé 1GB při stahování map do TAR formátu, ikony, zvuky atd ...)

[tprochazka]

Cokoliv statického je zlo :-)

Dříve jsem to řešil tak, že jsem měl jednu statickou třídu, která poskytovala statické metody stejně jako to děláš ty. Ale vždy v OnCreate každé aktivity jsme ji předal referenci právě běžící aktivity.

Teď to řeším přes service locator, tedy zavolám

Code Select Expand

profileService = DI.get(this, Profile.class);, kde this je kontext právě běžící aktivity a Profile.class je třída jejíž služby chci využívat, vnitřně se pak intsnace této třídy vytvoří nebo vytáhne z poolu, popřípadě se zabije pokud je nedostatek paměti. To má smysl pokud chci z více aktivit používat něco složitějšího a nechci to vytvářet pořád znovu.

dialogy zásadně řeším přes standardní metody jako onCreateDialog, i když to vypadá třeba takto:

Code Select Expand

@Override
 protected Dialog onCreateDialog(int id) {
  DI.get(this, DialogHandler.class).handle(id);
 }

Ještě zjednodušit to lze přes potomka Activity, který tyhle udělá za mě a já se tak zcela zbavím nutnosti řešit dialogová okna na úrovní aktivit a zároveň si tím zachovám automatickou perzistenci otevřených oken při rotaci.

Čímž samozřejmě netvrdím, že je to nejlepší možné nebo jediné řešení.