Lista ogłoszeń w aplikacji Mobile Second Hand – cz. 3.

Siemanko.

Dziś trzeci i zarazem ostatni wpis w tej serii dotyczącej tylko i wyłącznie części androidowej projektu, a konkretnie listy ogłoszeń. Sama lista nie jest jeszcze skończona i będę pracował nad nią nadal, ale dla zachowania parytetu między technologiami użytymi w projekcie staram się dzielić wpisy między owe technikalia. Zgodnie z zapowiedzią we wcześniejszym poście, dziś przybliżę nieco w jaki sposób ustalam lokalizację oraz jak pakuję zdjęcie z tablicy bajtów na widok. Z ogłoszeń parafialnych to wraz z nadejściem wiosny, mimo iż dzień dłuższy to czasu na klepanie w domu mam niestety mniej (sezon ligowy, sezon ogarniania podwórka, itp. ;)). Jednakże staram się jak mogę aby ciągnąć do przodu. Jako inną ciekawostkę przytoczę to, że zamówiłem sobie dwie książki do nauki androida. Jedna z serii „Head First” na temat programowania (tak na marginesie bardzo lubię tę serię i szczerze polecam) oraz jakąś na temat filozofii UI w aplikacjach androidowych. To tyle z ogłoszeń. Jedziemy z tematem.

GoogleApiClient i LocationManager

Z tego co wiem na tę chwilę to lokalizację telefonu można uzyskać dwojako. Za pomocą GoogleApiClient dostarczanego przez Google Play Services oraz za pomocą LocationManager wbudowanego w system androida. Jeśli chodzi o klienta google to jest on rekomendowany na stronie androida w sekcji treningu dotyczącej lokalizacji. Na pewno wymaga niewiele naszego kodu jednakże ja mam jakieś mieszane odczucia (może dlatego, że bawiłem się tym na samym początku gdy jeszcze moja znajomość androida była mikroskopijna?) bo miałem jakieś problemy z pobraniem lokalizacji. Szukając innych sposobów znalazłem właśnie rozwiązanie systemowe. Nie będę ukrywał, że implementacje jego wykorzystania zerżnąłem ze stacka, ale ważne że mniej więcej wiem o co kaman ;). W celu pobrania lokalizacji musimy w pliku AndroidManifest.xml dodać uses-permission dotyczące lokalizacji. „uses-permission” to wpisy, które informują system o tym do jakich modułów telefonu aplikacja ma mieć dostęp (sam to sobie tak tłumacze, ale może się mylę).

1

Jadąc od góry:

  • lokalizacja na podstawie sieci (stacje bazowe)
  • lokalizacja na podstawie sieci (stacje bazowe) i wi-fi
  • lokalizacja full wypas z powyższymi oraz z gps

Bez tych wpisów aplikacja się sypnie jeśli będziemy pytali o lokalizację. Ze względu na sporą ilość kodu serwisu GpsLocationService (tak go nazwałem) nie będą tutaj się więcej rozpisywał, ani wklejał screenów. Wszystko możesz oblukać w repo. Dodam tylko, że jest także obsłużona sytuacja gdy proszę o lokalizację, a tel ma wyłączony gps – wtedy wyświetlam monit z pytaniem czy user chce przejść do ustawień aby włączyć gps.

BitmapOperationService

Jak wiesz z poprzedniego wpisu zdjęcia ogłoszeń przesyłam jako tablice bajtów. Tę tablicę bajtów przerabiam na bitmapę w serwisie BitmapOperationService i łąduję ją do ViewImage poprzez setImageBitmap().

2

Jak widzisz oprócz tablicy bajtów (MainPhoto) do serwisu przekazuję także szerokość oraz wysokość ImageView, które znajduje się na fragmencie. Przekazuję wymiary po to aby wyskalować fotkę do wymiarów kontrolki. Jeśli jesteś ciekawy w jaki sposób to ponownie zapraszam do repo.

AdvertisementItemListActivityService

Po zmianie orientacji telefonu (nie, nie seksualnej) Activity czyli widok ulega zniszczeniu (nie jestem pewien czy całkowitemu) i zabawa zaczyna się od początku – czyli wywołanie metody onCreate(), ładowanie layout’u, kontrolek, danych itp. czyli wszystko zaczyna się od nowa w nowej konfiguracji urządzenia (czyli zmianie wymiarów ekranu). W przypadku mojej listy ogłoszeń wiązało się to z wysłaniem request’u do serwera, przeparsowaniu odpowiedzi na javove obiekty i ustawianiem adaptera. Ogólnie działo się to co przy pierwszym odpaleniu widoku z listą. Oczywiście nie było to przeze mnie pożądane działanie. Tuż przed zmianą konfiguracji urządzenia (czyli np. zmiana orientacji (też nie seksualnej) telefonu) można nadpisać metodę onSaveInstanceState(Bundle outState). Jeśli wpiszemy coś do obiektu Bundle poprzez jedną z jego metod put….(), możemy to potem wyciągnąć z Bundle przy starcie Activity w jej metodzie onCreate(Bundle savedInstanceState). Jednakże w ten sposób możemy wpisać tylko typy proste (string, int, bool, itp.). Dlatego tez zrobiłem sobie statyczny singleton AdvertisementItemListActivityService, w którym zapisuję listę ogłoszeń znajdującą się aktualnie w adapterze. W metodzie onCreate() odczytuje z serwisu zapisane obiekty i przekazuję je adapterowi. W ten sposób uniknąłem ponownego pobierania tych samych danych, a widok jest w tym samym miejscu listy ogłoszeń.

3

Metoda wywoływana tuz przed zmianą konfiguracji urządzenia

4

Kod w metodzie tworzącej activity. 

Podsumowanie

Zostało mi tu do ogarnięcia jeszcze page’owanie do infinity scrolla, który opisałem we wcześniejszym poście, oraz przejście do widoku detalu po kliknięciu na dane ogłoszenie. Oczywiście zostaje jeszcze kwestia ubrania tego wizualnie, ale najpierw ma działać, a później wyglądać. W następnych postach wracam do Asp.Net Core 1.0. O czym bedzie? No chyba coś o Entity Framework Core wypadałoby napisać 😉

Pjona!

Reklamy

Lista ogłoszeń w aplikacji Mobile Second Hand – cz. 2.

Siemanko.

Dziś druga część informacji na temat listy ogłoszeń w aplikacji mobilnej. Z poprzedniej części dowiedzieliście się, że skorzystałem z Fragment (List) – template’u  wbudowanego w Android Studio do generowania listy elementów widoku – który przerobiłem po swojemu. W tej części o tym jak go dostosowałem do swoich potrzeb.

Pobieranie ogłoszeń.

W metodzie onCreateView() activity (klasy) AdvertisementItemFragment będącej fragmentem (pojedyńczym elementem listy czyli ogłoszeniem) następuje wywołanie metody getAdvertisements(). Metoda ta, wywołuje serwis do pobierania ogłoszeń przekazując jego metodzie model ze współrzędnymi lokalizacji telefonu, z którego jest wysyłany request (o pobieraniu lokalizacji w następnym poście). Po co wysyłam współrzędne? To jest właśnie główny pomysł na tę aplikację – kojarzenie ze sobą ludzi w celu wymiany/sprzedaży ubrań w zadeklarowanym przez nich samych obszarze :). Wspomniany serwis z wykorzystaniem biblioteki Android Asynchronous Http Client (opisałem ją krótko w tym poście) uderza do WebApi w Asp.Net. W odpowiedzi dostaję jsona z listą ogłoszeń. Przy pomocy biblioteki Gson (którą również opisałem krótko w tym poście) parsuje stringi na javove obiekty ogłoszeń.

1

Parsowanie odpowiedzi (jsona) na obiekty javove z wykorzystaniem Gson.

Skrócony model ogłoszenia.

Aby nie pobierać całych ogłoszeń ze wszystkimi danymi, których i tak nie byłoby gdzie wyświetlić na liście (przy zachowaniu przejrzystości), zrobiłem skrócony model ogłoszenia do obsługi listy ogłoszeń.

2

Model ogłoszenia do wyświetlania na liście ogłoszeń

Modelu chyba nie muszę tłumaczyć poza polem Distance – jest to przybliżona odległość między użytkownikiem przeglądającym ogłoszenie, a autorem ogłoszenia w momencie jego utworzenia (wyliczona na serwerze). Zdjęcie przysyłam jako tablice bajtów (główne zdjęcia ogłoszeń, które mają być tzw. miniaturkami zmniejszam na serwerze w momencie zapisywania nowego ogłoszenia) i tu mam dla Was tipa co byście się nie musieli frustrować tak jak ja. Przy korzystaniu z Gsona’a do parsowania tablicy bajtów z jsona na obiekt javovy należy zadbać o to aby przy zwracaniu odpowiedzi z WebApi w Asp.Net skorzystać z JavaScriptSerializer i dane z kontrolera wypuścić jako string. Tablica bajtów zwracana przez wbudowany w Asp.Net Core 1.0 WebApi parser danych do jsona jest interpretowana (po stronie Androida) przez Gson jako ciąg znaków (string), a nie tablica bajtów.

Tak przygotowaną listę obiektów ładuję do ViewAdpatera.

3

Parsowanie odpowiedzi w formacie json na listę obiektów javovych oraz ustawianie ViewAdaptera .

Obsługa ViewAdaptera i customowy infinite scroll

ViewAdapter jest odpowiedzialny za wyświetlanie fragmentów. W metodzie onBindViewHolder(), która jest wywoływana tuż przed każdym wyświetleniem fragmentu, ustawiam wartości poszczególnych kontrolek widoku fragmentu odpowiednimi wartościami z modelu ogłoszenia.

4

Bindowanie danych z modelu ogłoszeń do kontrolek widoku fragmentu.

Holder to kasa, która trzyma referencje do kontrolek znajdujących się na widoku fragmentu. Jeden fragment na liście – jeden holder. Na powyższym screenie tuż przed zamykającym nawiasem klamrowym widać wywołanie metody:

checkIfThisItemIsLastAndRaiseOnInfinityScroll(holder, position)

Jest to mój pomysł na infinite scroll. W metodzie tej, sprawdzam index bindowanego obiektu ogłoszenia i porównuje go z długością listy wszystkich obiektów aktualnie znajdujących się w ViewAdapter’ze. Jeśli index jest ostatni to wywołuje odpowiednią metodę listenera, która odpala pobieranie danych.

5

Moja implementacji infinite scroll’a w ViewAdapterze.

Jak widać, zmienne lastHolder i lastPosition przechowują dane ostatnich elementów przed wywołaniem infinite scrolla, w celu doklejenia nowych danych do istniejącej listy bez zmiany widoku.

Screenshot_2016-03-23-18-16-03.png

Po doładowaniu danych użytkownik przegląda listę dalej od tego samego miejsca, w którym zaczęło się doładowywanie. Oczywiście będę musiał dopisać jakąś logikę dotyczącą pobierania danych wywołanych przez zdarzenia infinite scroll’a (jakiś paging itp.), ale to przecież się wciągnie noskiem 🙂

W następnej i ostatniej części opiszę co nieco jak ustalam lokalizację oraz jak ładuję fotkę z tablicy bajtów na widok.

Także Stej In Tacz!

Pjona!

Lista ogłoszeń w aplikacji Mobile Second Hand – cz. 1.

Siemanko.

Dzisiaj znów wracamy do części androidowej projektu. Ostatnio skupiłem się nad zwróceniem z serwera listy ogłoszeń z konkretnego obszaru wokół obecnej lokalizacji użytkownika (w sumie core aplikacji), przeparsowaniu jsona na Javove obiekty ogłoszeń i w końcu wyświetlenie ich na ekranie. Oto pierwszy „ładniejszy” efekt pracy. W tej serii (dwa lub trzy wpisy) postów skupię się tylko i wyłącznie nad częścią androidową. Pobieranie ogłoszeń z bazy oraz zwracanie ich z serwera opiszę w kolejnej serii.

WP_20160323_18_16_16_Pro

Zdjęcie prezentuje odpaloną aplikację na telefonie oraz rozlaną kawę na podkładko/notatniku.

Fragment i ViewAdapter.

Wiadomym dla mnie było, że ogłoszenia muszą być wyświetlane na scroll’owalnej liście. Tylko jak się do tego zabrać? Jak to jak?! Jak każdy szanujący się Full StackOverflow Developer zacząłem od grzebania w internecie 😉 Szybkie przetwarzanie informacji i już wiadomo, że do tego służą m.in Fragmenty i ViewAdaptery.

Fragment, to jak sama nazwa wskazuje, osobny byt reprezentujący jakiś element.

1

Screen z designera w Android Studio.

Na powyższym zdjęciu widoczne jest Activity (dziedziczące po Fragment) zawierające layout do prezentowania jednego ogłoszenia. W połączeniu z ViewAdapterem tworzy się lista takich fragmentów.

2

Screen z designera w Android Studio.

Ogólnie rzecz ujmując ViewAdapter zajmuje się wyświetlaniem elementów z kolekcji, którą mu przekażemy.

W najprostszy sposób taką listę można zrobić korzystając z gotowca wbudowanego w Android Studio (kolejny raz propsuje Android Studio i jego template’y).

3

Dodawanie template’u listy fragmentów do projektu w Android Studio.

Po wybraniu Fragment (List) do projektu wpadają dwa (dwie?) Activity (pliki .java z kodem i .xml z widokami), oraz klasa DummyContent.java, której obiekty będą wyświetlane na liście. Oczywiście template generuje dużo kodu do tworzenia fake’owych (DummyContent) obiektów, ładowania ich do adaptera, wyświetlania itp.. Jest to super punkt wyjścia do własnej implementacji. Ja oczywiście sporo zbędnego kodu pokasowałem i zaimplementowałem swoje rozwiązanie. Jakie? O tym w następnej części już w niedzielę.

Na koniec jeszcze jeden screen apki z telefonu:

Screenshot_2016-03-23-18-15-43

Screen aplikacji z małą czarną:)

Pjona!

 

MobileSecondHand – autentykacja po stronie serwera cz. 2.

Siemanko.

Dzisiaj druga część o autentykacji po stronie serwera. W części pierwszej napisałem, jak wygląda proces autentykacji za pomocą tokena, a dziś o tym jak i kiedy go generuje.

Przy tworzeniu nowej aplikacji webowej Asp.Net Core 1.0 z template’u w VS 2015 z automatu jest zaznaczona opcja indywidualnych kont użytkowników w sekcji autentykacji. Skutkuje to dodaniem do projektu paczki „Microsoft.AspNet.Identity.EntityFramework” (wraz z zależnościami), utworzeniem pierwszej migracji z tabelami związanymi z userami, oraz kontrolerów ze wstępnymi logikami do rejestracji, logowania i zarządzania kontem użytkownika. Żeby nie wywarzać otwartych drzwi oczywiście skorzystałem z tych dobrodziejstw w moim projekcie (po swojemu). Także przy tworzeniu oraz szukaniu usera w bazie korzystam z wbudowanych serwisów UserManager<T> oraz SignInManager<T>. Za pomocą ich metod mogę zapisać użytkownika do bazy, pobrać go, sprawdzić czy hasło jest prawidłowe itp.. Ogólnie sporo roboty do przodu.

Rejestracja i logowanie standardowe.

Rejestracja i logowanko sprowadza się do odebrania view modelu, wywołania odpowiednich metod z wcześniej wspomnianych serwisów i zwróceniu tokena.

1

2

3

Na ostatnim screenie jest metodka tworząca i zwracająca token. Odpowiedzialny za całe zamieszanie jest JwtSecurityTokenHandler z przestrzeni nazw System.IdentityModel.Tokens.Jwt.

Rejestracja i logowanie z facebookiem

Token autentykacji od fejsa pobieram w apce mobilnej i opisałem to w tym poście. Następnie token ten wysyłam na serwer gdzie napisałem sobie web clienta, który uderza do api facebooka w celu pobrania adresu emial potrzebnego do identity aplikacji serwerowej. Jednocześnie sprawdzana jest ważność facebook’owego tokenu. Cała klaska na dzień dzisiejszy wygląda tak:

4

Odpowiedzią api facebook’a jest oczywiście Json’ik. Parsuje go na swój obiekt odpowiedzi za pomocą JavaSrciptSerializer  z assembly System.Web.Exensions (bardzo fajna sprawa, rozwiązał mi problem błędnego parsowania tablicy byte’ów po stronie aplikacji mobilnej o czym w następnym poście). Swój obiekt odpowiedzi puszczam dalej i dzieje się to samo co na wcześniejszych screenach.

Pobieranie UserId z tokena

Po wpuszczeniu użytkownika do kontrolera przez JtwBearerTokenMiddleware wyciągam id usera z obiektu Identity  dostępnego przez wpisane User.Identity w kontrolerze. Do tej operacji napisałem serwisik zwracający mi id usera.

5

Podsumowanie

Autentykacja na takim poziomie jakim jest teraz w zupełności mi wystarcza aby w jak najmniejszym stopniu obciążać usera podawaniem swoich danych podczas korzystania z apki. W następnym poście wracamy do części androidowej i pobawimy się trochę z ogłoszeniami, czyli przeznaczeniem całego projektu :).

Pjona!,

MobileSecondHand – autentykacja po stronie serwera cz. 1.

Siemanko.

Dziś troszkę o tym jak rozwiązałem autentykację po stronie serwera (bo jest już zrobiona i działa). Post podzieliłem na dwie części coby mieć o czym pisać później bo ku mojemu zaskoczeniu (samym sobą? ;p) projekt idzie mi całkiem nieźle bo właśnie na chwilę przed rozpoczęciem pisania tego postu skończyłem klepać prototyp tworzenia nowego ogłoszenia po stronie telefonu, wysłania go na serwer, zapisania do bazy, i w końcu zwracania listy prawdziwnych ogłoszeń (bez hardcodu) oraz wyświetlenia jej w apce 🙂 Yeah!.  Są to oczywiście prototypy, które będę musiał przepisać porządnie, ale na razie skupiam się na funkcjonalnościach by dopieszczać je już działające.

Tyle słowem wstępu. Wracamy do tematu.

JWT Bearer Token

Projekt po stronie Asp.Net zakłada tylko WebApi do kumunikacji z aplikacją mobilną dlatego wiadomym dla mnie było, że autentykacja będzie realizowana przez token. Przyznam, że w mojej niedługiej karierze nie korzystałem jak dotąd z tokenów, dlatego właśnie postanowiłem to nadrobić. Zasadę działania autentykacji opartej na tokenie mniej więcej znałem z „telewizji”, ale nie wiedziałem od czego zacząć implementację, dlatego zacząłem typowo – google -> asp.net 5 token authentication -> enter -> trach, poszło. Przestudiowałem kilka artykułów, kilka stron i wybór padł na JWT Bearer Token. Dlaczego? Bo prosta implementcja, która sprowadziła się praktycznie do dopisania do dependencies w pliku project.json projektu startowego linijeczki:

„Microsoft.AspNet.Authentication.JwtBearer”: „1.0.0-rc1-final”

ctrl + s, bach, trach poszło, Jwt jest w projekcie. Następnie w klasie Startup projektu startowego odbywa się konfiguracja. W metodzie CofigureServices wpis:

aut1

Następnie w metodzie Configure:

aut2

Gdzie tokenAuthorizationOptions to obiekt konfiguracyjny z kluczem szyfrującym (RsaSecurityKey), który jest wczytywany z pliku i musi być zawsze ten sam dla aplikacji. Ja wstrzykuje sobie ten obiekt przez dependency injection.

Koniec konfiguracji. Teraz wystarczy opatrzeć metodę kontrolera lub cały kontroler atrybutem:

[Authorize(„Bearer”)]

i nie ma takiego wchodzenia na serwer bez tokenika! 😉 Uderzając z PostMan’a do aplikacji bez podania odpowiedniego nagłówka dostaniemy 401

aut3

jeśli uderzymy z nagłówkiem (o tworzeniu tokena w następnej części czyli w niedzielę):

Authorization: Bearer (token – ciąg znaków)

to jesteśmy wpuszczani do kontrolera.

Jwt Bearer middleware robi cała robotę. Z małym ale..

Bug w JWT Bearer midlleware w Asp.Net Core 1.0 rc1-final

Jeśli uderzamy bez tokena to spoko, jak było widać wcześniej dostajemy 401. Jeśli jednak uderzymy z nagłówkiem i token będzie błędny lub nieważny to dostaniemy 500!

aut5

aut4

Ogólnie to nie wiedziałem o co kaman bo przecież działało!

monkey

Po pewnym czasie dogoglowałem się do issue na githubie. A więc na szczęście to nie tylko u mnie 🙂 Można to obejść pisząc swoje middleware tuż przed JWTmiddleware na pipeline, które łapie w try catch następne wywołanie. W catchu złapie się ten wyjątek i po sprawdzeniu czy wyjątek jest tym, który nas interesuje, możemy zwrócić 401 (na screenie jeszcze nie dopisałem rozróżniania jaki to wyjątek dlatego jest samo Exception, a powinny być te związane z walidacją tokena):

aut6

Podsumowanie części 1

Poza tym bugiem to wydaje się być wszystko ok. Najważniejsze, że problem został rozwiązany, a o to przecież chodzi w naszym fachu 😉 Gdyby to miała być biznesowa aplikacja to na pewno bym nie skorzystał z JWT z bugiem, ale skoro to ma być apka, która zapewne nie zawita nigdy na google play (no chyba, że dla jaj) to co tu się szczypać!;)

W niedzielę część 2.

Pjona!

 

MobileSecondHand – pierwsze widoki i funkcjonalności związane z autentykacją.

Siemanko.

Niedzielny wieczór więc pora skończyć kodzenie na dziś i naklepać trochę tekstu, którego nie da się skompilować 😉

Dziś trochę o starcie aplikacji i związanymi z tym faktem działaniami. Na zdjęciu wyżej widać ekran startowy. Prosty widok fullscreen z polem tekstowym i spinnerem, który ma dla bajeru pokazywać, że coś się w tle dzieje 🙂 Jako, że założenia aplikacji nie uwzględniają użytkowników anonimowych (żeby coś wystawić, lub żeby się skontaktować z właścicielem ogłoszenia to i tak trzeba będzie mieć konto) dlatego na dzień dobry po uruchomieni apki sprawdzam czy user jest zalogowany.

1

Autentykacja bazuje na tokenie, dlatego :

  • sprawdzam czy aplikacja ma zapisane w czymś co się nazywa SharedPreferences (to jest jakieś miejsce w pamięci przydzielone przez Android dla każdej z aplikacji – a przynajmniej tak mi się wydaje :)). Jest to kolekcja elementów klucz – wartość, czyli słownik. Jeśli wartość wyciągnięta z tego słownika jest różna od nulla tzn., że coś tu było działane i user może być zalogowany, ale token może być już przeterminowany dlatego uderzam na serwer.
  • jeśli nie ma w SharedPreferences tokena tzn., że jest to pierwsze uruchomienie apki po zainstalowaniu. MobileSecondHand – jak każda szanująca się apka 😉 – umożliwia zalogowanie przez facebook’a. Do tego wykorzystałem po stronie androida gotową biblioteczkę przygotowaną oczywiście przez facebook’a. Sprawdzam czy user logował się już do apki przez fejsa co sprowadza się do poproszenia o AccesToken. Jeśli jest różny od nulla to idzie na serwer i tam dokonuje się cała robota, a zwracany jest świeżutki bearer tokenik, który ląduje we wcześniej wspomnianych SharedPreferences . Jeśli jest nullem to ręcznie zwracam status 401 do activity, w którym wszystko się zaczęło, co jest informacją, że user musi się zalogować.2

WP_20160313_17_14_17_Pro

Wyżej widok logowania. Jak widać można to zrobić dwojako. Loginem i hasłem lub przez facebook’a. Jeśli standardowo to po prostu na serwer idzie POSTem model do logowania (już za chwilę opiszę jak obsługuje komunikację z serwerem). Jeśli user nie ma jeszcze konta i nie ma też facebook’a, może przejść do prostego widoku rejestracji.

WP_20160313_17_15_23_Pro

Tutaj to samo. Wypełnić, kliknąć i idzie model na serwer, a wraca token autentykacji.

Jeśli jednak w sytuacji gdy user nie ma konta, ale ma facebook’a i chce się przez niego lognąć (co jest jak wszyscy wiemy bardzo wygodne na mobilnych urządzeniach) to wystarczy, że kliknie na button, który jest także przygotowany przez facebook’a. Obsłużenie logowanie przez fejsa sprowadza się do zaimplementowania callbacka do buttona logowania z facebook’iem.

3.png

Resztę wykona za nas kod z biblioteczki facebooka.

WP_20160313_17_15_45_Pro

Jeśli wszystko pójdzie ok to mamy token od facebooka, który ja wysyłam na serwer i rejestruje/loguje usera oraz zwracam mój token autentykacji.

Android Asynchronous Http Client

Jako, ze na głównym wątku jedzie UI, do wykonywania czasochłonnych operacji trzeba tworzyć i wykorzystywać inne wątki. Niewątpliwie takimi operacjami są requesty do serwera. Znalazłem do tego świetną bibliotekę (tutaj). Jest bardzo prosta w użyciu dzięki dobrej dokumentacji. Wysłanie requesta sprowadza się do podania urla, i danych oraz obsłużenia zdarzeń po skończonym requeście.

4

Trzeba tylko mieć na uwadze to, że onFailure() nie będzie wywołane tylko wtedy gdy z serwera dostaniemy błąd. onFailure()  jest wywoływane gdy nie uda się odpowiedzi przerobić na obiekt JSON (w przypadku widocznym na zdjęciu, ale biblioteka umożliwia castowanie na wiele innych typów) choć status odpowiedzi może być 200.

GSON

GSON to biblioteczka to konwertowania obiektów Javovych na obiekty JSON oraz w druga stronę. Tutaj jest do niej link. Wystarczy podać typ obiektu, na który chcemy przerobić JSONa, lub wywołać toJson() jeśli chcemy obiekt Javovy przerobić na JSONa

56

Podsumowanie

Od autentykacji zacząłem projekt, także już kilkanaście albo nawet więcej godzin przy tym spędziłem. Mam na myśli oczywiście część androidową. Wygląd apki jak na razie jest prosty, bez fajerwerków. Skupiam się na funkcjonalnościach, a wygląd zostawię na koniec. W środę opiszę autentykację po stronie Asp.Net.

Pjona!

Kilka słów o backendzie w ASP.NET Core 1.0

Siemanko.

Jest środa więc wedle harmonogramu, który ustaliłem we wcześniejszym poście ląduje na blogu jeszcze ciepły pościk. Dziś trochę o projekcie backendu dla aplikacji mobilnej. Dlaczego nowa wersja ASP.NET Core 1.0? Dla drugiego słowa z poprzedniego zdania – nowa 🙂 Mamy w tej chwili oficjalnie wersje RC1 (tutaj), a chyba nieoficjalnie pierwsze przymiarki do RC2 (jak się dowiedziałem szukając informacji na temat buga w JWT Bearer middleware – o czym przy okazji opisywania autentykacji – issue). Z nowym ASP.NET mam do czynienia od beta8.

Struktura projektu ASP.NET

Jak widać na załączonym obrazku zrobiłem sobie 6 projektów co by mieć porządeczek 😉

solution

Pierwszy projekt MobileSecondHand jest projektem startowym i jest to WebApplication utworzona z template’a w Visualu. Pozostałe projekty to webowe Class Library – package. I tu pierwsza z wielu nowości – library to paczki, które możesz opublikować na nugecie i instalować je jak inne biblioteki z nugeta. Te dodane do projektu poprzez File->New->Project dodaje się normalnie do Reference, ale muszą to być te „nowe” webowe Class Library (package). Jeśli masz napisane zajebiste ficzery, które wykorzystujesz w wielu różnych projektach – ale masz je napisane w „starym” Class Library – to nadal możesz wykorzystywać te zajebisty ficzery, ale w aplikacjach, w poprzedniej wersji frameworka 😉 Nie da się ich dodać do referencji projektu w nowej wersji frameworka. Trzeba „stare” przepisać na „nowe” Class Library (package).

packages

Jak widać wyżej projekty, do których dodałem referencje w projekcie startowym widnieją na liście dependencies w pliku project.json projektu startowego. Tu są wszystkie „paczki”. Możemy nie używać Package Manager Console czy Manage Nuget Packages tylko od razu wpisać na tej liście paczki, które chcemy dołączyć do projektu i zapisać plik, a wszystko stanie się samo 😉

Kolejną nowością jest klasa Startup.cs gdzie odbywa się cała konfiguracja i start aplikacji. Nie trzeba robić wpisów konfiguracyjnych w web.config czy global.asax – tego drugiego już nie ma. Całą konfigurację (np. CORS, MVC, routing, sposób autentykacji, dostęp do danych itp.) przeprowadzamy w Startup. NIe będą jej tu wklejał bo na jednym screenie się nie zmieści także jak masz ochotę to luknij do repo.

Kolejnym super ficzerem są kontrolery – WebApi czy zwykły dziedziczą po klasie Controller.cs i jeśli chcemy to możemy opędzić w jednym kontrolerze REST API oraz MVC do zwracania widoków oczywiście nadając metodom specjalne RouteAttribute’y.

Najlepszym ficzerem wg mnie jest wbudowany kontener IoC. Na pewno jest on kiepściejszy niż inne zewnętrzne istniejące od dawna, ale mam to w dupie bo mi w zupełności wystarcza, a nie muszę nic konfigurować poza zarejestrowaniem interfesju co sprowadza się do 1 (słownie: jednej) linijki i dzieje się to właśnie we wcześniej wspomnianej klasie Startup.cs 🙂

service

Mamy do wybory trzy opcje:

  • AddTransient – instancja na każde wystąpienie interfejsu
  • AddScoped – instancja na web request
  • AddSingleton – instancja w ramach całej aplikacji

i mnie to pasuje 🙂

Dobra, może wyglądać na to, że się wymądrzam, ale przytoczyłem kilka nowości, które zdążyłem poznać, ale jest jeszcze wiele do nauczenia się dlatego też właśnie backend robię w ASP.NET Core 1.0, o którym Gutek powiedział na DotNetConf, że póki nie wyjdzie pierwsza stabilna wersja to nowe ASP.NET jest jedynie do zabawy 🙂

Jeśli zajrzysz do repo to zobaczysz w głównym projekcie kilka rzeczy (kontrolery z zakomentowanym kodem, serwisy bez implementacji) z defaultowej aplikacji tworzonej przez visual. Na razie ich nie wyrzucam bo być może wykorzystam je w późniejszym etapie więc po co wymyślać koło na nowo 🙂

 

Dzisiejszym postem kończę wstęp do mojego projektu. Od niedzieli jedziemy już na grubo i będziecie mogli poczytać oraz zobaczyć co i jak jest zrobione do tej pory,a jest kilka rzeczy 😉

Pjona!