Jak w temacie. Jak z poziomu androida nawiązać połączenie i wysyłać, odbierać zapytania z zewnętrznej bazy danych? Wiem żę już taki temat był, ale nie uzyskałem tam pożądanej odpowiedzi. Słyszałem o transferze jdbc ale nie wiem jak w androidzie zaimpletować.
Bo pytasz o działania na ułamkach, a nie zadałeś sobie trudu, żeby wcześniej nauczyć się dzielenia.
Dokładnie tak samo jak na desktopie albo webie. Pamiętaj tylko, żeby działać w AsyncTasku, żeby ci nie zblokowało wątku UI.
- nadal twierdzę, że bezpośrednie łączenie się z bazą to jedna z głupszych i niebezpieczniejszych rzeczy, jakie można wykonać na Androidzie.
Uzyskałeś, tylko twoja wiedza jest zbyt mała, żeby to przetrawić.
Jak wszędzie: http://stackoverflow.com/questions/1575 … id-devices (odpowiedź najdłuższa)
Tylko używanie JDBC po stronie klienta niesie kilka wad
-
Aby używać bazy, login i hasło muszą być zaszyte w kodzie aplikacji (albo w inny łatwy do odczytania sposób: plik, lokalna baza, etc.)
-
JDBC pochłania dużo transferu i prądu
-
Załóżmy taki nieprawdopodobny scenariusz, że z twojej aplikacji korzysta 10.000 osób. Ponieważ, instancja aplikacji na telefonie A nie wie nic o instancji B będziesz tworzył pierdyliard połączeń co efektywnie zabije dostęp do bazy. Taki self-owned DDoS.
-
Załóżmy, że ta twoja marna aplikacyjka, odniesie sukces poziomu Angry Birds, doczeka się portu na iPhona, iPada, WindowsPhona, PC, etc. Wszędzie “surowo” zapiszesz to przy pomocy JDBC (głównie bardziej chodzi o hardkodowane stringi z SQL) i nagle uznasz, że w sumie można by zmienić trochę schemat bazy. Nie da się, jesteś ugotowany. Zarówno z punktu pisania, zajmie to dużo czasu, ale gorzej z tym, że zanim ludki ściągną nową wersję gdzie, np. nazwy kolumny z formatu lol_lol zmieniły się na lolLol to musisz utrzymywać dwie wersje bazy, które reprezentują to samo. Zawsze skończy się to jakimiś niespójnymi danymi.
Jakie jest więc rozwiązanie? Middleware Architecture.
Generalnie to rozwiązanie usuwa w/w problemy, a nie stwarza żadnych nowych (być może przy bardzo prostych projektach można odnieść wrażenie powstawania boilerplate code, ale nigdy nie wiadomo kiedy małe będzie musiało stać się wielkie, więc myślmy o skalowalności za wczasu).
No więc co i jak? Może mały szkic
Musimy stworzyć warstwę pośrednią, będącą wysokopoziomowym interfejsem. Ten interfejs swoje źródło danych będzie brał z bazy przy pomocy JDBC (lub czegokolwiek innego), a komunikował się z Androidem przy pomocy JSON-a. Czemu JSON? Przenośny, otwarty, czytelny, mało danych nadmiarowych, gotowe parsery w praktycznie każdym języku.
Jak rozwiązuje powyższe problemy?
-
No hasło i login są w kodzie, ale warstwy pośredniej. Do niej dostępu nie mają użytkownicy, są one bezpieczne.
-
Tu musiałbym się długo rozwodzić nad działaniem JDBC, aby to wytłumaczyć. W skrócie JSON, jest wysyłany od tak. Serwer kończy przetwarzanie i odsyła response. Co najwyżej zostanie to podzielone na kilka, kilkanaście ramek tcp. JDBC z kolei nie pobiera wszystkiego (ma to logiczne uzasadnienie, normalne hurtownie danych mają TB informacji, wybranie wszystkiego byłoby równoznaczne z załadowaniem tego do RAM - jak sam rozumiesz OutOfMemoryException), tylko utrzymuje połączenie. Jest ono reprezentowane przez iterowalny kursor, z którego wybieramy elementy. Nisko-poziomowo one są dociągane, powoduje to:
a) dłuższe przebywanie urządzenia w fazie wysokiego pobierania prądu
b) utrzymywanie połączenia kosztuje transfer + nie wiadomo ile nadmiarowych danych JDBC będzie używać (zależne od wewnętrznej implementacji)
c) zawsze, powtarzam zawsze znajdzie się jakiś ktoś, kto zapomni w kodzie kursor zamknąć. Normalne, błąd w praktyce rzadko wykrywany, bo wszystko działa poprawnie. Zostanie zamknięty przy timeoutcie, więc po co się martwić? Sam rozumiesz, że timeout to jakieś kolejne 20-30 sek?
d) JDBC wymaga otwartego portu. Może to nie oczywiste, ale każda sieciowa komunikacja wymaga otwartego portu na routerze, a nie zawsze jest taka możliwość. To co wyróżnia JSON? To, że jest wysyłane po porcie 80, bo to najzwyklejsza odpowiedź na żądanie HTTP. Ten port jest zawsze otwarty. Generalnie jeden z powodów dla którego Web Service wyparły Remote Procedure Call.
-
W skrócie, jeśli połączenia, nie będą bezpośrednio z bazą danych, a z serwerem, to będzie on mógł zarządzać czymś takim jak ConnectionPool (przynajmniej Javowe Servery Aplikacji coś takiego mają). Przypomina to trochę ThreadPool, tylko zamiast wątków, mamy obiekty reprezentujące połączenie z serwerem. Jest to bardzo skalowalne podejście opierające się na reusingu i komutacji. Innymi słowy zostawmy np. 20 otwartych połączeń dla operacji krótkich i ewentualnie, jeśli przyjdzie żądanie, że jakiś ktoś będzie pobierał duży zbiór danych (realizowana flagą w JSON). Dostanie osobne dedykowane połączenie, tak, aby nie blokować tych 20 dla operacji szybkich (pobranie kilkunastu rekordów). Działa to, jak kasy do 5 artykułów w hipermarketach.
-
Jak już mówiłem, to będzie interfejs. Innymi słowy wystawi jakieś tam metody na których będzie można działać. A ich implementacja odbywa się wewnątrz serwera. Mam nadzieję, że rozumiesz co to oznacza? Każda zmiana logiki biznesowej, która nie modyfikuje tego interfejsu jest dla użytkownika końcowego w praktyce transparentna.
Poza tym jak mówie stworzenie middleware to głównie plusy. Wyobraź sobie, że twoja aplikacja do przeliczenia czegoś potrzebuje 1.000.000 rekordów z bazy i robi to jakimś algorytmem klasy Divide Conquer, a odpowiedzią jest jedna liczba. Bez middleware musiałbyś wysłać 1mln rekordów, prawda? Czyli część obliczeń można wykonywać po stronie serwer’a zarówno tych w dużej dysproporcji in względem out, ale też czasem mamy dane tajne. I nie chcemy ich komuś wysyłać, żeby u nich się liczyło. Z middleware nie ma problemu.