Rozpoznawanie kategorii i koloru z tekstu ogłoszenia oraz pierwsze testy jednostkowe w Asp.Net Core 1.0

Siemanko

Jak już wcześniej wspominałem aplikacja mobilna nie będzie wymagała deklarowania kategorii czy koloru ubrania w momencie tworzenia nowego ogłoszenia. Niewątpliwie te dane byłyby bardzo przydatne w celu filtrowania wyników wyszukiwania oraz przy Machine Learning, które miałoby ogarniać najchętniej przeglądane ciuchy przez użytkownika w celu podpowiadania mu tego co mogło by go zainteresować (jeszcze nie ruszyłem z ML, ale mam to w planach ;)). Tą robotą zajmie się system.

Słowniki ze słowami kluczowymi dla kategorii i koloru

Wyrażenia regularne nie wchodzą w grę ponieważ nazwy kategorii i kolorów są przeróżne, więc dla każdej opcji musiałbym napisać oddzielne wyrażenie co przy późniejszej potrzebie modyfikacji okazało by się, że to niezły pain (nie wkurzają Cię te moje angielskie bądź pseudo angielskie wcinki? ;)). Dlatego wymyśliłem to najprościej jak mogłem i opiszę to na przykładzie kategorii.

2

Fragment słownika kategorii

Kluczem jest początek nazwy kategorii, a wartością lista słów pasujących do wzorca z klucza wraz z różnymi odmianami, przy czym pierwszym elementem jest zawsze słowo kluczowe, które będzie wiązane z ogłoszeniami. Taki słownik będę mógł zawsze zmodyfikować dodając kolejne klucze bądź rozszerzając listy wartości dla klucza. Jedynym ograniczeniem będzie tylko to, że nie będę mógł zmienić pierwszych elementów z list wartości bo te będą mogły być już zapisane w bazie.

Rozpoznawanie kategorii i koloru

Najlepiej będzie jak rzucisz okiem na kod.

3

Lecę foreach’em po kluczach danego słownika i sprawdzam czy zawiera się on w tekście ogłoszenia. Jeśli tak to lecę kolejnym foreach’em po wartościach dla danego klucza i sprawdzam czy którykolwiek ze stringów znajduje się w tekście. Jeśli tak to do listy wynikowej przypisuje pierwszy element z listy wartości. W ten sposób wyłapuje hasła kluczowe, które potem są wyciągane z bazy lub zapisywane jeśli jeszcze takich nie było, a następnie wiązane z ogłoszeniem.

Side Waffle, XUnit i Moq – czyli ostre testowanko 😉

Aby sprawdzić czy to co opisałem wcześniej rzeczywiście działa postanowiłem wreszcie napisać pierwsze unit testy. Do tego celu doinstalowałem sobie do VS extension’a Side WaffleJest to paczka z ogromem różnych templatów, o których nie będę pisał prócz jednego – xUnit.

3

Jest to już skonfigurowany pod DNXa projekt testowy z xUnit. Od razu można jechać z testami. Co bardzo ważne – aby uruchomić napisany test trzeba otworzyć Test Explorer’a i zbudować projekt – w innym przypadku VS nie ogarnie, że są jakieś testy.

4

Przykładowy teścik

Nie jestem jakimś szpeniem od testów, ale dzięki dobrociom od xUnit takim jak [Theory], pisząc 18 testów w rzeczywistości mam przetestowane 83 przypadki.

Podsumowanie

Dzięki testom jednostkowym dla rozpoznawaczki słów kluczowych wyłapałem kilka błędów już na etapie jej pisania, które szybciutko poprawiłem 🙂

Unit testy są cool!

Pjona!

Reklamy

Dodawanie nowego ogłoszenia w Mobile Second Hand

Siemanko

Widziałeś/aś już jak się będzie można w apce mobilnej zalogować do systemu (tak, do systemu bo aplikacja mobilna w projekcie to tylko klient), jak wygląda teraz (mocno dewelopersko) lista ogłoszeń więc teraz czas pokazać jak wygląda i działa na tę chwilę tworzenie nowego ogłoszenia wraz z dodaniem go do systemu.

IMAG0037

Tworzenie nowego ogłoszenia w aplikacji mobilnej

Na powyższym zdjęciu widzisz listę ogłoszeń. W prawym dolnym rogu jest widoczny tzw. FAB. Przycisk który przy przewijaniu listy jest cały czas w tym samym miejscu (btw. można zrobić tak aby przy przewijaniu w dół znikał i pojawiał się po powrocie na początek listy, ale nie o tym). Pewnie się domyślasz do czego służy? 🙂 Po kliknięciu przechodzimy do tworzenia nowego ogłoszonka.

IMAG0038

Tadam. Oto formularz do nowego ogłoszenia. Elementy (kontrolki) do wprowadzania danych umieściłem na scroll’owalnym layoucie, dzięki czemu nie ogranicza mnie wysokość ekranu oraz intuicyjnie przesuwając w dół użytkownik przejdzie do końca formularza.

IMAG0039

Kolejny babol w designerze Xamarin’a

Wspominałem już w wcześniejszych postach o nierenderujących się komponentach w designerze (np. guzik do logowania z facebookiem czy FAB). Mam kolejnego babola. W designerze nie podejrzysz kontrolek, które nie mieszczą się na widoku, a są faktycznie na layoucie (mimo iż przesuniesz pasek scrolla)

1.jpg

Także zostaje tylko xml i „kodowe” dodawanie i ustawianie widoków. Oczywiście po starcie apki na telefonie widok jest scroll’owalny.

Pola formularza

Które pole do czego to chyba się orientujesz z opisów 🙂 Pokrótce:

  • tytuł główny, który będzie widoczny na liście ogłoszeń
  • dodatkowe informacje gdzie można się rozpisać, a te będą widoczne na detalu ogłoszenia (po wejściu na niego z listy)
  • cena bez częsśi dziesiętnych
  • pola radio do określenia jaka forma pozbycia się ciucha interesuje użytkownika, a ta z kolei będzie umieszczona jako jakaś ikonka na liście ogłoszeń
  • zdjęcie – oczywiście robione z poziomu aplikacji. Na razie tylko jedno, ale w kodzie zostawiłem sobie furtki aby można było robić i dołączyć kilka zdjęć
  • znów pola radio, tym razem do określenia czy do ogłoszenia ma być dołączona lokalizacja aktualna czy domowa zapisana w ustawieniach (np. wystawiam ogłoszenie u koleżanki, ale zaraz wracam do domu 30 km i tam będę przesiadywał ;))
  • guzior do opublikowania ogłoszenia

W momencie naciśnięcia guzika do publikacja sprawdzam czy wszystkie pola zostały wypełnione oraz czy zostało zrobione zdjęcie. Jeśli tak to idą requesty do serwera. Najpierw jeden ze zdjęciem, a po udanym zapisie drugi z modelem. To jak to ogarniam na serwerze jest tematem na jeden z kolejnych wpisów.

Podsumowanie

W ramach podsumowania przejdziemy razem przez proces dodawania ogłoszenia 🙂

  • wypełniamy formularz i robimy zdjęcie

IMAG0047

IMAG0040

  • naciskamy guzik „OPUBLIKUJ” i czekamy sekundkę, aż się wszystko zapisze

IMAG0042

  • po wszystkim jesteśmy przeniesieni z powrotem na listę ogłoszeń, gdzie możemy podziwiać nasze nowoutworzone ogłoszenie i czekać na kontakt od chętnego kupującego (kontakt także będzie się odbywał w aplikacji) 🙂
IMAG0045

0 km ponieważ się nie ruszyłem 😉 Jednak gdybym odszedł i odświeżył listę zobaczyłbym ile dzieli mnie do miejsca, w którym opublikowałem ogłoszenie.

Pjona!

Xamarin’owa apka doprowadzona do stanu jaki prezentuje w Android Studio.

Siemanko.

Dziś króciutko.

W dniu dzisiejszym udało mi się doprowadzić aplikację mobilną do stanu jaki prezentowała w Android Studio w momencie podjęcia decyzji o przesiadce na Xamarin’a, więc nareszcie będę mógł jechać z nowymi tematami. Nie zliczałem czasu, ale szacuję, że zajęło mi to ok 20 godzin. Biorąc pod uwagę, że nie miałem wcześniej z Xamarin’em nic wspólnego to myślę, że to dobry wynik, a przyjemność jaką sprawia mi pisanie w nim jest o wiele większa niż w Android Studio. Ostatnie posty nie dotykały funkcjonalności rozwijanych w projekcie dlatego pozwolę sobie przypomnieć Ci co jest zrobione i za co zabieram się od jutra (dziś już dość kodzenia ;)).

Jest zrobione (zarówno po stronie aplikacji mobilnej jak i na serwerze):

  • autentykacja za pomocą tokena JWT (logowanie/rejestracja za pomocą formularza lub facebooka)
  • ustalanie lokalizacji w aplikacji mobilnej
  • pobieranie listy ogłoszeń na podstawie lokalizacji użytkownika uderzającego do API z uwzględnieniem zadeklarowanego przez niego obszaru z jakiego chce zobaczyć ogłoszenia (na podstawie zadeklarowanego promienia – wszystko wyliczam na serwerze)
  • tworzenie nowego ogłoszenia wraz ze zdjęciem i zapis do bazy na serwerze co skutkuje natychmiastowym pojawieniem się ogłoszenia w systemie

Co będzie robione:

  • predefiniowane hasła kluczowe dotyczące rodzaju ubrania (np. sukienka, bluzka itp.) oraz koloru, które będę wyłapywał na serwerze z tytułu i opisu ogłoszenia aby następnie je powiązać z sobą powiązać. W aplikacji nie będę wymagał wybierania ręcznego kategorii, itp. jak to jest np. na Allegro. Ma to być maksymalnie proste dlatego przypisywaniem haseł zajmie się system.
  • pobieranie listy ogłoszeń z zawężeniem do predefiniowanego hasła (np. tylko ogłoszenia ze spodniami)
  • powiadomienia w tle o pojawieniu się nowych ogłoszeń w zadeklarowanym przez usera obszarze
  • wyświetlanie szczegółów ogłoszenia po kliknięciu go na liście
  • komunikacja między użytkownikami systemu (kupujący – sprzedający)

Podsumowanie

Cieszę się, że będę już mógł pracować nad nowymi rzeczami, a nie odgrzewać stare kotlety ;). Jeśli Ty też się cieszysz moim szczęściem to daj feedback ;). A jeśli nie – to nie ;p

Pjona!

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!

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!

Kilka słów o EF Core 1.0

Siemanko.

Dziś troszkę o EF Core 1.0 (EF 7 do niedawna), które wykorzystuję w projekcie Asp.Net Core jako część backend’u dla aplikacji mobilnej Mobile Second Hand. Troszkę, bo nie poznałem jeszcze wszystkich nowości w tej wersji Microsoft’owego ORM’a i to co dziś przeczytasz będzie to głównie opis największych różnic między w.w. wersją, a poprzednią czyli EF6.

Gotowiec Entity Framework Identity.

Jak kiedyś wspomniałem, projekt Asp.Net Core założyłem z wbudowanego w Visual Studio template’a – Web Aplication – z zaznaczoną opcją Individual User Accounts co skutkuje tym, że z automatu jest skonfigurowany dostęp do danych wraz z obsługą autentykacji. Wystarczy tylko w pliczku appsettings.json głównego projektu wpisać connection string do bazy, z którą chcemy pracować. W moim przypadku:

q

Tak jak w poprzedniej wersji Entity Framework, jeśli baza podana w connection stringu nie istniała, wystarczyło utworzyć nowy obiekt DbContext’u aby ORM tę bazę utworzył, dlatego poszedłem tym samym tropem – utworzyłem obiekt Usera i spróbowałem zapisać. Niestety ku mojemu zdziwieniu nic z tego nie wyszło. Dostawałem wyjątek, że EF nie może się zalogować do serwera bazy danych z wykorzystaniem poświadczeń podanych w connection stringu. Było to tym bardziej frustrujące bo logowanie do SQL’a mam domenowe i tak też podałem w connection stringu. Po pewnym czasie i paru chujach skierowanych w stronę monitorów doszedłem do tego, że trzeba się ręcznie upewnić o istnieniu bazy i wtedy EF Core ją utworzy jeśli jej nie ma. Należy to zrobić wpisując jedną linijkę na końcu metody Configure w klasie Startup.cs.

2

Oczywiście context to nazwa parametru dla DbContext’u aplikacji jaki przyjmuje metoda Configure (dlatego równie dobrze może być dupa.Database.EnsureCreated()), a owy DbContext jest wstrzykiwany z użyciem Dependency Injection.

Brak Initializer’ów.

W poprzedniej wersji EF do współpracy z DbContext’em były definiowane i wykorzystywane tzw. Initializer’y. To one określały co ma się dziać z bazą danych. I tak:

  • CreateDatabaseIfNotExists – tworzył bazę gdy jej nie było – dlatego w poprzedniej wersji EF baza była z automatu tworzona gdyż ten Initializer był domyślny
  • DropCreateDatabaseIfModelChanges – usuwał i tworzył bazę gdy uległ zmianie, którykolwiek z modeli podanych w DbSet’cie
  • DropCreateDatabaseAlways – za każdym uruchomieniem aplikacji i jej pierwszym odwołaniu się do bazy ta była usuwana i tworzona na nowo
  • CustomDbInitializer – możliwość napisania swojego gdy żaden z powyższych nie odpowiadał (np. migracja do najnowszej wersji bazy w przypadku korzystania z ręcznych migracji)

Oczywiście wykorzystując te initilizer’y mogliśmy wypełniać bazę jakimiś danymi, ale to było w poprzedniej wersji. Teraz są tylko ręczne migracje.

Tylko ręczne migracje

W poprzedniej wersji mogliśmy nie korzystać z migracji, włączyć automatyczne migracje bądź ręcznie migrować schemat bazy. Teraz nie ma takiego wyboru i jedynym dostępnym sposobem do obsługi schematu bazy są ręczne migracje. Migracjami operujemy z poziomu command line’a. W projekcie głównym muszą być zainstalowane EntityFramework.Commands, aby można było ich używać w wierszu poleceń (w gotowej aplikacji z template’a już wszystko jest). Jeśli masz w solucji kilka projektów to musisz pamiętać aby za pomocą cd przejść do projektu głównego, gdzie są zainstalowane EntityFramework.Commands oraz koniecznie wpisać dnvm use 1.0.0-rc1-final (póki jest jeszcze wersja RC1 frameworka Asp.net Core) bo zacznie sypać wyjątkami, jeśli spróbujesz korzystać z komend EF np. dnx ef –help.

Podsumowanie

Tak jak wspomniałem we wstępie to tylko pierwsze spojrzenie na nową wersję EF. Jeśli jesteś ciekaw jak od zera dodać do projektu nowe EF to odwiedź matczyną stronę Asp.Net Core gdzie jest wszystko elegancko opisane.

W niedzielę napiszę o pierwszych walkach z Xamarinem ponieważ jak możesz się dowiedzieć z poprzedniego postu porzuciłem projekt w Android Studio i zaczynam od zera w Xamarinie.

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!