PorównanieW środę 24 października byłem na spotkaniu grupy WODNUG prowadzonej obecnie przez Szymona Seligę.
Spotkanie było poprowadzone przez Marcina Nowaka, który opowiedział o rozwiązaniu XAMARIN.
Sam się tym rozwiązaniem kiedyś interesowałem.
Zrobiłem nawet o tym prezentację oraz wpis na temat moich przemyśleń co, do programowania na wielu platformach.
Spotkanie to jednak mnie poruszyło.
Sam programowałem kiedyś na Windows Phone, na Androida i na iOS.
Najgorsze jest jednak to, że jak zestawi się sposób programowania i przyjazność środowiska, to rzeczywiście na tle tego wszystkiego Windows Phone wygrywa.
Najgorszy jest iOS, który ma dziwną filozofię i wywraca wszystko do góry nogami, ale po kolei.
Programowanie na systemy Android
Android nie jest taki straszny, jak się na początku może wydawać dla programisty .NET.
Kompletnym koszmarem w tym zestawieniu jest i zawsze będzie iOS.
Zacznijmy więc od pewnych drobnostek, czyli od języka JAVA.
Java nie ma właściwości, ale w trakcie pisania najbardziej mi brakowało wyrażeń LINQ. Można jednak z tym żyć.
Kontrolki władnące listami elementów moim zdaniem naprawdę są źle napisane. Zacytuję tu siebie z innego wpisu.
Model samej platformy ma tyle dziwnych mechanizmów, że człowiek czuje jakby się cofał. Powiązanie danych z listą w Androidzie wymaga napisania adaptera. Sam adapter musi być napisany zgodnie z pewnymi wytycznym i sztuczkami, które można znaleźć na necie jak i na samych prezentacjach Google. Jeśli tego nie zrobimy możemy się zdziwić dlaczego lista tak wolno się przesuwa. Jak się okazuje, ona z każdą akcją użytkownika się odświeża, co przy źle napisanym kodzie oznacza katastrofę.
Są to jednak drobnostki. Można się do nich przyzwyczaić i je zaakceptować.
Można zaakceptować fakt, że emulator Androida jest bardzo powolny, a przynajmniej taki był, gdy pisałem aplikacje. Testowanie na telefony z Androidem nie jest trudne, gdyż uzyskanie jakiegoś chińskiego śmiecia do testów nie jest trudne.
Android istnieje w teorii wszędzie, trzeba więc stworzyć wiele widoków. Nie mamy też pewności, czy aplikacja będzie działała na każdym urządzeniu? Od tego problemu są jednak emulatory, można więc sprawdzić jak na każdym urządzeniu nasza aplikacja działa.
Android nie obsługuje oczywiście grafiki wektorowej. Trzeba więc tworzyć wiele ilustracji do tego samego przycisku.
Zleceniodawcy na Androida często mają abstrakcyjne pomysły na aplikacje, które wymagają łamania ustalonych reguł i łamania rejestru samego systemu. Brak więc żelaznych reguł dla twórców aplikacji też może być problemem. Możesz robić wszystko, ale nie każdy wie jak, zwłaszcza ty. To nie jest wiedza powszechna, którą można uzyskać z książek i Internetu. A tak się składa, że konkurencja wie jak to zrobić. Tajemna wiedza.
Brak żelaznego sklepu z aplikacjami Android i możliwość innej dystrybucji można uznać za zaletę.
Przejdźmy więc dalej.
Programowanie na systemy iOS
Objective-C nie był taki straszny. Teraz jak wspominam programowanie na tę platformę, to rzeczywiście śmiało mogę powiedzieć, że większość czasu poświęciłem wykonaniu wyglądu aplikacji, a powinienem się skupić na tym jak ona ma działać.
Co gorsze - jak mam tworzyć cały interfejs aplikacji?. Nie ma kursu, czy tutoriala, który jasno powiedziałby jakie są wady i zalety użycia globalnego StoryBoardu, gdzie wszystkie widoki są w jednym miejscu.
Wybrałem rozwiązanie StoryBoard. Była to nowa funkcjonalność, więc wszędzie można było o tym przeczytać. Można było wyklikać nawigację używając mechanizmu segue.
Aplikacja, którą pisałem rozwijała się z dnia na dzień na coś bardziej poważnego. Mając do dyspozycji 30 widoków i 30 kontrolerów ( a nie 8 jak wcześniej ) doszedłem do wniosku, że lepiej byłoby napisać każdy widok oddzielnie, tak jak to się robiło przed StoryBoard. Nawigacja pomiędzy widokami jest w rękach kodu, więc można bardziej poszaleć.
Chociaż uwaga nawigacja w iOS nie jest taka elastyczna jak w Androidzie, więc jeśli zleceniodawca z dnia na dzień coś wymyśli, np. że ma coś inaczej działać to i tak jest to problem.
Oczywiście iOS nie ma obsługi grafiki wektorowej. Każdy przycisk to obrazek. iOS wraz z obecną wersją 8 musi posiadać wiele rozdzielności danego obrazka. Gdy ja programowałem, każdy obrazek musiał mieć jeszcze swoją wersję dwa razy większą od normalnego rozmiaru. Obecnie trzeba posiadać jeszcze obrazek 3 razy większy. W ten sposób powstaje obsługa DPI.
Jest to jednak irytujące ponieważ w takich chwilach przypominam sobie, że jestem programistą i nie powinienem spędzać tyle czasu nad grafikami.
Pamiętam jak po premierze iOS7 zaktualizowałem projekt w nowym XCODE wtedy 5. Cały layout mi się rozsypał, bo nie zrobiłem go według pewnych wytycznych. Poprawiałem go przez 3 dni.
Moim zdaniem programowanie - a raczej robienie wszystkiego innego jest tak bolesne w iOS, że nie ma co marzyć o napisaniu zawansowanej aplikacji, nie mając doświadczenia i wiedzy na temat jak unikać takich pułapek w iOS.
Moim zadaniem było też napisanie aplikacji na iOS tak, aby wyglądała ona tak samo jak jej powstająca wersja na Android. Na iOS aplikacja nie może oczywiście wyglądać jak aplikacji napisana w Metro UI albo jak na Androida z małymi przyciskami. Musiałem się wykazywać własną inicjatywą jak, co ma wyglądać. Pamiętam też jak przez cały tydzień kłóciłem się ze swoim zleceniodawcą, że pasek nawigacji w iOS nie może składać się z wielu ilustracji i musi mieć miejsce na przycisk wstecz.
Tyle kłótni, bo według czyjeś wizji coś musi wyglądać tak samo, a według wytycznych sklepu iOS nie może to tak wyglądać.
Myślę, że iOS to jednak dobra platforma, zwłaszcza jeśli chcemy napisać aplikację, która wyświetla jakąś listę elementów pobranych z jakiegoś serwisu iOS.
Moim zadaniem było napisanie aplikacji rozszerzającej rzeczywistość, używając Wikitude. Sam framework ciągle się wieszał bez mojej kontroli, więc przyszłość aplikacji wydała się blada.
Nic dziwnego, że ostatecznie oszczędziłem sobie tego bólu. Do iOS może kiedyś wrócę.
Szkoda, że najtańszy komputer z iOS kosztuje obecnie 3800 zł. Używanych lepiej nie kupować.
Jak już mówimy o kosztach to warto powiedzieć, że bez licencji IPhone, która kosztuje 100$ nie możemy testować aplikacji na telefonach, które jej nie mają. Warto też powiedzieć, że telefon IPhone kosztuje w okolicach 3000zł. Tablet 2000 zł.
Programowanie na Windows Phone
Windows Phone.
Podstawowa wada polega na braku gotowych rozwiązań. Jest to platforma przez wielu pomijana i zapominana, i dotyczy to też bibliotek i narzędzi pomocniczych.
iOS to chodzący problemy, ale ponieważ jest on popularny, to posiada wiele narzędzi. Chociaż nie działają one stabilne jak np. opisany wcześniej Wikitude. Jeśli czegoś nie ma na iOS, to przy ludziach wyglądasz jak idiota, a z Windows Phone możesz się wykręcić, że przecież nikt tego nie używa.
Windows Phone obsługuje jednak grafikę wektorową napisaną w XAML. Nie trzeba więc tworzyć wielu ilustracji dla tego samego przycisku. Aplikacja zawsze będzie wyglądać tak samo ładnie, bo tak działa grafika wektorowa. Rysowanie grafiki nie ma efektu ubocznego na samo działanie aplikacji. Wydaje się więc, że iOS i Android to jakiś kiepski dowcip - w tym wypadku.
Warto też wspomnieć o mechanizmie powiązywania danych, znanych z WPF i Windows Runtime. Dzięki temu, mechanizmy adapterów z Androida i mechanizmy zdarzeniowe z iOS wydają się raczkować i traktować programistę jak idiotę.
Przypisuję kolekcje do właściwości. W widoku napisanym w XAML mówię, co ma gdzie trafić, a resztą zajmuje się sam framework.
C# oczywiście wygodniej się programuje niż w Objective-C.
Sklep Windows Phone nie jest taki wymagający. Jego egzystencja jednak może wkurzać programistów Android.
Podsumowanie co z rozwwiązaniem XAMARI
Czy można programować na wielu platformach używając C#?
Od dwóch lat nie sprawdzałem co się dzieje w tym rozwiązaniu.
Nie czuje się jednak zawiedziony swoim przyjściem do grupy WODNUG. Wręcz przeciwnie wymusiło to moją mentalną dyskusję na temat, na której platformie dobrze się piszę programowanie.
Najnowsze rozwiązanie XAMARIN nazywające się XAMARI forms rozwiązuje problem różnych widoków, w każdej platformie. Co z tego, że będziemy mieli współdzielny kod jeśli widoku nie możemy współdzielić.
Teraz jednak jest to możliwe. Można opisywać wygląd aplikacji w C#, trochę na wzór właściwości XAML. Kod ten zostanie odpowiednio przetłumaczony.
Przyszłość pisania aplikacji mobilny zapowiada się ciekawie.
Zapraszam także na każde spotkanie Grupy .NET WODNUG które jest organizowane w ostatnią środę miesiąca. 
