Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Xamarin.Forms Tips — WCF, Intellisense, PCL Profile, build i inne bolączki

Rozpoczynając przygodę z Xamarin.Forms można natknąć się czasami na sytuacje, które mogą przyprawić o ból głowy. Postanowiłem zebrać kilka często spotykanych problemów i przedstawić ich rozwiązania.

Reaktywacja Intellisense w Xamarin.Forms XAML

Największą bolączką w przypadku pracy z Xamarin.Forms bywa... brak Intellisense w dokumentach XAML Xamarin.Forms w Visual Studio.

Problem nie występuje zawsze i nie pojawia się na samym początku pracy z XAML pod Xamarin.Forms. W moim przypadku po kilku godzinach nagle Intellisense przestał działać bez żądnego powodu. Co jeszcze dziwniejsze, na innym komputerze ze świeżym Visual Studio, podpowiedzi działają wyśmienicie.

Jeśli zatem coś zacznie szwankować w Intellisense warto sprawdzić następujące rozwiązania:

  • zamiast otwierać plik xaml dwuklikiem, klikam prawym przyciskiem myszy na dokumencie i wybieramy Open With.... W otwartym oknie z menu wybieramy Source Code (Text) Editor (zaznaczając przy okazji opcję Set as Default)
  • alternatywą może być instalacja dodatku Enable XAML Language for Xamarin.Forms, który w wielu przypadkach przywraca podpowiedzi w edytorze
  • problem może rozwiązać również odinstalowanie (nie dezaktywacja) ReSharpera, jeśli takowego posiadamy

WCF i zmiana profilu PCL

Często spotykanym problemem w Xamarin.Forms (PCL) jest dodanie referencji do WCFa (ręcznie wygenerowanie ich przy pomocy SLsvcUtil.exe również nic nie da). W domyślnej konfiguracji nie jest to możliwe. Przyczyną takiego stanu jest to, iż tworząc nowy projekt w Xamarin.Forms do solucji dorzucany jest projekt pod Windows Phone 8.1. To sprawia, że profil PCL ustawiany jest na kompatybilny z WP8.1 (dokładniej jest to Profile 111), co skutkuje brakiem wsparcia dla WCFa.

Wszyscy wiemy, że Microsoft pogrzebał Windows Phone 8.1 (Windows 10 Mobile jeszcze oficjalnie żyje), zatem rezygnując z wsparcia dla tego systemu, możemy uzyskać dostęp do WCFa. Można to zrobić szybko poprzez zmianę profilu PCL. Listę dostępnych profili, ze szczegółowym opisem, znajdziemy pod adresem: Notes on Using Various PCL Profiles with Xamarin. W tym przypadku śmiało przejść można na najnowszy profil 44.

Warto nadmienić, że instalując Visual Studio 2015, otrzymując wszystkie niezbędne profile PCL, zatem nie musimy nic ręcznie doinstalowywać.

Załóżmy, że mamy już solucję z Xamarin.Forms, w której znajdują się projekty na wiele platform.

Zacznijmy zatem od usunięcia projektu pod Windows Phone 8.1, który blokuje nam możliwość zmiany profilu (przy okazji usuwam też projekt pod Windows 8.1, a z okienek zostawiam tylko Universal Windows Platform).

Teraz wejdźmy we właściwości biblioteki PCL, do której dodać chcemy referencję do WCFa, a następnie otwórzmy okienko z docelowymi platformami (prawy klik na projekcie: Properties -> Library i przycisk Change w polu Targeting).

W tym miejscu wybieramy konfigurację jak na załączonym obrazku (można pokusić się też o ASP .NET Core 1.0). Takie ustawienie opcji ustawi profil PCL na 44.

W tym momencie dostaniemy pełne wsparcie dla WCF w Xamarin.Forms. Dokładny profil można podejrzeć i zmienić ręcznie poprzez edycję pliku csproj projektu PCL. Znajdziemy w nim dwa interesujące nas pola TargetFrameworkVersion i TargetFrameworkProfile. Pierwsze informuje o wersji frameworka do PCL, drugie o nazwie profilu.

Deploy aplikacji na Androida utknął na połączeniu z emulatorem

W przypadku, gdy SDK do Androida było instalowane/aktualizowane ręcznie (czy to po instalacji Visual Studio poprzez instalator Xamaina lub ręcznie, pobierając SDK z sieci), można napotkać na dość nieoczekiwany i trudny do zdiagnozowania błąd.

Przy próbie wrzucenia naszej aplikacji z Visual Studio na emulator Androida, konsola w VS zatrzyma się na (wraz z odpalonym i działającym emualtorem):

1>Starting deploy 4.5" KitKat (4.4) HDPI Phone ... 1>Starting emulator 4.5" KitKat (4.4) HDPI Phone ... 1>Validating emulator arguments... 1>Determining if emulator is already running... 1>Preparing virtual machine... 1>Launching emulator... 1>Emulator launched successfully

Problemem w tym przypadku jest ścieżka do SDK, a dokładniej ADB (Android Debug Bridge). Aby to objeść, w Visual Studio przechodzimy do Tools -> Options -> Xamarin -> Android Settings i zapamiętujemy Android SDK Location. Następnie otwieramy rejestr (regedit.exe) i przechodzimy do gałęzi:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Android SDK Tools

W tym miejscu wartość klucza Path ustawiamy na taką, jaka widnieje w VS w polu Android SDK Location.

Jak przebiega build projektu Xamarin.Forms na Androida iOS?

Pracując z Xamarinem warto wiedzieć w jaki sposób buildowane są poszczególne aplikacje do ich natywnych wersji.

Build aplikacji na iOS: kompilator Xamarin C# generuje C# IL (Intermediate Language), a następnie używając kompilatora Apple na macOS generuje natywny kod maszynowy na iOS, niczym kompilator Objective-C.

Build aplikacji na Androida: kompilator Xamarin C# generuje C# IL. Kod odpalany jest przez Mono na urządzeniu wraz z silnikiem Javy.

Kilka rad na koniec

Zamykając ten wpis chciałbym jeszcze dodać kilka uwag, o których warto pamiętać przy rozpoczęciu pracy z Xamarin.Forms:

  • nie ma sensu aktualizować na siłę poprzez NuGeta wszystkich pakietów związanych z Xamarinem; część z nich w najnowszej wersji nie jest zgodna z Xamarin.Forms, a jedynie z "natywnym Xamarinem"
  • mając w sieci komputer z macOS + Xcode, można skorzystać z iOS Simulator (for Windows); narzędzie umożliwi odpalenie w okienku Windowsa emulatora iOS, bez potrzeby łączenia się z pulpitem zdalnym macOS
  • pliki resources w Androidzie nie powinny zawierać znaków specjalnych
  • system Windows Phone 8.1 (nie mylić z Windows 10 Mobile) nawet Microsoft uznaje już za martwy, zatem jeśli nie warto spalać się i zachowywać kompatybilność z starszą wersją mobilnych okienek
  • Emulator Androida na Hyper-V działa o wiele szybciej niż odpowiednik od Google
  • Xamarin.Forms został niemalże stworzony do MVVM (MVVM Light Toolkit, MvvmCross)
  • Xamarin.Forms nie jest idealny, ale potrafi bardzo dużo
  • w Xamarin.Forms nie mamy, aż tak dużego wpływu na UI, jak w natywnym Xamarinie
  • chcąc zyskać na szybkości w ListView warto stworzyć kod w CS niż XAML

 

windows programowanie urządzenia mobilne

Komentarze

0 nowych
SebaZ   15 #1 05.11.2016 23:44

W kontekście śmierci mobilnego Windowsa uważam pisanie pod niego aplikacji, a potem portowanie jej na inne platformy za strzał w stopę... i to bolący jeśli chodzi o czas i zasoby. Wiem, ze Xamarin automatyzuje pewne sprawy, ale jednak pisanie czegokolwiek na Windows Mobile jest bezcelowe. Plus taki, że te appki zadziałają na PCtowym Windows 10.

djfoxer   17 #2 06.11.2016 01:10

@SebaZ: Stąd też warto zainteresować się Xamarinem, jeśli ktoś tworzy w .NET. Pisząc w C# można wypuścić apki na iOS i Androida z pominięciem platformy Windows.

Scorpions.B WSPÓŁPRACOWNIK  20 #3 06.11.2016 15:50

Pozdrawiam autora wpisu! :)

  #4 06.11.2016 15:52

@SebaZ: Wydaje mi się że większym strzałem w stopę byłoby pisanie aplikacji na Androida w Javie które później trzeba od zera pisać na iOS w Swift. Kto ma czas pisać aplikację dwa razy? Chyba nikt. Aktualnie są dwa sposoby aby aplikację napisać jeden raz na wszystkie platfrmy: HTML oraz Xamarin. Innego rozwiązania nie ma. Pisanie natywne w Java oraz Swift to strata czasu i pieniędzy

  #5 06.11.2016 15:55

@djfoxer: Ja bym wykluczył jeszcze Windows 8.1 w wersji PC. Niepotrzebne komplikowanie kodu a mało kto w tym systemie korzysta z aplikacji metro. Jak już pisać apkę z obsługą Windows to lepiej wybrać tylko Windows 10 z UWP bo z mojego doświadczenia wynika że pod tym systemem więcej osób korzysta ze sklepu. Aplikacje w okienkach są bardziej użyteczne niż na pełnym ekranie

kostek135   8 #6 07.11.2016 00:02

Anonim (niezalogowany): Anon #4 bzdury gadasz. Na iOS możesz spokojnie pisać w Java. Tu masz przykład apki ( https://github.com/jperedadnr/Game2048FX ) JavaFX dla 3 desktopów (Win,Lin,Mac) oraz iOS i Android. Ofc na WinMob się nie da, bo tam Java nie istnieje - tak jak sama platforma, więc bym ją olał.

Autor edytował komentarz w dniu: 07.11.2016 00:06
  #7 07.11.2016 10:23

Co do kompilacji dla iOS - w drugim kroku używany jest mtouch, kompilator, który został napisany w ramach projektu Mono.

  #8 07.11.2016 10:28

Mógłbyś rozwinąć temat szybkości ListView? Skąd to zwiększenie prędkości?
Co do wpływu na UI, jeśli chcesz, to możesz tworzyć renderery swoich kontrolek, dzięki czemu możesz tworzyć wymyślne UI :)

  #9 07.11.2016 16:11

- chcąc zyskać na szybkości w ListView warto stworzyć kod w CS niż XAML
ta porada juz chyba nie aktualna, RecycleElement daje rade.

- Emulator Androida na Hyper-V działa o wiele szybciej niż odpowiednik od Google
Odopwiedniki od google w wersji na procesory x86 z zainstalowanymHAXM w systemie działają równie szybko.

-w Xamarin.Forms nie mamy, aż tak dużego wpływu na UI, jak w natywnym Xamarinie
Bezpośrednio faktycznie mamy mniejszy wpływ, w razie potrzeby mogą nas poratować renderery .

-Xamarin.Forms nie jest idealny, ale potrafi bardzo dużo
"Nie jest idealny" bardzo w sedno :) Czasami to pół dnia rwania włosów z głowy.

djfoxer   17 #10 07.11.2016 19:56

@Marcin Lach (niezalogowany): Znalazłem to jakiś czas temu na forum Xamarina. Teraz widzę, że Michael Ridland umieścił to również w swojej prezentacji (slajd 15) http://www.michaelridland.com/xamarin/awesome-xamarin-forms-tips-tricks/

djfoxer   17 #11 07.11.2016 19:56

@Scorpions.B: Pozdrawiam autora komentarza ;)

djfoxer   17 #12 07.11.2016 19:57

@Anonim (niezalogowany): Tak, właśnie w tekście pisałem, że osobiście też usuwam W8.1, zostawiając tylko UWP i to raczej jako ciekawostkę na wolną chwilę.

djfoxer   17 #13 07.11.2016 20:04

@tttt2 (niezalogowany):
- ta porada juz chyba nie aktualna, RecycleElement daje rade.
trafna uwaga, ciekawy czy ktoś zrobił porównanie

- Odopwiedniki od google w wersji na procesory x86 z zainstalowanymHAXM w systemie działają równie szybko.
Z tego co czytałem Hyper-V jest sporo lepsze, a sam HAXM gryzie się z W10 Anniversary Update: https://code.google.com/p/android/issues/detail?id=221594

  #14 08.11.2016 15:35

@djfoxer: sprawdzę ten HyperV, dzięki. Odnośnie HAXM na W10 AU, z linku który podesłałeś wynika że problem został poprawiony w HAXM 6.0.4.

djfoxer   17 #15 09.11.2016 22:52

@Anonim (niezalogowany): Niestety nie do końca problem został u wszystkich rozwiązany.