Ś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.

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.

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.

Rynek aplikacji mobilnych wciąż ma się świetnie, mimo że na horyzoncie pojawia się silna konkurencja, która byłaby w stanie rozwiązać część problemów związanych z developmentem aplikacji mobilnych. Chodzi mi oczywiście o responsywne strony WWW, które w dzisiejszych czasach są już standardem. Z każdym tygodniem wzrasta wsparcie dla standardów webowych w mobilnych przeglądarkach, dlatego też możliwości programistów są w tym obszarze coraz większe.

Rozwój mobilnych stron nie jest jednak jeszcze w tej chwili problemem dla deweloperów aplikacji. Ci póki co wciąż mogą spać spokojnie. Strony WWW nie mają dostępu do wielu istotnych API po stronie urządzenia. Poza tym dedykowane aplikacje wciąż są lepiej dopasowane do realiów poszczególnych systemów.

Oczywiście aplikacje mobilne mają swoją problemy. Przede wszystkim trzeba ich napisać tyle, ile systemów mobilnych chcemy obsługiwać. Ma to oczywiście wpływ na czas oraz koszta. Musimy posiadać programistów specjalizujących się w technologi dedykowanej platformy mobilnej. Ale czy na pewno?

Można się skusić na tzw. rozwiązania cross-platformowe, czyli np. na tytułowego Xamarina. Ale czy wybór takiej technologii na pewno pozwoli na skrócenie czasu projektu x razy?

Kojarzycie Incepcję? Według mnie był to naprawdę dobry kawał kina - jedna z tych pozycji, o których mówimy i myślimy również po wyjściu z sali kinowej. Film na rynku polskim nazwano Incepcją, choć oryginalny tytuł brzmi Inception - zrobiono tutaj prostą kalkę językową zamiast zastosować właściwe tłumaczenie. W ten sposób dystrybutorzy filmu dodali do naszego codziennego słownika ten nieformalny zwrot (termin ten nie występuje w SJP - info na dzień pisania wpisu), który dla wielu osób oznacza wielokrotne zagłębienie.

Termin incepcja odrobinę pasuje do tego, o czym chciałbym napisać w dzisiejszym wpisie. Zademonstruję Wam bibliotekę do programowej obsługi NuGeta, którą można sciągnąć jako paczkę NuGetową;-)