Świat technologi działających w oparciu o .Net Framework jest ostatnimi czasy niezwykle bogaty. Mamy tutaj kilka rozwiązań mobilnych, webowych, a także wsparcie dla desktopów. Można by powiedzieć - czysta sielanka. Pewne problemy zaczynają się jednak w sytuacji, w której rzeczywiście chcielibyśmy pracować z kilkoma rozwiązaniami naraz.

W takiej chwili, naturalne stają się próby współdzielenia raz napisanego kodu, w różnych rozwiązaniach. Microsoft udostępnia w takim celu choćby tzw. Class library. Jednak jeśli kiedykolwiek próbowaliście użyć tego rozwiązania dla różnych targetów, to z pewnością już wiecie, że jest to po prostu technicznie niewykonalne.

Rozwiązaniem tego problemu, miały być tzw. portable class library. W praktyce rzeczywiście za ich pomocą można przygotować bibliotekę, która będzie mogła być skonsumowana na różne sposoby, o ile tylko odpowiednio wybierzemy jej profil. Tych jest całkiem sporo, a każda zmiana wymagana ponownej rekompilacji wszystkich elementów w naszej układance. Zmiana profilu powoduje również zawężenie, bądź też rozszerzenie zestawu dostępnych API. Ogólnie jest to rozwiązanie na tyle problematyczne, że tęgie głowy postanowiły wypracować nowe, bardziej uniwersalne rozwiązanie.

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.

Od jakiegoś czasu, dość intensywnie zajmuje się Xamarinem, a ściślej jego mutacją Forms, która pozwala na szybsze tworzenie jednej aplikacji na kilka systemów. Jest to z pewnością narzędzie godne uwagi, ponieważ niesie ze sobą spore możliwości.

Niestety przeglądając zasoby sklepów mobilnych, trudno znaleźć informację w jaki sposób były tworzone umieszczone w nich aplikacje. Dlatego też nie ukrywam, że ucieszyła mnie informacja o możliwości recenzowania aplikacji napisanej w technologii, która obecnie stała mi się bardzo bliska i która po przejęciu przez Microsoft, ma szansę nabrać wiatru w żagle.

Zapraszam do recenzji aplikacji WydatkoNotes w wersji na Androida.

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.

Blisko 5 lat temu popełniłem mój pierwszy tekst na temat Taskera. Od tego czasu z aplikacji korzystałem praktycznie codziennie i była ona stałym bywalcem wszystkich moich urządzeń z Androidem. Tasker to świetne narzędzie, które przy pewnym wkładzie początkowym, po prostu działa i ułatwia nasze życie. Program niestety od zawsze miał dwa poważne problemy, które zniechęcały do niego wielu użytkowników.

Po pierwsze była to cena, która cały czas oscyluje w granicy 20 zł, a po drugie złożoność. Dla przeciętnego Kowalskiego ten program był po prostu zbyt skomplikowany.

Dla mnie przez pracę w IT, ten drugi argument nie był argumentem na nie, a i pierwszy przestał być problemem, w momencie gdy poznałem dostępne funkcjonalności tego kombajnu.

Piękna sielanka trwała blisko 5 lat i tak naprawdę zepsuła ją dopiero wymiana telefonu na nowszy...

Xamarin nie jest gwarantem trzykrotnie szybszego developmentu. Nie zachodzi tutaj żadna równość typu, że niezależnie ile platform docelowych będziemy chcieli obsłużyć, to w praktyce i tak piszemy jedną aplikację. Xamarin tak nie działa. Nawet w sytuacji gdy korzystamy z Formsów to i tak nie jesteśmy w stanie skrócić developmentu na inne platformy do zera. Na ten temat szerzej pisałem we wpisie w ubiegłym tygodniu.

Czy zatem warto się w ogóle zainteresować tą technologią? Czy oferuje ona jakieś sensowne benefity? Na jakim systemie możemy programować? Jak to wszystko w praktyce działa? Na te i inne odpowiedzi postaram się odpowiedzieć w dzisiejszym tekście, który jest swego rodzaju wprowadzeniem do tej technologii na łamach mojego bloga.