Xamarin – póki co nie polecam, dlaczego?

Jakiś czas temu, gdy pojawił się Xamarin bardzo zainteresowałam się tym środowiskiem. Zajmowałam się wówczas aplikacjami mobilnymi na Windows Mobile i Windows Phone a miałam ambicję zacząć zajmować się też tworzeniem aplikacji na Androida. Czekała mnie więc nauka Javy.
A tu nagle pewnego dnia znalazłam Xamarina. Pomyślałam sobie, że to cudowna perspektywa – mogę zostać przy moim ulubionym języku C# i jednocześnie móc robić aplikację na Androida. System iOS w ogóle mnie w tamtym momencie nie interesował, bo środowiska tego nie lubiłam i nie chciałam mieć z nim do czynienia nawet za pośrednictwem C#.
Jednak los chciał inaczej – któregoś dnia miałam wreszcie szansę spróbować swoich sił w rozwijaniu aplikacji komercyjnej na iOS za pomocą Xamarin Studio.
Niestety miałam też pecha o którym za chwilę.
Istnieje kilka sposobów robienia tego typu aplikacji:
Najgorszy – Xamarin Studio + Xcode – kiedy to design aplikacji jest definiowany za pomocą Xcode, więc developer zmuszony jest używać Xamarin Studio na Macu oraz Xcode (którego programista .NET raczej nie zna).
Lepszy – Xamarin Studio na Windows lub wtyczka do Visual Studio + serwer buildowy na Macu – design definiowany jest w Xamarin Studio lub Visual Studio.

Chyba najbardziej efektywny, bo oferuje najwięcej współdzielonego między platformami kodu – Xamarin Forms – realizowane poprzez Xamarin Studio na Windows lub wtyczkę w Visual Studio.

Jak łatwo się domyślić, kiedy mówimy o pechu – niestety trafiłam na tą najgorszą wersję.

Zatem: współpraca Xamarin Studio i Xcode na Macu jest mocno niedopracowana.
Przykładowo: żeby plik z designem otworzyć w Xcode trzeba kliknąć nań dwa razy w Xamarin Studio i kiedy się go zmieni (a nawet jak nie zmieni) i wróci do Xamarin Studio wyświetla on, że aktualizuje zmiany z Xcode (nawet jeśli ich nie było!!!). Ale jeśli wtedy stwierdzimy, że jeszcze może byśmy coś zmienili, wrócimy do Xcode, zmienimy coś i przejdziemy do Xamarin Studio zmian już nie widzi. Za każdym razem trzeba klikać podwójnie w plik, którym chcemy wyedytować. Nie widzi też wszystkich zmian, jeśli zrobimy je w tym pliku w który kliknęliśmy a także w jakimś innym. Zmiany w tym drugim nie przeniosą się do Xamarina automatycznie. Najczęściej trzeba przeładować projekt a nawet Xamarin Studio zrestartować. Podobnie się dzieje, jeśli plik z designem mamy aktualnie otwarty w Xamarin Studio (jest to zwykły XML choć niespecjalnie przyjazny do edycji „z palca”). Jeśli zmienimy go w międzyczasie w Xcode, Xamarin go nie przeładuje. Generalnie takich smaczków jest więcej, ponieważ ciągle przychodzą aktualizacje do środowiska, które nie zawsze coś naprawiają, a czasem wręcz psują. Po niedawnej aktualizacji Xamarin Studio na Macu zaczął mi się zawieszać na amen, kiedy debugowałam aplikację i wyskakiwał jakiś exception. Dla kogoś przyzwyczajonego do dojrzałego środowiska jakim jest w tym momencie Visual Studio używanie Xamarin Studio jest najzwyczajniej w świecie bolesne.

Tak więc po początkowej fascynacji Xamarinem przyszedł czas na refleksję. Moim zdaniem jego IDE jest jeszcze mocno niedopracowane i przypomina mi trochę Visual Studio C++ 6, które to w porównaniu z podobnym w przeznaczeniu środowiskiem Borland Builder było cienkie i niewygodne w użyciu. Takie właśnie mam odczucie teraz jeśli próbuję porównywać Visual Studio i Xamarin Studio. Na dodatek to połączenie Xamarin Studio + Xcode dla programisty .NET, który nie ma pojęcia o Xcode (jak ja), kompletnie mnie rozczarowało. Nie rozumiem do końca, co kierowało twórcami, kiedy zdecydowali się w ogóle dopuścić taką opcję.

Pewnej nadziei dla tego środowiska doszukiwałabym się w korzystaniu tylko i wyłącznie z wtyczek do Visual Studio – dzięki temu zachowujemy moc naszego ulubionego IDE a także we wspomnianych wyżej Xamarin Forms. Nie miałam okazji jeszcze spróbować w „prawdziwych” aplikacjach tych dwóch podejść, ale jeśli tylko będę miała nie omieszkam o tym wspomnieć.

Na ten moment z kolei zapał do pisania aplikacji na Androida za pomocą Xamarina nieco mi osłabł i chyba wrócę do pomysłu nauczenia się Javy. W końcu IDE do aplikacji Androidowych robi nie byle kto, bo JetBrains, więc można się spodziewać tylko dobrych rzeczy.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *