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.

Język znaczników XAML, jest integralnym elementem kilku ważnych technologii Microsoftu. Pojawia się on: w sukcesywnie upadającym Silverlighcie, WPFie, Windows Phonie, czy też w aplikacjach uniwersalnych. Dlatego też jeśli poznacie jedno z wymienionych wyżej środowisk, to bardzo łatwo będzie się Wam przestawić na dowolną z pozostałych technologi.

W zależności od środowiska, mogą pojawiać się pewne delikatne różnice w możliwościach jakie dostarczy nam XAML, ale mimo wszystko jest naprawdę sporo rzeczy wspólnych - ot choćby podstawowe kontrolki.

Jedną z takich kontrolek jest pozornie prosty TextBlock, który w praktyce skrywa w sobie spore możliwości. Jakie? Na te pytanie postaram się odpowiedzieć trochę szerzej w dalszej części tekstu;-)

W architekturze WinRT możemy korzystać z dwóch bardzo przyjemnych kontrolek do prezentacji danych - ListView oraz GridView. Obie te kontrolki mają duże możliwości konfiguracyjne, posiadają sporo zdarzeń i można je również fajnie ostylować. Jednym słowem jest naprawdę dobrze;-)

Naszą piękną, idealistyczną sielankę może jednak w łatwy sposób zakłócić, pewien dość prozaiczny problem, który nazywa się nadmiar danych. Tego rodzaju sytuacja zasadniczo nie ma żadnych pozytywów. Nasza aplikacja pochłonie duże ilości pamięci, może zacząć się zacinać, a dodatkowo jeśli dane pochodzą z zewnątrz, niepotrzebnie pobierzemy dane, które być może nigdy nie zostaną wyświetlone...

W praktyce okazuje się, że można jednak łatwo wybrnąć z tej sytuacji - wystarczy bowiem w zbindowanej kolekcji zaimplementować interfejs ISupportIncrementalLoading i życie znów stanie się piękne;-)

Rynek aplikacji mobilnych rozwija się niezwykle dynamicznie w ostatnich latach. Programy na telefony dotykają dzisiaj naprawdę wielu ważnych i istotnych obszarów naszego codziennego życia. Coraz częściej tego rodzaju aplikacje funkcjonują w chmurze, dzięki czemu mamy łatwy dostęp do wszystkich niezbędnych nam informacji, niezależnie od tego gdzie jesteśmy i z jakiego urządzenia aktualnie korzystamy.

Wykorzystanie chmury wiąże się najczęściej z użyciem odpowiedniego API, do którego podłączają się wszystkie aplikacje klienckie. W wielu przypadkach programy mobilne muszą wysyłać kilka różnych żądań na raz. Oczywiście w .Net mamy odpowiednie klasy do obsługi komunikacji sieciowej. Jedną z takich konstrukcji jest klasa HttpClient umieszczona w przestrzeni System.Net.Http. HttpClient działa naprawdę bardzo sprawnie, aczkolwiek jest jeden mały problem z tą konstrukcją - trzeba napisać trochę dodatkowego kodu, który pozwoli na równoległe wykonywanie wielu różnych żądań. Na szczęście nie jest to trudne i postaram się tego dowieźć w niniejszym tekście.

XAML - czyli tzw. rozszerzalny język znaczników, jest motorem napędowym wielu technologi stworzonych przez Microsoft. Spotkać go można m.in. w Silverlighcie, WPFie, czy też katowanych ostatnio przeze mnie na blogu aplikacjach uniwersalnych. I choć między tymi technologiami jest sporo istotnych różnic, to w praktyce są one częściowo ze sobą zbieżne właśnie dzięki XAMLowi.

Tworząc frontend w WPF, można bardzo szybko złapać o co chodzi w aplikacjach uniwersalnych - i vice versa. Oczywiście poszczególne kontrolki mogą się różnić pomiędzy konkretnymi implementacjami, ale jest też kilka takich elementów, które albo są takie same, albo zachowują się bardzo podobnie. Do tej właśnie grupy można zaliczyć tytułowego GRIDa, który w praktyce jest moim ulubionym kontenerem do budowania efektywnych layoutów. W dzisiejszym tekście postaram się Wam przedstawić kluczowe jego elementy, które można wykorzystać w codziennej pracy.

Ostatnio w pracy miałem do rozwikłania pewien banalny problem (przynajmniej tak mi się pierwotnie wydawało). Moim zadaniem było znalezienie programowego rozwiązania, które w sposób jednoznaczny pozwoli zidentyfikować smartfon z systemem Windows Phone. Aplikacja wykorzystywała architekturę WinRT (Universal Apps).

Na potencjalne rozwiązanie wpadłem stosunkowo szybko. Postanowiłem skorzystać z adresu MAC (odbiornik WiFi/moduł GSM). I wszystko byłoby w porządku, gdyby nie fakt, że nie można tego adresu w żaden normalny sposób wyciągnąć za pomocą kodu.. Musiałem więc poszukać innego rozwiązania. Na szczęście się udało, a wszystko to dzięki klasie HardwareIdentification.

W ostatnim czasie otworzyłem mały cykl wpisów na temat Universal Apps, ponieważ jest to obecnie dość bliski mi zawodowo temat. Sama koncepcja tego rozwiązania, wydaje się być odważna, ale wygląda jednak na to, że ktoś to w Microsofcie całkiem sprytnie to przemyślał. Oczywiście kilka elementów jeszcze tutaj kuleje, ale w tej chwili projekty Universal Apps przypominają trochę tworzenie stron responsywnych. Mamy jednolity backend i tak naprawdę zmienia się głównie frontend (XAML), choć w tym akurat przypadku programiści XAMLa mają trochę lepiej niż frontendowcy;-)

Dlaczego o tym wszystkim znów piszę? A no dlatego, że tym właśnie wpisem chciałbym usystematyzować wiedzę co, gdzie i jak współdzielić w projektach Universal Apps.

W ostatnim czasie mocno wchodzę w temat Universal Apps, ponieważ jest to obszar w który w najbliższej przyszłości będę się angażować zawodowo, a jeśli czas pozwoli być może również i prywatnie. Dotychczas popełniłem dwa teksty na ten temat. Jeśli nie czytaliście ich wcześniej, to polecam lekturę rozpocząć od tego pierwszego, który omawia w sposób ogólny koncepcję aplikacji uniwersalnych dla Windows.

Ponieważ dotychczas więcej było teorii, dziś skupimy się na praktyce i zbudujemy naszą pierwszą aplikację. I bynajmniej nie będzie ona wyświetlała tylko i wyłącznie napisu Hello World;-)

Aplikacje uniwersalne przyniosły sporo zmian w procesie tworzenia oprogramowania na systemy Microsoftu. Oprócz zupełnie odmienionej koncepcji budowy aplikacji (uwspólnienie architektury dla różnych platform), mamy tutaj również sporo niuansów, które dzieją się niejako za kulisami. Zmiany tego rodzaju dotknęły bardzo wielu obszarów i pewnie gdybym napisał po zdaniu na temat każdej z nich, mógłbym tutaj stworzyć niezły elaborat. Nie w tym jednak rzecz.

Dziś chciałbym skupić się na jednym konkretnym temacie, a mianowicie na starych, poczciwych plikach zasobów resx, które w aplikacjach uniwersalnych stały się passé;-)

Microsoft przespał czas w którym rodziły się nowe mobilne OSy. W momencie gdy powstawał Android oraz iOS, w ofercie giganta z Redmond dostępny był przestarzały i odrobinę toporny Windows Mobile. Microsoft zauważył że zbyt wiele tym OSem nie ugra, więc stworzył Windows Phone, który miał być swego rodzaju sukcesorem wcześniejszej platformy. W międzyczasie pojawił się również kontrowersyjny Windows 8, który wprowadził interfejs Modern UI. W krótkim więc czasie powstało kilka nowych, niekompatybilnych ze sobą platform, które mimo wielu podobieństw wymagały jednak innego podejścia. Sukcesu zabrakło w obu przypadkach.

Windows instalowany jest na większości nowych komputerów, ale nowy interfejs spotkał się raczej z delikatnie mówiąc chłodnym przyjęciem. Windows Phone przez długi czas zwiększał swoje udziały w rynku, ale robił to w zaiste żółwim tempie. Czy zatem nowa koncepcja budowy uniwersalnych aplikacji dla obu ekosystemów, odwróci złą passę Microsoftu?