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.