Wpis z mikrobloga

@Keczupp: Nie będzie, ale jest to brzydkie. Nie możesz mieszać warstw swojej aplikacji więc źródło danych najlepiej przenieść do innego projektu, a w swojej porobić struktury DAL (Data Access Layer).. Mówię tu oczywiście o większej aplikacji, gdzie użytkownicy będą np wymieniać się danymi lub jest potrzebna jedna duża baza danych. Jeśli chodzi o o baze na urządzeniu to nie potrzebujesz tak cudować zwykły SQLite styknie.

Oczywiście to tylko moje sugestię
@Nartenlener: Akurat dane z bazy będą tylko czytane, więc jak najłatwiej i najwydajniej bym je chciał wyciągnąć (bo może być ich sporo). Tyle, że te dane będą czytane asynchronicznie (na podstawie aktualnej lokalizacji z gps) i, jako że z androidem dopiero zaczynam, zastanawiam się jak to rozwiązać.
@Keczupp: Na twoim miejscu postawił bym jakieś API i wywoływał je z aplikacji mobilnej. Ma to taką zaletę, że aplikacja na andku będzie mniejsza, mniejszy transfer zużyjesz bo będziesz wymieniał z API tylko JSONy - czysty tekst, a nie preambuły do połączenia do bazy. A co w przypadku jak będzie konieczność napisania apki na iOS? Będziesz przepisywał logikę związaną z bazą? Szczerze polecam rozwiązanie oparte na API
@Keczupp: a jak w ogóle nie masz czasu na bazę to polecam firabase.google.com. Multum rzeczy w jednym. Jest darmowe do 100 połączeń z serwerem na raz. Jest też trick, że po wykonaniu zadania mówisz żeby się rozłączyło, no ale wtedy updatów nie ma. Sprawdź czy Ci pasuje, bo implementacja jest szybka i bezbolesna.
@Keczupp: Jeżeli baza Ci jest potrzebna wyłącznie do apki mobilnej to na 99% Oracle to za ciężkie rozwiązanie. Jeżeli jednak musi być Oracle to połączenie tylko przez jakieś API RESTowe, bezpośrednie połączenie do bazy zmniejsza Ci elastyczność (co jak będziesz chciał dorobić apkę webową? albo apkę na iOS?), bezpieczeństwo, zwiększasz skomplikowanie apki