Kolejnych kilka słów na temat początków pracy w Xamarin’ie

Siemanko.

W dalszym ciągu doprowadzam projekt aplikacji mobilnej w Xamarin’ie do stanu jaki prezentuje już w Android Studio. To jest oczywiście warunkiem wprowadzania i rozwijania kolejnych funkcjonalności. Przypomnę, że ogarniętą mam już autentykację, logowanie (również przez fb), rejestrowanie, lokalizację, pobieranie i wyświetlanie listy ogłoszeń oraz tworzenie nowego ogłoszenia (o czym jeszcze nie pisałem na blogu). Mimo braku wolnego czasu w ilości jakiej bym tego sobie życzył robota idzie całkiem nieźle bo aby dojść do wcześniej wspomnianego stanu zostało mi tylko zrobienie jeszcze jednego activity z obsługą tworzenia nowego ogłoszenia oraz jakieś drobne usprawnienia, takie jak „handling results” przy zmianie orientacji ekranu itp.. Do czynników składających się na tak sprawne tempo należy c#, .NET, znajomość VS oraz bagaż doświadczeń jaki wyniosłem z Android Studio :).

Dobra, koniec tego pierdololo. Jedziemy dalej z Xamarin’em (pierwsza część tutaj).

Struktura projektu

1

Projekt z ikonką telefonu o nazwie MobileSecondHand.App to natywna aplikacja androidowa zawierająca UI oraz wszystkie dllki pochodzące z Android SDK dla Xamarina. To tu piszę activity, widoki, funkcjonalności wykorzystujące sprzętowe moduły urządzenia z androidem (kamera, gps, itp.). W tym projekcie znajduje się kod, który nie jest cross-platform. Ten kod jest tylko dla androida.

Kolejne dwa projekty są to PortableClassLibrary. W tych projektach kod jest (tak obiecują) cross-platform i może być wykorzystany w aplikacjach dla trzech znanych systemów operacyjnych na urządzenia mobilne. Ja umieściłem w nich modele oraz serwisy do komunikacji z REST API oraz do innych rzeczy dostarczających lub obrabiających jakieś dane. Ogólnie wszystko co można odseparować od zależności do konkretnej platformy. We wszystkich trzech projektach mogę korzystać z nugeta i doinstalowywać sobie dobroci jakie się w nim znajdują. Co się znajduje w tych projektach? A to 🙂

Podsumowanie

Z kodu aplikacji, który piszę teraz w Xamarin’ie jestem o niebo bardziej zadowolony niż z tego co się działo w javie, w Android Studio. Te same funkcjonalności zajmują o wiele mniej linijek, a jakakolwiek potrzeba ingerencji w już napisany wcześniej kod nie sprawia mi problemów. W przeciwieństwie do projektu w Android Studio. Tam to była (jest) „sodomia i gomoria” 😉

Przesiadka na Xamarin’a to była decyzja right on point – tak z angielska – a co 🙂

Pjona!

Reklamy

Wrażenia po pierwszych randkach z Xamarinem cz. 1

Siemanko.

Jak wiesz z tego wpisu, postanowiłem porzucić projekt aplikacji mobilnej w Android Studio i zacząć wszystko od nowa w Xamarin’ie (w związku z tym, że stał się darmowy). Wiązało się to oczywiście z dodatkowym nakładem pracy na doprowadzenie apki do stanu jaki już prezentuje w projekcie z Android Studio, ale ekscytacja nową technologią, o której coraz więcej się słyszy oraz perspektywa pracy w znanym mi środowisku (Visual Studio) wzięły zdecydowanie górę i już dziś poszedł do repo pierwszy push z projektem Xamarin’owym. Jakie wrażenia po ok 10ciu godzinach pracy w Xamarinie?

Powolny start aplikacji

To było pierwsze moje spostrzeżenie po przesiadce z Android Studio gdzie start apki z debuggerem trwał w porywach do 10ciu sekund, a bez debuga niemal natychmiast, tak start nawet czystego wygenerowanego templat’u w Visual Studio trwa znacznie dłużej. Nie mierzyłem stoperem, ale jest to na prawdę znacząca różnica w szczególności jeśli wprowadzam jakieś drobne zmiany w kodzie i chcę szybko zobaczyć ich wpływ na działanie aplikacji. Niestety aplikacja dłużej się uruchamia niż ja potem w niej klikam. W zasadzie nie ma co się dziwić bo przy każdym uruchomieniu aplikacja chyba jest publikowana (z tego co widać w output’cie) i przerabiana na jave więc to musi trwać. Dodam, że nie korzystam z emulatora tylko z fizycznego urządzenia.

Nie wszystko na co IDE pozwoli zostanie zatwierdzone przy build’zie.

Napisałem jakiś kod, który był poprawny dla .NETu natomiast przy buildzie czy próbie uruchomienia aplikacji dostałem wiele mówiący błąd:

1

I tyle. Żadnego wskaźnika do miejsca w kodzie. Domyśliłem się co mogło być problemem więc zlokalizowanie kodu, z którym maszynka do javy miała problem nie trwało długo lecz kiszka była by gdybym naklepał sporo kodu bez buildów w między czasie opierając się tylko na informacjach od IDE. Weź bądź mądry i szukaj wiatru w polu.

Jeśli coś się nie renderuje w designerze niekoniecznie nie będzie się renderować po starcie.

No właśnie. Na tym straciłem ze dwie godziny. Dodałem do projektu komponent: Facebook Android SDK (przez Component Store – taki Xamarinowy nuget). Nie jest to oficjalne SDK wydane przez Facebooka tylko przez grupę Xamarina. I tak jak w Android Studio dodałem sobie na widok (w .xml) guzior do logowania z facebookiem. Przełączam się na widok designera, a tu bach:

2

Mówię sobie: trudno – nikt nie powiedział, że będzie łatwo 🙂 Grzebałem w necie, sprawdzałem sample tego SDK, odinstalowywałem i instalowałem ponownie komponent itp. itd. tak przez jakieś 2 godziny bez rezultatów.  W końcu uruchomiłem aplikację z ostatnią nadzieją, że to designer sobie nie radzi i ku mojej radości przez zaciśnięte zęby tak się właśnie dzieje. W uruchomionej aplikacji guzik jest wyrenderowany.

IMAG0025

I tak jest również z innymi komponentami androida, które w Android Studio są dostępne „z pudełka” natomiast w Xamarin’ie trzeba je pobierać prze Comeponent Store do swojej aplikacji i oglądać dopiero po uruchomieniu apki 😉 Mam nadzieję, że chociaż Tobie zaoszczędzę trochę czasu i sporo frustracji jeśli napotkasz na ten sam problem.

Podsumowanie

Z dzisiejszego wpisu pewnie wnioskujesz, że nie jestem zbyt zadowolony z przesiadki na Xamarin’a oraz w ogóle z pracy, z tym ustrojstwem 😉 Otóż nie. Skupiłem się na tych skrajnych przypadkach ponieważ to one rzuciły się najbardziej w oczy w pierwszej kolejności. Dobrodziejstwa? Największą zaletą jest C# i .NET. Nie muszę korzystać z zewnętrznej biblioteki do asynchronicznej komunikacji z rest api bo z pudełeczka mam HttpClient i operatory async/await. Nie muszę korzystać z Gsona (które jest mega powolny) do konwersji jsona na obiekty bo mam z nugeta Newtonsoft.Json. Nie fiksuję się tylko i wyłącznie na jedną platformę bo mam PortableClassLibrary i jak mi odpierdoli to kupie sobie iPhona i będę mógł wykorzystać ten sam kod do pisania apki na iOSa 🙂

W środę dalsza część wrażeń z pracy w Xamarin’ie.

Pjona!

Bye bye Android Studio. Hello Xamarin!

Siemanko.

poprzednim poście zaanonsowałem, że dzisiejszy wpis będzie traktował o części Asp.Net’owej projketu, a konkretnie o Entity Framework Core. Jednakże breaking news z czwartku spowodował, że postanowiłem zmienić technologię (a raczej narzędzie) w jakiej piszę aplikację mobilną na androida, dlatego jednocześnie dzisiejszym tematem są zmiany w projekcie.

Xamarin za darmochę!

Jeśli pochodzisz ze światka .NET’owego to wiesz o co kaman. Jeśli nie – dowiesz się z następnych zdań. Xamarin to platforma do pisania aplikacji tzw. „crossplatform”, na trzy mobilne systemy operacyjne:

  • android
  • iOS
  • windows phone

Aplikacje piszę się w języku C# i .NET. Teoretycznie jeden kod – trzy systemy. Teoretycznie bo warstwa UI każdego z systemów jest różna:

  • android – .xml
  • iOS – chuj wie jak się to nazywa ale potrzeba do tego maca
  • windows phone – .xaml

Jednak jeśli dobrze rozgraniczymy warstwę prezentacji od pozostałych (dostępu do danych, samych danych, itp.) to średnio ok 60% kodu (tak mówi gościu z kursu na pluralsite) można wykorzystać do zbudowania apki na każdy z systemów mobilnych. Brzmi super? Tak, tylko, że jeszcze do czwartku (30.03.2016) Xamarin był komercyjny i drogi, a jego wersja trial opiewała na jedyne 30 dni. To się zmieniło i dla pojedynczych devów Xamarin jest za darmochę. Pozdrowienia dla hejterów Microsoft’u! Bang!

Przesiadka na Xamarin’a.

Podjąłem decyzję, że dotychczasowy kod i w ogóle cały projekt w Andriod Studio puszczam w niepamięć i zaczynam pisać aplikację od zera w Xamarin’ie.

Zalety:

  • znam C# i .NET
  • znam Visual Studio
  • nie fiksuję się tylko na andrioda jeśli chodzi o kod niezwiązany z UI
  • nie muszę błądzić po środowisku i języku, którego nie znam
  • to jest wg mnie przyszłość

Wady:

  • sporo (niezbyt ładnego swoją drogą) kodu java idzie do kosza
  • muszę zacząć od zera aplikację mobilną co oznacza, że praca nad rozwijaniem dotychczasowych funkcjonalności nie jest możliwa

Jak widać zalety przewyższają (ilościowo) wady. Trochę czasu stracę na robienie od początku tych funkcjonalności, które już napisałem w javie, ale później nowe rzeczy będą szły znacznie szybciej i będą lepiej wykonane – jestem o tym przekonany!

Podsumowanie

Czasu i pracy poświęconych na poznawanie i naukę Android Studio, javy i androida od jego naturalnego środowiska nie żałuję , wręcz przeciwnie – uważam to za świetny epizod. Mam teraz pewny ogląd na te technologie, a wcześniej nie miałem o nich zielonego pojęcia. Teraz czas na kolejny (mam nadzieję, że dłuższy) epizod – XAMARIN bejbe!

IMAG0008

A tu foto mojego miejsca w domu gdzie zaczynam naukę Xamarin’a 🙂

Pjona!