Android App mit zentraler Datenbankverbindung

S

sepz

Erfahrenes Mitglied
27
Moin Leute,

mein Ziel ist es eine App zu entwickeln, welche sich grob gesagt anfangs mit einer Datenbank verbindet um deren Inhalte abzufragen, bei beliegen können diese Daten dann am Gerät erweitert werden. Löschen oder Ändern der Datensätze ist nicht erwünscht, nur Abfragen und Zufügen.

Überall wird in Verbindung mit Android ja die SQLite DB genannt, diese ist aber wie ich es gelesen habe keine Server/Client Datenbank und da ich mehrere Geräte habe die auf diese Datenbank zugreifen sollen/können/müssen fällt SQLite ja weg. Ich hatte erst noch die Hoffnung auf den ContentProvider, aber so wie ich das verstanden habe löst der ContentProvider ein Datenübergabe-Problem nur über Apps pro Gerät und nicht über dieselbe App im Netzwerk.

Bin ich dann gezwungen auf beispielsweise MySQL umzusteigen? Wie würde es bei einer solchen Datenbank dann mit dem Zugriff klappen, bräuchte ich PHP-Kenntnisse um die Abfragen ausführen zu können?

Entwickelt wird unter einer Linux-Umgebung, also fallen reine MS-Lösungen weg. Falls aber jemand sagen würde die Umsetzung wäre mit MS-Access <-> Android am einfachsten würde ich es auch unter Windows machen...

Ich hoffe mein Anliegen ist deutlich ausgedrückt :p
 
da gibt es gleich eine ganze Reihe möglicher Lösungen.
Generell könntest du jede Art von Datenbank auf dem Server nutzen, aber ich würde dir absolut zu MySQL raten.
Den Zugriff kannst du dann auch verschiedenermaßen gestalten:
was du ja selbst bereits genannt hast ist php - kann man machen, keine Frage - kleine Schnittstelle über JSON oder XML, Aufruf über eine HttpUrlConnection und die Sache läuft.
Ich für meinen Teil favorisiere aber Socket-Verbindungen mit einen Java-Server im Backend.
Zugegebenermaßen ist die php-basierte Lösung wohl einfacher, aber da musst du wohl einfach selbst wissen was dir lieber ist;)

Gruß Steffen

edit: ich war einfach zu lahm^^
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: sepz
Ich kann dir nur raten einen REST ähnlichen Webservice zu basteln (womit auch immer) ;)
Meine Favs sind da immer noch JAX-RS(2.0) und die Google App engine, bzw. gehen mitlerweile auch CloudEndpoints voll klar...
Aber da musst du dir dein liebling selbst suchen ;)

lg. Dagobert
 
  • Danke
Reaktionen: sepz
Die am meisten verwendeten DBs sind wohl PostgreSQL und MySQL, ich persönlich mag lieber PostgreSQL. Mit den beiden DBs kannst du aber eigentlich nichts falsch machen.

Und wenn du nur Datenbankabfragen machst, ist wohl ein WebService am sinnvollsten (Java, PHP, etc.). Sockets brauchst du wenn du eine ständige Verbindung zum Server haben willst / brauchst.
 
  • Danke
Reaktionen: sepz
Moin,

danke schonmal für die Antworten. Ich fange mal bei der ersten an.
Im 2. Link besteht quasi das gleiche Problem vor dem ich gerade stehe, als Lösung wird MySQL mit PHP empfohlen, einen anderen Lösungsansatz gibt es jedoch auch: JDBC, also quasi eine direkte Verbindung zwischen Android app Java <-> MySQL Server, wobei da das Problem besteht das die User direkt an der Datenbank arbeiten. Im letzten Post stellt ein User eine gute Frage "Online oder Offline"?

Dann hab ich etwas überlegt und eigentlich sind so gut wie alle Daten in der Datenbank fix, das heißt z.B. ein Standort ändert sich nicht der bleibt immer gleich, dann könnte ich doch theoretisch beim ersten Start der App alle Daten direkt per Java und JDBC vom MySQL Server holen und diese lokal in einer SQLite Datenbank speichern. Aus dem 2. Link hat ein User die Schnittstelle MySQL <> SQLight mit Ruby realisiert. Sobald der User die App das nächste mal startet, wird ein GPS Signal geholt und fixe Angaben wie naheliegenste Standorte aus der SQLite Datenbank abgefragt. Nur eine variable müsste immer "frisch" vom MySQL Server geholt werden, zudem würde ich diese variable nun doch gerne vom Benutzer geändert haben falls erwünscht, sodass ich irgendwie nach Änderung dieses einen Wertes einen Abgleich der SQLight DB mit der MySQL DB durchführen müsste. Wäre das so machbar? Was haltet ihr davon? Hab ich etwas übersehen?

Das mit dem REST hatte ich mir mal kurz angeschaut, mein erster Eindruck ist das es etwas den Rahmen des Aufwandes sprengen könnte.

Socket Programmierung hatte ich schonmal unter C, weiß nicht ob man das jetzt vergleichen kann, aber eine ständige Verbindung brauche ich nicht, deswegen würde das dann wohl wegfallen.
 
sepz schrieb:
Moin,

danke schonmal für die Antworten. Ich fange mal bei der ersten an.
Im 2. Link besteht quasi das gleiche Problem vor dem ich gerade stehe, als Lösung wird MySQL mit PHP empfohlen, einen anderen Lösungsansatz gibt es jedoch auch: JDBC, also quasi eine direkte Verbindung zwischen Android app Java <-> MySQL Server, wobei da das Problem besteht das die User direkt an der Datenbank arbeiten. Im letzten Post stellt ein User eine gute Frage "Online oder Offline"?
Das ist aber nur eine eher theoretischer Ansatz.
Niemals sollte man einem Client direkt Zugriff auf die Datenbank geben.
(Solange es nicht eine Datenbank nur für diesen einen Client ist)
Weil du dann sämtliche Zugangsdaten zu der DB im Client speichern musst (IP, Port, Username und vorallem ein Password).
Nehmen wir an du nutzt MySQL und dafür wird eine Lücke bekannt mit der man Adminrechte bekommen kann mit einem normalen User.
Plötzlich könnte jeder in deiner Datenbank rumspielen.
Ganz davon abgesehen, dass du dann deine Datenbank auch von aussen erreichbar machen musst, ohne weitere Sicherungen könnte also einfach jemand anfangen und jedes mögliche Passwort für den root zugang ausprobieren (zugegeben das dauert natürlich etwas, aber theoretisch ist das null arbeit)

Von daher meine Meinung JDBC auf Android ist (fast) NIE eine gute Idee, da Android Apps ja in der Regel Clients sind die mehrfach verteilt und genutzt werden.


sepz schrieb:
Dann hab ich etwas überlegt und eigentlich sind so gut wie alle Daten in der Datenbank fix, das heißt z.B. ein Standort ändert sich nicht der bleibt immer gleich, dann könnte ich doch theoretisch beim ersten Start der App alle Daten direkt per Java und JDBC vom MySQL Server holen und diese lokal in einer SQLite Datenbank speichern. Aus dem 2. Link hat ein User die Schnittstelle MySQL <> SQLight mit Ruby realisiert. Sobald der User die App das nächste mal startet, wird ein GPS Signal geholt und fixe Angaben wie naheliegenste Standorte aus der SQLite Datenbank abgefragt. Nur eine variable müsste immer "frisch" vom MySQL Server geholt werden, zudem würde ich diese variable nun doch gerne vom Benutzer geändert haben falls erwünscht, sodass ich irgendwie nach Änderung dieses einen Wertes einen Abgleich der SQLight DB mit der MySQL DB durchführen müsste. Wäre das so machbar? Was haltet ihr davon? Hab ich etwas übersehen?
Also wenn es sich um Standorte handelt und die sich selten ändern (also selten neue hinzukommen oder gelöscht werden) kann man das mit dem einmal Abgleich durchaus machen.
Welche Variable du noch vom Server holen musst weiß ich aber nicht.
Ich würde dann hingehen und eine Art Protokoll führen über die Datenbank einträge, die App kann dann beim nächsten mal mit ihrem letzten Aktualisierungsdatum beim Server anfragen und bekommt nur die Änderungen seit diesem Datum mitgeteilt (also was wurde seit dem dd.MM.yyyy geändert)

sepz schrieb:
Das mit dem REST hatte ich mir mal kurz angeschaut, mein erster Eindruck ist das es etwas den Rahmen des Aufwandes sprengen könnte.

Socket Programmierung hatte ich schonmal unter C, weiß nicht ob man das jetzt vergleichen kann, aber eine ständige Verbindung brauche ich nicht, deswegen würde das dann wohl wegfallen.

Wieso würde das den Aufwandsprengen?
REST ist das einfachste überhaupt.

Mit PHP bekommt man sogar den speicherplatz dafür für umsonst.
(kostenlose webhoster mit PHP und MySQL gibt es ja jede menge).

Du brauchst dann nur eine Simple HTTP Anfrage schicken z.B. an
deineadresse.de/getDatebase.php?date=dd.MM.yyyy

Dein PHP-Script holt dann einfach alle Änderungen seit dem Datum aus der Datenbank (oder wenn kein Datum übergeben wurde halt die ganze Datenbank) und schickt sie z.B. als Json Objekt an deine App die diese Dann ganz einfach verarbeitet (Hier empfehle ich immer https://code.google.com/p/google-gson/ wirklich sehr sehr einfach zu nutzen)

Aber wenn du sowieso immer daten vom Server holen musst (du sagstes irgendwas von einer Variable die aus der DB kommen muss), könntest du die Berechnung der Standorte in der Nähe auch direkt auf dem (Web-PHP)Server durchführen. Je nachdem wie aufwendig die Berechnung ist (dürfte für Standorte nicht so aufwendig sein, also ist das hier wieder mehr ein Thoeriekurs ;)) spart das Rechenzeit auf dem Telefon und damit Akkulaufzeit und auf älteren Telefonen läuft die App evtl sogar schneller.
 
  • Danke
Reaktionen: sepz
Hmm ok, also nochmal etwas drüber nachgedacht.
Wenn ich das jetzt richtig verstanden habe bildet REST quasi aus allem eine Ressource, welche ich dann via XML oder eben JSON wie von dir vorgeschlagen vom Server zum Clienten krieg? In dieser Ressource hinterlege ich dann z.B. alle Änderungen ab einem bestimmten Datum in der DB und gleiche diese Änderungen dann mit dem Clienten ab.

Ist das so richtig?
 
Du musst dich auch nicht wirklich an die REST Definition halten wie sie z.B. in Wikipedia beschrieben ist.

Deswegen würde ich mich nicht an dem Wort REST aufhängen sondern lieber einfach nur webservice sagen.

Für deine Anwendung könnte wie gesagt ein einziges PHP Script reichen.

Wie gesagt im Prinzip ist es richtig was du sagst.
Du musst nicht aus allem eine Resource bilden Hauptsache du hast eine simple HTTP Zugriffsschicht auf deine Daten. Und kannst die Daten, die du geliefert bekommst dann einfach verarbeiten.
 
  • Danke
Reaktionen: sepz und markus.tullius
Ok, bleibt dann eigentlich nurnoch eine Frage zu klären, ob es sich lohnt eine SQLight DB anzulegen wo 90% der Daten einmalig hinterlegt sind und bei jedem Start der App nur 2 Dinge abgerufen werden müssen, 1. GPS Koordinaten und 2. "Füllstand", da die Benutzer den Füllstand eines bestimmten Standortes in der App selbst eingeben können, wäre dieser die variable die sich halt ändern könnte.

Oder ob ich es so umsetzen sollte wie du es im vorletzten Post beschrieben hattest...
 
Mache es so, wie beschrieben. Du sparst Dir sehr viel Arbeit, wenn später sich noch mal was ändert (z.B. Erweiterungen). Und mit großer Wahrscheinlichkeit kannst du den Code immer wieder verwenden. ;)


REST ist eine Möglichkeit, Daten sinnvoll und übersichtlich zu übertragen.
 
  • Danke
Reaktionen: sepz
Was du noch überdenken kannst:
Entweder speicherst du alle Standorte einmal auf dem Telefon oder aber du schickst deinen Standort an den Server und dieser schickst dir alle Standorte in einem gewissen Umkreis inkl Füllstand an dein Telefon. Das kommt ein bisschen drauf an ob du die standort daten ansonsten auch offline brauchst.
 
  • Danke
Reaktionen: sepz
Hm auch eine gute Frage, also Standort Beschreibung wie zb "amfa Straße 3" will ich aufjedenfall auch offline zur Verfügung stellen. Für das GPS wird bei den meisten ja eigentlich eh Internet benötigt, ich denke mal die wenigsten werden das Kartenmaterial offline zur Verfügung haben. Also könnte man die Berechnung theoretisch auch von der Datenbank holen. Programmiertechnisch werde ich es wahrscheinlich aber lieber in der Android app umsetzen wollen.


//Edit : obwohl dein gutes Argument für akkulaufzeit und Geschwindigkeit auf älteren Telefone für die Berechnung nicht direkt in der app spricht...
 
Naja sagen wir so, eine Anfrage an den Server musst du so oder so senden, wenn du die Füllstände haben willst.

Da wäre ist halt wirklich die Frage ob die berechnung nicht lieber auf dem Server durchgeführt wird und die App nur noch als "dumme" Anzeige dient (sog. Thin-Client).

Ich bin ein Freund von Thin Clients, gerade im mobile bereich.
Je nachdem wie flexible du den gestaltest, kannst du nämlich ohne App Update Neuerungen bringen.

Beispielsweise willst du nicht nur den Füllstand anzeigen sondern auch wann das letzte mal gefüllt wurde (wenn das überhaupt zutrifft.).
Wenn du deine App so flexible baust, dass sie zusätzliche Informationen einfach dazu schreiben kann, brauchst du nur Änderungen an deinem Server zu machen und alle die die App nutzen sehen sofort die weiteren Informationen.

Ansonsten müssten die User erst ein Update der App aus dem playstore ziehen und das machen nun mal nicht alle und schon gar nicht sofort, sondern oft nur im WLAN, das manche nicht mal zuhause haben.
 
  • Danke
Reaktionen: sepz
Klingt irgendwie genial :D Werde ich dann wahrscheinlich so umsetzen!

Besten Dank für die Antworten von allen, Danke Button wird gleich sorgfältig betätigt :)
 
  • Danke
Reaktionen: markus.tullius

Ähnliche Themen

B
Antworten
4
Aufrufe
430
bb321
B
FabianDev
Antworten
5
Aufrufe
530
swa00
swa00
D
Antworten
23
Aufrufe
2.383
Data2006
D
Zurück
Oben Unten