Android App: Lokale DB <-> Server mit DB

[Ronschk]

Hi,
Ich bin dabei eine App zu programmieren, die später einmal mit einem Server kommunizieren soll. Der Server soll über eine Datenbank verfügen und nen paar Berchnungen mit den Daten erledigen. Zwar verfüge ich über mad programmierskillz wenn es um java/c++/etc geht, bin aber recht frisch im Bereich Datenbanken und habe von Servern so ca. 0 Ahnung.
Momentan ist es so, dass ich ne SQLite DB auf dem Geräte habe auf dem die App läuft und eine Server-Klasse die Schnittstelle zwischen App und DB bildet.
Jetzt will ich natürlich gerne alle so gestalten, dass, wenn wir uns einen Server mieten, nicht alles neu programmiert werden muss. Dazu ein paar Fragen:

1. Würde sich dazu ein Glassfish Server eignen (auf diesem könnte ich ja mehr oder weniger "ganz normal" in Java programmieren?)? Bzw was gibt es für Alternativen und was haben die für Vorteile/Nachteile?

2. Bzgl Schnittstelle: Würden Server und App gemeinsame (DTO) Klassen verwenden oder werden nur "einfache" Datentypen übertragen?

3. Ist es, ohne sehr großen Aufwand, möglich auf nem Desktop Pc (windows 7) die Server Applikation so laufen zu lassen wie sie später auch auf nem anderen Server laufen wird?

Habe wie gesagt sehr sehr wenig Ahnung in dem Bereich, deswegen bitte ich schwachsinnige Fragen zu verzeihen

 

[Hans2000]

Was spricht gegen JDBC? JDBC ist es recht egal wo die Datenbank ist (localhost oder remote).

 

[Starfire]

was hastn bisher programmiert, wenn du noch gar nichts mit client-server kommunikation programmiert hast?

hast du schon kenntnisse in java ee?
schau dir mal http://docs.oracle.com/javaee/6/tutorial/doc/bnaay.html an.
ersetze dort die faces komponente durch webservices und du hast ne passende architektur.


1.
wenn du webservices verwendest wie z.b. soap oder json etc. ist es egal was der server ist, solange er die schnittstellen bereitstellt.
http aufrufe haben aber immer einen gewissen overhead.
effizienter sind da simple socket protokolle, stichworte: jms hornetq.

das ganze kann ein javaserver wie glassfish jboss etc. sein, ein tomcat reicht wahrscheinlich auch, aber es könnte auch irgend ein php server oder etwas von microsoft zb. iis sein.

wenn die serverkomponente keine komplexen berechnungen durchführen soll, wofür du andere framesworks/apis benötigst, oder von sich aus mit anderen servern kommunizieren soll, dann könnte das auch eine datenbank von sich aus erledigen.
bei ner oracle datenbank erledigen das zb. jobs, trigger oder sogar einfache views.

2.
da hast du freie hand, je nachdem was für ein protokoll du verwenden willst. beides hat vor und nachteile.
DTOs lassen sich immer wiederverwenden, bei manchen protokollen ist das serialisieren der objekte zwar nicht unmöglich, aber ziemlich frickelig.
möglich ist aber grundsätzlich beides.
wenn man kein striktes design hat oder die architektur sowas vorschreibt, nimmt man normalerweise die erst mal einfachere lösung und refakturiert das, wenn einem die lösung das dritte mal stinkt.

3.
ja, wird eh alles in der JVM laufen.
beim jboss brauchst du nicht mal unterschiedliche versionen für windows/linux. da reichts die tmp dateien wegzuwerfen und einfach den ordner zu kopieren.

 

[ducki]

gibt ja möglichkeiten wie sand am meer. ich weiß nicht wie groß deine app wird aber der overhead von http wird vmtl nicht relevant sein
ich würde mir eine schöne restful API mit json-paketen überlegen. implementierung dann mit php oder node.js wenn ihr hip seid

 

[Ronschk]

was hastn bisher programmiert, wenn du noch gar nichts mit client-server kommunikation programmiert hast?

Software die lokale Daten auswertet, Prorgramme für Bildverarbeitung, GUIs.. Studiere keine Informatik sondern etwas ausm Ingenieursbereich und der Client-Server Teil der Informatik hat mich da irgenwie nie erwischt :P

Danke erstmal für die Antworten. Schade, dass es da Möglichkeiten wie Sand am Meer gibt, das macht es nicht unbedingt leichter ^^ Vielleicht helfen ja nen paar mehr Infos.
Es soll eine shopping App werden bei der der User Eingaben tätigt, auf deren Basis ihm Produkte vorgeschlagen werden. D.h der Server sollte neben nem Zugriff auf eine Datenbank auch noch in der Lage sein (etwas größere) Berechnungen durchzuführen. Dabei wird ca. alle fünf bis zehn Sekunden eine Kommunikation zwischen App und Server stattfinden die darin resultiert, dass der User ein paar Bilder (und weitere Infos) aufs Gerät geschickt bekommt. Der Overhead ist also erstmal nicht so wichtig(?).
Es soll schon darauf ausgelegt sein, dass eine Menge Leute die App benutzen können.
Die App soll es natürlich auch für iOS geben, falls das eine Rolle spielt.
Ich persönlich fände es toll, wenn ich auf dem Server in Java/c#/c++ programmieren könnte und wenn sich der Programmier- (und Lern-) Aufwand dafür in Grenzen hält (die App an sich ist gerade erstmal genug ).
Hilft das die Auswahl zu reduzieren?

 

[reddy.LIKE]

gibt ja möglichkeiten wie sand am meer. ich weiß nicht wie groß deine app wird aber der overhead von http wird vmtl nicht relevant sein
ich würde mir eine schöne restful API mit json-paketen überlegen. implementierung dann mit php oder node.js wenn ihr hip seid

vergiss das mit dem sand an meer, das ist die best practice für deinen anwendungsfall und dann haste das schon mal intus wenn du später wirklich auf den overhead achten musst.

austausch zwischen frontend/backend; app/server json thats da story.

hab gerade erst deinen letzten post gelesen, wozu im backend server c++ oder c#? macht bei der anwendung wenig bis gar keinen sinn, ausser du hast jemanden der darin gerade fit ist. wozu das rad neu erfinden und ich kapier bis heute nicht warum php so stiefmütterlich behandelt wird, ist irgendwie nicht hip aber bitte der größte teil des internets basiert darauf.

also backend/server >> spring framework (java); play framework (java) wenns java sein muss oder besser laravel oder simpel php brauchst du auch keinen dedicated server sondern reicht in der regel nen normaler hosted webspace.
für die app: schickst du halt die suchparameter an deine api dein server liefert dann nur das ergebnis zurück fertig. in der app haste dann noch nen cache für schon gelieferte ergebnisse, falls es so was wie vor und zurück gibt fühlt sich nativer an als jedesmal wieder aufn server respons zu warten. ich persönlich würd ja für die app/froneted angularjs nehmen.. brauchst du dir um vieles wie chaching etc weniger sorgen machen und als backend laravel aber das sind persönliche vorlieben.

 

[ducki]

laravel sieht ja ziemlich fresh aus. aber auch krass umfangreich. meinst du für eine reine rest api wär das nicht overkill? ich hab für den zweck bis jetzt Slim genutzt, verpass ich irgendwas tolles wenn ich mir laravel nicht gebe?
ng natürlich premium. werde mein nächstes frontend wieder darauf aufbauen.

 

[reddy.LIKE]

Ne verpasste nix, slim bringt auch alles nötige mit.. laravel wird gerade unendlich gehypte, für diesen anwendungsfall wird aber slim so gar besser sein.

Wollt mit laravel nur die php frameworks in stellung bringen ob slim oder laravel völlig egal hauptsache php

Ps. mit handy hier zu posten is wirklich pain, aber hauptsache keine mobiltheme since 2011 sorry aber tippfehler etc lass ich einfach so

 

[skY]

in der app haste dann noch nen cache für schon gelieferte ergebnisse, falls es so was wie vor und zurück gibt fühlt sich nativer an als jedesmal wieder aufn server respons zu warten.

wollte das nur noch mal hervorheben. fruehzeitig daran denken und die implementierung nicht ans ende verschieben.

haben die pflege einer app uebernommen die ne ganze menge zeug mit nem server austauscht (rest api, unter anderem auch relativ hoch aufloesende bilder). leider haben die urspruenglichen entwickler den (laut kunden explizit geforderten) "offline modus" unter den tisch gekehrt.
fazit: wir basteln jetzt nach und nach caching fuer alles ein, ist relativ grausam. obwohl wir schon relativ viel zeit reingebuttert haben, frisst die app beim intensiveren testen in 3 tagen gern mal 200mb datenvolumen weg

ansonsten passt alles was reddi und der rest sagt.