ListView to jedna z najważniejszych kontrolek w Xamarin.Forms. Jak sama jej nazwa wskazuje, jest ona odpowiedzialna za ogarnięcie tematu listy. Listy można spotkać w praktycznie każdej aplikacji, począwszy choćby od najprostszych programów typu TODO poprzez rozbudowane aplikacje wyświetlające video, obsługujące naszą pocztę, czy dbające o temat komunikacji.

Kontrolka którą dostarcza Xamarin.Forms, posiada wiele przydatnych elementów (temat na inny wpis to historia jak w praktyce działa ta kontrolka, a warto dodać że wymaga ona sporej dawki cierpliwości od programisty..), a jedną z nich jest możliwość ustawienia szablonu elementu wyświetlanego na liście.

Domyślnie na ListView, możemy wyświetlać elementy tylko w jednym layoucie, który oczywiście można modyfikować odpowiednimi wartościami modelu i dobrze napisanym XAMLem. W praktyce jednak, nie zawsze jest to najlepsze rozwiązanie. Dużo lepszą opcją będzie zastosowanie klasy DataTemplateSelector, która na podstawie właściwości zawartych w modelu, jest w stanie dostarczyć odpowiedni układ, dopasowany do aktualnych danych.

W poprzednich wpisach sporo pisałem o różnych sposobach obsługi poszczególnych systemów wspieranych przez aplikację. Odradzałem wykorzystywanie projektów typu Shared, zachęcałem zaś do bibliotek portable.

Rozwiązanie w wariancie portable niesie swoje ograniczenia, ale tak na dobrą sprawę wymusza na programiście bardziej przemyślane podejście i zwiększa przejrzystość tworzonego kodu. Okazuje się jednak, że nawet w takiej sytuacji, można skorzystać z pewnych specjalnych rozwiązań przygotowanych przez twórców Xamarina. Konkretniej chodzi o klasę Device, która wystawia dwie istotne właściwości oraz udostępnia kilka przydatnych metod, które pozwalają na uruchamianie kodu specyficznego dla poszczególnych systemów.

Kilka tygodni temu na łamach bloga, opisywałem CustomRenderery. Rozwiązanie daje to ogromne możliwości i pozwala na zapewnienie stricte natywnych wrażeń w sytuacji gdy korzystamy z Xamarin.Forms i nie wystarczają nam standardowo dostępne kontrolki i właściwości. Wykorzystując CustomRenderery, możemy w miejsce wskazanej kontrolki (czyli dowolnego elementu, który w Xamarin dziedziczy z View) wstawić natywną implementację dla wybranego, bądź też dla wszystkich obsługiwanych systemów. Jest to bardzo kompleksowe rozwiązanie, które czasem może jednak przytłaczać mnogością dostępnych opcji. Na szczęście Xamarin zapewnia również inne narzędzia.

Jednym z nich są tytułowe efekty, które możemy aplikować do kontrolek. I choć podejście to pozwala częściowo uzyskać podobne efekty jak CustomRenderery, w praktyce funkcjonuje w zgoła innych realiach.

Mechanizm DependencyService zaprezentowany w poprzednim wpisie, daje sporo możliwości już na starcie pracy z Xamarin.Forms. Dzięki zastosowaniu specjalnego atrybutu, możemy korzystać z funkcjonalności opisanych w paradygmacie IoC praktycznie bez żadnego wysiłku i mamy ten mechanizm dostępny out-of-the-box.

Prostota rozwiązania niesie za sobą też pewne skutki uboczne. Mechanizm jest niezwykle łatwy w użyciu, ale zarazem bardzo ograniczony funkcjonalnie. Jeśli kiedykolwiek pracowaliście z kontenerami IoC typu Autofac, czy Ninject, to szybko przekonacie się, że DependencyService tak naprawdę oferuje nie wiele.

Nie możemy w prosty sposób określić czy usługa ma być rejestrowana jako pojedyncza instancja, na żądanie, czy może też ma zawsze zwracać ten sam obiekt w określonym obszarze aplikacji. Nie mówię już tutaj również o bardziej złożonych operacjach, typu rejestracja usługi ze zdefiniowanymi wartościami parametrów itp. itd.

Czy zatem warto korzystać ze standardowego rozwiązania? Być może w prostych aplikacjach może i tak, ale ogólnie zachęcam do wyboru bardziej zaawansowanych bibliotek. Na szczęście takowe można bardzo łatwo podpiąć do Xamarin.Forms:-)

Xamarin.Forms to rozwiązanie multiplatformowe, dlatego też musi ono posiadać narzędzia, które ułatwiają development na kilka różnych systemów jednocześnie. We wcześniejszych tekstach poruszyłem już kilka zagadnień z tego zakresu, a były to m.in.:

• Biblioteki portable
• Projekty shared
• Custom renderery

Twórcy Xamarina przygotowali jednak znacznie większą paletę rozwiązań z których możemy skorzystać na co dzień. Do tych najważniejszych oprócz powyższych, zaliczyłbym jeszcze:

• Wbudowany w system mechanizm DependencyService
• Efekty
• Statyczną klasę Device

W kolejnych wpisach postaram się nadrobić zaległości w tym temacie. Dziś zacznę od wbudowanej w Xamarin.Forms klasy DependencyService.

Xamarin.Forms nie jest lekiem na całe zło i w praktyce nie da się za pomocą tej technologii zrobić w pełni natywnego efektu, stosując dostępne standardowo kontrolki. Idea tego rozwiązania jest inna. Do worka zwanego Xamarin.Forms trafiają takie elementy, które da się jakoś uwspólnić pomiędzy obsługiwanymi systemami. Innymi słowy po użyciu określonej kontrolki i tak w rzeczywistości zostanie wykorzystana ta natywna, która w danym systemie jest najbardziej zbliżona funkcjonalnie i wizualnie. I tak np. Formsowy Label, w Windows tłumaczony jest na TextBlocka, a w Androidzie na TextView.

Na szczęście, tak jak napisałem we wprowadzeniu, do Formsów możemy łatwo dokładać elementy natywne w prosty sposób mieszając oba podejścia. Poza tym istnieją rozwiązania wbudowane w technologię, które cały ten proces w znaczący sposób ułatwiają. Jedną z takich opcji, są tytułowe Custom renderery.

W poprzednim wpisie na temat Xamarina, zrobiłem małe wprowadzenie teoretyczne do tej technologii. Przedstawiłem podstawowe założenia oraz dostępne warianty użycia tego rozwiązania.

Jeśli uważasz, że wybór technologii jaką jest Xamarin był sam w sobie trudną decyzję, to mam niestety złą wiadomość. Już na starcie trzeba podjąć kolejną i to równie ważną. Którego podejścia użyć - Forms czy Native?

W poprzednim poście przedstawiłem podstawowe założenia obu z nich. W wielkim skrócie - Forms zapewnią większą reużywalność kodu kosztem elementów specyficznych dla wspieranych platform. Podejście native z kolei, pozwala na tworzenie layoutów z użyciem elementów i technologii charakterystycznych dla wspieranych platform, co oczywiście wiąże się z większym nakładem kosztów. Wybór więc tak naprawdę zależy od potrzeb.

Warto jednak dodać, że wybór podejścia Forms niekoniecznie oznacza całkowite odcięcie od podejścia native. Oba rozwiązania można mieszać, z tym że w praktyce lepiej funkcjonują wstawki native w części Forms aniżeli odwrotnie. Z tego też powodu w dzisiejszym tekście skupimy się na podejściu opartym o formatki.

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:-)

Tworząc aplikacje mobilne, nie jest łatwo zbudować model danych, który idealnie odpowiadałby potrzebom aktualnego widoku. Problem staje się jeszcze bardziej złożony, w sytuacji gdy korzystamy z API, które zwraca ogólny model, dla rożnych końcówek. W takiej sytuacji, programista aplikacji mobilnej musi sam zadbać o odpowiednie wyświetlenie i sformatowanie otrzymanych danych..

W świecie Universal Apps problem ten można rozwiązać na różne sposoby. Osobiście preferuje tutaj wykorzystanie architektury MVVM, która wymaga od programisty stworzenia dedykowanego ViewModelu zawierającego odpowiednio przygotowane dane do wyświetlenia. Nie wszystkie właściwości da się jednak sensownie odpowiednio przetworzyć - zwłaszcza jeśli określony element danych wyświetlany jest inaczej na komputerze i telefonie. W takiej sytuacji z pomocą przyjdą konwertery. W dzisiejszym tekście zaprezentuje mix obu rozwiązań na przykładzie prostej aplikacji na telefon.

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;-)