Xamarin – intellisense i breakpointy

Już wczoraj szykowałam się do opisania jak bardzo ucieszyło mnie dodanie intellisense do XAML’a w Xamarin dla Visual Studio. Tak – znalazło się w najnowszych aktualizacjach.
Gdybym jednak te aktualizacje robiła regularnie już ponad tydzień temu odkryłabym, że pojawiła się również regresja w postaci problemów z debugowaniem na iOS z VS. Problem ten już kiedyś się pojawił i był rozwiązany. Mianowicie w trybie debug aplikacja nie zatrzymuje się na breakpointach… Tym samym moja radość z nowych aktualizacji nie trwała długo.
Na szczęście jest obejście na ten problem: https://bugzilla.xamarin.com/show_bug.cgi?id=29628#c5

Nie przestaje mnie dziwić, iż Xamarinowanie zdaje się być dużo trudniejsze na platformę iOS niż Android, chociaż to iOS jest popularniejszy. Pytanie czy to ekipa Xamarina nie nadąża za iOSem czy iOS podkłada kłody pod nogi konkurencji…

Xamarin Studio – Split View iOS

Któregoś dnia chciałam użyć Split View w aplikacji iOS. Niestety okazało się, że tutorial na temat jak używać tej kontrolki znajdujący się na stronie Xamarina nie za bardzo sprawdza się w rzeczywistości. Składa się z dwóch części – w pierwszej jest jakiś kawałek kodu do ściągnięcia, w drugiej opis „zrób to sam”. Niestety po złożeniu wszystkiego kod nie dość, że nie działa, to nawet się nie kompiluje.

Może kiedyś, gdy to naprawią, ten wpis się zdezaktualizuje, ale na dzień dzisiejszy opisy ze strony Xamarina nie działają.

Musiałam jednak skleić to wszystko ze sobą, tak by działało a efekt umieściłam na githubie. Może komuś zaoszczędzi trochę czasu na naprawianiu tutorialowego skryptu. Swoją droga można by się spodziewać czegoś więcej po tak drogim środowisku pracy;)

Xamarin Studio na Macu – bug czy feature?

Jestem bardzo przyzwyczajona do Visual Studio i sądziłam, iż twórcy Xamarina wyjdą bardziej naprzeciw developerom o podobnych przyzwyczajeniach.
Przedstawiam zatem kolejne „urozmaicające” życie smaczki z Xamarin Studio w edycji na Maca, które całkowicie odróżniają to środowisko od VS.

1 – Opcja „Refactor -> Zmień nazwę”
Po pierwsze widać tutaj mieszankę języka polskiego z angielskim, ale o tym za chwilę. Zmieniam nazwę, potwierdzam, zmienia się w powiązanych plikach i w bieżącym, ale… ojej, zrobiłam literówkę. Odruch? Cofam. Co się okazuje? Cofnięcie działa tylko na bieżący pliku. Dla porównania w VS oczywiście odwracane są wszystkie zmiany.

2 – Opcja „Add -> New file” (tutaj już nie będzie mieszanki, bo zrezygnowałam  z używania wersji polskiej interfejsu). Wybieramy utworzenie nowej pustej klasy i w efekcie otrzymujemy klasę zadeklarowaną jako publiczna od razu z pustym konstruktorem również publicznym. Tym samym łamana jest zasada, iż elementy powinny być deklarowane z jak najmniejszym dostępem. Powinien on być rozszerzany w miarę potrzeb. Jeśli tak będziemy pisać kod, to szybko stanie się on książkowym przykładem antypatternu Object Orgy. Dlaczego Xamarin pcha nas w tym kierunku?

3 – Opcja „Refactor -> Extract local variable”.  Klikamy na jakiejś liczbie, nasza zmienna się wyodrębnia, ale zostaje ona nazwana domyślnie ‚i’. W ten sposób nie pozostawia nam wyboru nazwy. Żeby ją zmienić trzeba użyć powyższej wątpliwej opcji „Refactor->Rename (Zmień nazwę)” ewentualnie zamienić ręcznie. Co ciekawe, jeśli klikniemy na jakimś stringu, to mamy nie tylko „Extract local variable”, ale również, co właśnie dużo bardziej by się tutaj przydało, „Create Constant Field”. Dlaczego brakuje tej opcji w odniesieniu do liczb? Przecież z nich równie często zdarza się tworzyć stałe.

Jak już wspomniałam, tłumaczenie w XS jest mieszane – kiedy mam ustawiony User Interface Language na polski albo default (wtedy prawdopodobnie bierze utawienia z systemu operacyjnego). Nie ma kompletnego polskiego tłumaczenia, więc jest pół na pół. Lepiej ma się sytuacja z językami takimi jak hiszpański czy niemiecki (tylko te poza polskim sprawdziłam), ale nadal tłumaczenie jest niekompletne. Po co tracić czas na coś niedokończonego? Lista języków do wyboru jest bardzo długa, ale co z tego skoro tak „działają”.

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.