Odstranění zvýraznění dotyku na odkazech na WP a iOS

Při testování vašich webů na mobilních webových prohlížečích se můžete dovědět, že Windows Phone a iOS automaticky aplikují speciální zvýrazňování ve chvíli, kdy uživatel klepne na jakýkoliv odkaz na stránce – jde o lehké zašednutí celého prostoru na kterém je odkaz zobrazen. Přestože toto chování může být v mnoha případech užitečné, hlavně pro to, aby uživatel věděl na jaký odkaz doopravdy klepnul, v jiných situacích to může být poměrně nežádoucí a nepřívětivé vůči designu stránky.

Jak zvýrazňování zabránit? Pojďme se podívat na řešení pro oba systémy! Pokračovat ve čtení “Odstranění zvýraznění dotyku na odkazech na WP a iOS”

Jak zobrazit více obsahu na Windows 8.1

Nedávno jsem narazil na skvělou funkci nového Windows 8.1 Modern UI, která majitelům notebooků a tabletů s vysokým rozlišením umožní zobrazit mnohem více obsahu (za cenu zmenšení jednotlivých prvků).§

Na Microsoft Surface Pro 2 vypadá obrazovka Start přibližně tak jako na následujícím obrázku – zobrazují se čtyři řádky středně velkých dlaždic nad sebou.

startscreennormal

Ve výchozím nastavení navíc můžeme spustit vedle sebe najednou nejvýše dvě Windows Store aplikace.

Zkusme to vylepšit!  Pokračovat ve čtení “Jak zobrazit více obsahu na Windows 8.1”

ItemsSource a SelectedItem

Poměrně obvyklou chybou při psaní XAMLu (především u mě, já ji doslova nemohu přestat psát) je prohození pořadí dependency properties ItemsSource a SelectedItem u ovládacích prvků pro zobrazení výběrových seznamů.

Ukažme si to v kontextu prvku ListView ve WinRT. Pro binding kolekce k ListView použijeme vlastnost ItemsSourcePro vybrání jednoho z jejích prvků použijeme SelectedItem.

To zní dobře ne? Bohužel.

XAML parser prochází náš ListView v pořadí zleva doprava. Když narazí na SelectedItem, pokusí se vybrat tento prvek v připojené kolekci. Bohužel, ten nelze nalézt a skončí to tak, že je vybraný prvek ListView znovu nastaven na null. Nyní již parser přečte i ItemsSource, ale to už je příliš pozdě na to, aby zachránil situaci.

Jediné správné pořadí, kdy dostaneme opravdu požadované výsledky a zbavíme se často nepochopitelných chyb je zapsáním ItemsSource před SelectedItem.

Zlo se skrývá v detailech.

Nefunkční lokalizace ve WinRT?

Tento týden jsem musel řešit velice záhadné chování při snaze o lokalizaci aplikace pro Windows 8.1.

Jako obvykle jsem si připravil třídu pro lokalizaci, přidal odpovídající soubory *.resw, texty pro lokalizaci v en a cs a nakonec na XAML stránkách stringy přes binding napojil. Vše se zdálo v pořádku až na ten malý detail, že fungovala pouze anglická (neutral) varianta. Situace se ještě více zkomplikovala ve chvíli, kdy jsem vytvořil nový projekt, který se po přesně stejném nastavení choval správně.

Po delším hledání jsem našel nepříliš zřejmou příčinu problému. Soubor Package.appmanifest, který obsahuje různá nastavení chování aplikace v systému obsahuje některá nastavení, která přes vizuální návrhář nejsou dostupná. Soubor AppManifest je totiž ve skutečnosti jen převlečený klasický textový XML dokument, který můžete otevřít ve Visual Studiu kliknutím pravým tlačítkem myši na tento soubor v Solution Exploreru a následně výběrem příikazu Open With… nebo View Code.

Otevření Package.appmanifest v XML editoru

Zdrojem  mých problémů byl jeden z elementů manifestu – konkrétně element Resources. Tento element ovlivňuje chování souborů resource v projektu a především určuje jejich dostupné jazyky.  V mém případě vypadal takto:

Pokud bych chtěl přidat další jazyky, mohl bych zopakovat element Resource s dalšími ISO zkratkami jazyků, které požaduji. Toto však jak jistě uznáte není příliš praktické. Lepší řešení nabízí podoba, která je výchozí po vytvoření nového Windows 8.1 projektu:

Speciální konstanta x-generate určuje, že při sestavování balíčku se automaticky vygenerují příslušné lokalizace na základě toho, jaké budou nalezeny soubory *.resw v projektu.