Liczniki wydajności w Windows Store Apps

Ostatnio pisałem na temat zdarzenia BindingFailed klasy DebuggerSettings. Jedną z niewielu właściwości tej klasy jest EnableFrameRateCounter.

public App()
{
    InitializeComponent();
    Suspending += OnSuspending;

    DebugSettings.EnableFrameRateCounter = true;
}

Zmiana tej flagi na true sprawia, ze w górnym lewym rogu uruchomionej aplikacji pojawią się liczniki wydajności, które doskonale znają programiści Windows Phone.

 

Znaczenie poszczególnych wartości:

• Cp fps: the frames-per-second frame rate for the composition thread
• UI fps: the frames-per-second frame rate for the UI thread
• Memory: memory utilization for textures
• Batch: the count of surfaces that are sent to the graphics processing unit (GPU)
• Cp cpu: time in milliseconds spent on the composition thread’s processor
• UI cpu: time in milliseconds spent on the UI thread’s processor

Debugowanie BindingExpression w Windows Store Apps

Jedną z zalet XAML’a, DataBinding i MVVM jest to, że grafik i programista mogę swobodnie pracować nad tą samą aplikacją. Miejscem styku są wyrażenia BindingExpression w kodzie XAML. Niestety, czasami styku nie ma, albo wręcz robią się zwarcia i trzeba na to jakoś zareagować.

WP XNA 13: Trial

Windows Phone jako jedyna platforma umożliwia tworzenie aplikacji z tzw. Trial’em. Wiem, ktoś może powiedzieć, że przecież w AppStore czy Android Market też są aplikacje płatne i darmowe. Czym więc różni się Windows Phone? Tym, że możemy stworzyć jedną aplikację, która będzie jednocześnie wersją Trial i pełną, a Windows Phone Marketplace automatycznie zadba o procedurę kupna i podniesienia wersji z darmowej na pełną.

W tym poście opiszę moje podejście do tego tematu. Na koniec opiszę jakiego rodzaju Triale można stosować oraz na co zwrócić uwagę.

Ten wpis jest częścią cyklu o moich przygodach w tworzeniu gier XNA dla Windows Phone.

Wyświetlanie kontrolek XAML’owych tylko w Debug

Podczas działania naszej aplikacji (a będącej jeszcze w fazie dewelopmentu) często zachodzi potrzeba na wyświetlanie dodatkowych informacji. Przykładowo wyświetlamy różnego rodzaju identyfikatory czy kody wczytanych danych aby śledzić czy edytowany rekord jest tym rekordem, o który nam chodzi. W tym celu używamy różnego rodzaju loggerów, tracerów, outputów, a także najnormalniej w świecie wyrzucamy tą zawartość na interfejs użytkownika. Nie uważam, że jest to dobre podejście, ale czasami tak robimy. Gdy już się decydujemy na ten krok, każdy sobie mówi, że będzie pamiętać o tym kawałku kodu i zakomentuje go lub usunie przed releasem. Zamiast tak mówić, lepiej działać i zabezpieczyć się przed późniejszą kompromitacją.

XAML bindings debugging w Silverlight 4

W poprzednim poście opisałem nowość w Silverlight 5 – XAML bindings debugging, czyli debugowanie bindingów prosto w XAML’u.

Programiści już się cieszą i czekają od kwietnia na wersję RTM, a wtedy zmigrują swoje projekty do nowej wersji.

Wcale nie trzeba czekać

Ale okazuje się, że nie trzeba czekać. Już dzisiaj można debugować bindingi w „starych” projektach Silverlight 4!

Silverlight – XAML bindings debugging

Na konferencji Silverlight Firestarter (2 grudnia 2010) ogłoszono, że nadchodzi Silverlight 5, a cztery miesiące później, na konferencji MIX 11, ogłoszono publiczną wersję Silverlight 5 Beta.

Jednym z wyczekiwanych ficzerów jest debugowanie bindingów w XAML‚u. To bardzo przydatny wynalazek.

Ukrywanie składowych klas w debugerze (DebuggerBrowsable)

Możliwości kształtowania wyglądu naszych klas dla łatwiejszego debuggowania są bardzo duże. Poprzednio pokazałem jak można wpływać  na to, co nam wyświetli debugger o naszej klasie (DebuggerDisplay) oraz jak można tworzyć własne wizualizery klas (Debugger Visualizers). Teraz czas na ukrywanie składowych (np. prywatnych) naszej klasy, aby nie zaśmiecać sobie podglądu stanu okiektu podczas sesji „odrobaczania”.

Wizualizacja obiektów w debuggerze (DebuggerVisualizers)

Niedawno oglądałem nagranie z sesji Advanced Debugging with Visual Studio 2010, która prowadził Ingo Rammer. Bardzo fajna sesja, świetnie prowadzona. Pojawiły się na niej ciekawe informacje, które pozwalają ułatwić i urozmaicić sobie sesje w debuggerze Visual Studio. Zainspirowany tematem, postanowiłem na własnej skórze przetestować pokazywane rozwiązania.

Poprzednio pokazywałem jak można manipulować wyświetlaniem informacji o obiektach naszych klas (przeciążanie metody ToString() i/lub użycie atrybutu DebuggerDisplay). Dzisiaj pokażę jak stworzyć własny edytor (visualizer) do edycji obiektów naszych klas podczas debugowania (przykład ten nie był w całości pokazany w sesji Ingo Rammera.

Łatwiejsze debugowanie w .NET (DebuggerDisplay i ToString)

Po staremu

Typowa, prosta klasa Person.  Cztery właściwości i konstruktor.