Ostatnie lata w świecie developmentu, to ogromny rozwój technologii frontendowych oraz dynamiczny rozwój sektora mobilnego, w którym wciąż jeszcze liczą się trzy systemy. No dobra - tak naprawdę to Windows Phone, tudzież Windows Mobile, trochę juz dogorywa. Świat WWW ma swoje problemy, a jednym z największych jest oczywiście wsparcie dla różnych przeglądarek. W świecie mobile, mamy za to zgoła inną sytuację. Z grubsza możemy spodziewać się wynikowego efektu na różnych urządzeniach z jednym systemem (chociaż w Androidzie to w sumie bywa różnie), ale problem stanowi fakt, że oprogramować musimy 2-3 różne platformy, które w standardzie wymagają innych języków programowania.

Na szczęście istnieją rozwiązania, które są w stanie ten problem zminimalizować, a jednym z nich jest Xamarin, który pozwala na jednoczesne pisanie aplikacji na Androida, iOS, Mac OS, Windows, Windows Mobile za pomocą C#. Dotychczas to rozwiązanie miało jednak pewną, dość istotną wadę - spory koszt licencji, ale wydaje mi się, że już wkrótce może to ulec drastycznej zmianie dzięki wydarzeniu, które miało miejsce w tym tygodniu.

Ostatnio przy jednym z projektów służbowych, musiałem zrobić layout, który obejmowałby zagnieżdżanie kontrolek ListView. Poziomy scroll przesuwał elementy głównej listy, natomiast w każdym takim obiekcie, znajdował się panel zawierający pewne określone dane + kolejny ListView przesuwany już wertykalnie. Nie byłoby w tym nic nadzwyczajnego, gdyby nie fakt, że wewnętrzne kontrolki ListView, zawierały w sobie listę elementów na których znaleźć można było kontrolki użytkownika. Szybko okazało się, że to był błąd, bo w praktyce takie kontrolki w dużej ilości są strasznie nie wydajne, nawet przy zastosowanej wirtualizacji.

Na szczęście w porę przypomniałem sobie o innym rodzaju kontrolek, który pozwolił mi zaoszczędzić nawet kilkadziesiąt megabajtów pamięci i znacznie przyspieszył ładowanie widoku:-)

Niektóre kontrolki z których korzystamy w Windows Phone, przygotowane są do pracy w różnych orientacjach. Możemy je używać zarówno w pionie jak i w poziomie. W niektórych przypadkach, wystarczy przestawić jedną właściwość. Z taką sytuacją mamy do czynienia np. w StackPanelu. Inne są nieco bardziej złożone, co nie oznacza, że ich konfiguracja jest jakoś wielce karkołomna. Taką właśnie sytuację mamy w przypadku kontrolki ListView, która domyślnie działa również wertykalnie.

Dwa tygodnie temu popełniłem wpis na temat lokalnych notyfikacji, które z powodzeniem bez większych przeszkód można użyć w każdej aplikacji uniwersalnej. Dziś chciałbym pozostać w temacie notyfikacji, aczkolwiek tym razem podejdziemy do sprawy trochę bardziej globalnie - zajmiemy się tzw. notyfikacjami push.

Idea tego rodzaju notyfikacji jest prostsza niż się to powszechnie zdaje, a kluczem do sukcesu w naszym przypadku będzie usługa WNS oraz testowy serwis do wysyłania pushy. Oczywiście wysyłka notyfikacji docelowo powinna zostać zrealizowana w jakiejś usłudze backendowej, ale to już temat na inny wpis;-)

Notyfikacje są obecnie czymś powszechnym w każdym liczącym się mobilnym systemie. Dzięki nim, jesteśmy na bieżąco z mailami, powiadomieniami z Facebooka, czy choćby z wynikiem wyczekiwanego meczu. Windows Phone nie odstaje niczym w tym obszarze od swojej konkurencji, a nawet oferuje kilka dodatkowych, ciekawych opcji.

W dzisiejszym tekście przedstawię przykładowe użycie lokalnych notyfikacji typu toast - zarówno w wersji harmonogramowanej (scheduled) jak i normalnej. Notyfikacje innego typu wysyła się w zbliżony sposób - zmieniamy rodzaj używanych klas oraz XMLa.

W swojej stosunkowo krótkiej karierze programistycznej, zdążyłem już pracować z różnymi technologiami. Naturalnym tego następstwem są oczywiście wszelkiej maści porównania. Czasem np. porównuje Razora z MVC do XAMLa. I choć w teorii bardziej rozbudowana jest ta druga z obu tych technologii, to w praktyce Razor ma kilka konstrukcji, do których tęsknym okiem wyglądają designerzy XAMLa. Jedną z nich jest IF. I choć w teorii można ją częściowo zastąpić choćby za pomocą VisualStates, to w praktyce okazuje się, że istniejące rozwiązania, nie zawsze są do końca optymalne, ale od czego są dodatkowe biblioteki;-) Powitajcie Conditional XAML - prostą bibliotekę, która skrywa olbrzymie możliwości.

Czasem tworząc aplikację wykorzystującą XAML, chcielibyśmy przekazywać dane pomiędzy poszczególnymi stronami. Niestety technologie Microsoftu nie są do tego dobrze przygotowane. Co prawda możemy zawsze wykorzystać jakiś globalny obiekt kontekstu, ale w praktyce jest to rozwiązanie nieefektywne. Możemy również wykorzystać foldery lokalne/roaming, który opisywałem tutaj, ale w pewnym sensie strzelamy tutaj do muchy z armaty. Czy można to zrobić jakoś prosto i elegancko? Okazuje się, że tak - choć po części zależy to od używanych przez Was bibliotek.

Jakiś czas temu opisywałem na łamach tego blogu MVVM Light, która upraszcza wdrożenie modelu MVVM w wielu technologiach Microsoftu, a oprócz tego skrywa w sobie kilka fajnych funkcji. Dziś chciałbym opisać jedną z nich - Messengera, który może być swego rodzaju mostkiem informacyjnymi pomiędzy ViewModelami umieszczonymi w naszej aplikacji.

Domyślnie tworząc aplikacje uniwersalne, możemy korzystać z rozbudowanego modelu zdarzeń. Każde ze zdarzeń, może zostać zaimplementowane w tzw. części code-behind wybranej strony/kontrolki. Nie wszystkim do końca odpowiada jednak ten model. Spore grono programistów jest zwolennikiem architektury MVVM, która promuje wydzielone konstrukcje zwane ViewModelami. Ważnym elementem ViewModel są komendy, które pozwalają na realizację określonych zadań. Niestety nie wszystkie kontrolki Microsoftu są do tego dobrze przygotowane. Czy można sobie z tym jakoś poradzić?

Częściowo tak. Po pierwsze, można wykorzystać Behaviors SDK (więcej na ten temat pisałem tutaj). Jeśli to rozwiązanie nie zadziała, można skorzystać z innych metod alternatywnych - np. z Attached properties. I to właśnie ten sposób mam zamiar Wam dzisiaj zaprezentować.

W chwili obecnej tworząc aplikacje mobilne, bardzo często korzystamy z Internetu, o czym wspominałem po części w ostatnim wpisie. Siłą rzeczy w chmurze często trzymamy też konfigurację aplikacji/usługi, aczkolwiek nie musi to być regułą. Aplikacje uniwersalne obsługują bowiem tzw kontenery danych (ApplicationDataContainer), które pozwalają na zapisywanie ustawień dla konkretnej instalacji, a także globalnie dla naszego konta Windows Live. W dzisiejszym wpisie, zaprezentuję prosty sposób na wykorzystanie tych mechanizmów w praktyce.

Większość mobilnych aplikacji wymaga aktywnego połączenia internetowego do poprawnego działania. Wiele z nich, nie posiada nawet trybu offline i bez sieci po prostu nie jest w stanie funkcjonować. Często developer musi również reagować na rodzaj połączenia sieciowego, z którego aktualnie korzysta użytkownik (WiFi/GSM), dlatego temat ten jest naprawdę ważny z perspektywy całego projektu aplikacji.

Na szczęście wszystkie opisane wyżej zagadnienia można łatwo oprogramować w aplikacjach uniwersalnych - wystarczy tylko skorzystać z klasy NetworkInformation, której przykładowe użycie zaprezentuję w dzisiejszym tekście:-)