Kontrola režimu náhledu v Xamarin.Forms

Visual Studio pro Windows a Mac nyní obsahuje Xamarin XAML Previewer, který nám umožňuje zobrazit náhled vašich Xamarin.Forms XAML souborů bez nutnosti spuštění aplikace. Bohužel v některých případech může obsahovat konstruktor vašich stránek kód, se kterým si Previewer nedokáže poradit (například service resolution, apod.) a spadne. Můžeme snadno ověřit zda aplikace běží v režimu náhledu (design mode)?

XAML Previewer
XAML Previewer

Pokračovat ve čtení “Kontrola režimu náhledu v Xamarin.Forms”

Checking for design mode in Xamarin.Forms

Visual Studio for Windows and Mac now includes Xamarin XAML Previewer, which allows you to preview your Xamarin.Forms XAML without having to launch the app. Unfortunately, there are times when your page constructor contains code that cannot be run in design mode (for example service resolution, etc.) and causes the previewer to crash. Can we easily check if the app is in preview (design) mode?

XAML Previewer
XAML Previewer

Pokračovat ve čtení “Checking for design mode in Xamarin.Forms”

Úprava viditelnosti pojmenovaných XAML elementů

Atribut x:Name v XAMLu vytváří pro elementy členské položky třídy, které lze použít pro přístup k ovladacím prvkům z kódu. Narozdíl od WPF však v UWP jsou tyto položky třídy definovány jako private, což znamená, že k nim je možné přistupovat pouze z třídy samotné. Pokud vezmeme v potaz, že z hlediska architektury by to byl špatný nápad, je možné toto chování změnit? Pokračovat ve čtení “Úprava viditelnosti pojmenovaných XAML elementů”

Modifying XAML named field visibility

The x:Name attribute in XAML creates named fields that you can use to access the controls from the code-behind. However, as opposed to WPF, in UWP these fields are private which means you can access them from the code-behind only, not from other classes. While noting it is a good idea from architectural standpoint, is it possible to change this behavior? Pokračovat ve čtení “Modifying XAML named field visibility”

Rychlý tip: Vždy implementujte všechny VisualStates!

Při vývoji UWP aplikace jsem narazil na zajímavou zvláštnost.

XAML VisualStates definují vzhled ovladacích prvků v různých stavech. Přestože obvykle nemusíte rozlišovat všechny z nich, vyplatí se je přesto implementovat (i když jde jen o copy-paste nějakého jiného stavu) nebo narazíte na těžko vysvětlitelné problémy.

V mém případě jsem upravoval vzhled ListViewItem a zapomněl jsem zahrnout implementaci pro stavy PointerOverSelected a PressedSelected. Překvapivě na mém zařízení vše fungovalo jak mělo a použil se jako fallback vzhled stavu Selected. Později jsem však zjistil, že na zařízeních s jinou verzí systému zůstávaly položky seznamu ve stavu PointerOver dokud je neopustil kurzor myši (a i tento přístup dává smysl).

Rozdílné chování mezi verzemi systému je obzvláště zajímavé, protože “problém” se původně neprojevoval ve stabilních buildech Windows 10 Creators Update, ale nyní se zde projevuje také (pravděpodobně vlivem aktualizací).

Quick tip: Always implement all VisualStates!

I have come across an interesting oddity while building a UWP app.

XAML VisualStates define the visual look of control in different states. Even though you sometimes don’t need to make distinction for all of them, you should still implement them however (even if they are just a simple copy-paste of another style) or you might meet some inexplicable problems.

In my case I have customized the ListViewItem  style and forgot to include implementations for the PointerOverSelected  and PressedSelected  states. Surprisingly everything worked as expected on my devices, as the visual used the Selected  state as fallback. However, I have later found out the same did not happen on other devices and the list view items stayed in the PointerOver state until the mouse cursor moved away (which also makes sense).

This difference in behavior is especially interesting, as the problem did not originally occur on the stable builds of Windows 10 Creators Update, but now it seems to occur as well (maybe after some patches?).