Android - Middleware


(Neo1888) #1

Czytałem troszkę o tworzeniu apek na androida. I tak się zastanawiam. Mam apkę - przykładowo jakiś portal społecznościowy. Dane użytkowników chcę trzymać w bazie danych. Prawdopodobnie gdzieś na serwerze. Słyszałem, że używa się wtedy opr. middleware. Np. tworzy skrypty w phpie do pobierania z bazy i parsuje na JSONA po czym umieszcza na stronce i apka po httpie sobie pobiera co potrzebuje. Nie wiem co z zapisem i ogólnie nie gra mi tutaj np. trzymanie tego na szeroko dostępnym httpie. Jak to się ma do większych projektów, co z zapisywaniem do bazy? Ktoś robił coś takiego? Jestem w tym nowy i będę wdzięczny za pomoc w zrozumieniu koncepcji. 


(Fizyda) #2

Stawia się serwer REST, załatwia nam to pobieranie, zapisywanie, usuwanie danych bo w ramach niego to wszystko implementujemy. A ogranicza się to przez np dodatkowe klucze dostępu do api serwera rest. Dodatkowo powinna być zapewniona w przypadku portalu opcja logowania za pomocą loginu i hasła wraz z utrzymaniem jego sesji w natywnej aplikacji i to dzięki tej sesji można uwierzytelniać bez ciągłego podawania loginu i hasła dostęp do wrażliwych danych za pomocą api - danych typu usuń konto, przelej pieniądze itp. Publiczne dane które np można wyświetlić przechodząć na stronę nie muszą być w żaden sposób ograniczane i mogą być dostępne za pomocą api bez uwierzytelnienia np. lista newsów na portalu, czy zawartość konkretnego newsa - chyba że są to newsy premium w tedy po zalogowaniu i uwierzytelnieniu za pomocą sesji.

 

Popatrz sobie na api twitcha, facebooka, steam czy innej aplikacji internetowej. Np Twich pozwala wszystkim bez żadnego ograniczenia pobierać listę kanałów live, sprawdzać status kanału, pobierać śledzone kanały użytkownika, ale np dodanie kanału X do śledzony przez użytkownika Y wymaga już przesłania dodatkowo kodu oauth dla użytkownika Y, którego z kolei dostajemy po autoryzacji takiego użytkownika - musimy w aplikacji mieć mechanizm autoryzacji z twitchem tak by mógł się on niejako zalogować w naszym serwisie/aplikacji w tedy otrzymujemy oauth dla niego zachowujemy np w bazie danych i możemy coś zmieniać na koncie tego usera przy pomocy api. OAuth będzie kluczem sesji/identyfikatorem sesji o którym wspominałem wyżej.


(Frankfurterium) #3

To, co napisał Fizyda, ale z uwagą, że porządny REST powinien być bezstanowy i nie tworzyć na serwerze żadnej sesji. Istnieje parę mechanizmów pozwalających zamienić credentialsy użytkownika na swojego rodzaju token, który uwierzytelnia każde zapytanie między aplikacją i backendem. Sam preferuję JWT, które jest lekkie i obsługiwane na każdej popularnej platformie.


(cheshireCat) #4

Ew stare SOAPowe serwisy też się nadadzą - działać będzie. Choć REST jest bardziej na czasie. Jak już robisz w javie to możesz nie bawić się w phapy i inne takie tylko np w springu sobie machnąć potrzebne rzeczy. Dostępny jest cały stack oprogramowania i do serwisów i do obsługi baz danych - resztę już zszyjesz;) tutoriali jest chyba sporo na necie ew. książki;) http://spring.io/guides 


(ttomas) #5

Ciekawy temat.

Może jeszcze wrzucicie parę ciekawostek np: co będzie np: lepsze / wydajniejsze / nowe (dla mnie , na sychchronizację androida z jakimś serwerem, (szybko (user z mizernym łączem) i skutecznie ) .


(Fizyda) #6

Zależy od tego co, jak duże, jak często i z czym chcesz synchronizować. Zawsze najmniejszy narzut będzie powodować własny protokół komunikacyjny.


(cheshireCat) #7

O ile będzie dobrze napisany więc raczej komuś kto nie wie jeszcze do końca nawet jakie są możliwości i rozwiązania, nie polecałbym tej opcji.


(ttomas) #8

Źle się wyraziłem, chodziło mi o opinię dodatków do Androida na zasadzie REST, synchronicznych i asynchronicznych, np: http://loopj.com/android-async-http/

 

oczywiście jak wszyscy wiedzą, pisanie protokołów lub używanie bibliotek jest podyktowane czasem i budżetem :).


(Fizyda) #9

Ja nic do resta nie mam :P. Pod warunkiem że komunikujemy się z serwerem raz na jakiś czas i to klient żąda danych, a serwer nie ma potrzeby sam z siebie wysyłania czegoś do klienta. W przeciwnym wypadku warto zainteresować się websocetami dla aplikacji webowych, a dla tradycyjnych zwykłymi z użyciem jsona do komunikacji.