App - Server Infrastuktur

  • Hallo zusammen,


    ich komme aus der Enterprise Java Welt mit Swing Client / Application Server / Datenbank. Das Hilft mir aber bei Android nur begrenzt weiter, daher meine Frage:


    Ich möchte eine App schreiben die Daten mit einem Server austauschen kann inkl. Authentifizierung. Die von der Anwendung Bussiness Logik soll auf dem Server laufen, dieser soll auch einzelne Clients notifizieren können.


    Gibt es da einen Überblick (Links/ Bücher) wie man so etwas am besten mit den ganzen Google Diensten / Google App Engine / Services / APIs die es so gibt aufzieht?

  • "KISS - Keep it simple stupid"


    Die Kommunikation zwischen App und Server ist ziemlich einfach. Du musst dich halt nur mit der Webentwicklung etwas auskennen.


    Prinzipiell läuft es so ab:
    Eine Webseite stellt einen "Service" (stinknormale Webseite ohne UI) zur Verfügung. Über den Service wird kein HTML sondern nur JSON, XML oder CSV zurückgeliefert. CSV benötigt am wenigsten Speicher und ist imho am besten geeignet.


    Den Service stellst dir einfach wie eine Webseite vor. z.B. http://www.meintollerservice.d…lterByName=tolles+produkt
    Diese URL liefert dann alle Produkte die z.B. mit diesem Namen anfangen zurück.


    Die Android App macht nichts anderes als diese URL asynchron abzurufen, parsen und dem User darzustellen.


    Wenn du noch einen Login machen willst, dann kannst du ähnlich vorgehen nur brauchst du dann https! Unbedingt!
    Die beste Vorgehensweise ist hier, dass du nach dem Login ein Token (UUID/Guid) zurückliefern lässt die eine bestimmte Dauer gültig ist und bei jeder Aktion mitgeschickt und validiert wird. :)


    Denke das ist mal ein kleiner grober Überblick.

  • CSV benötigt am wenigsten Speicher und ist imho am besten geeignet.


    Dem widerspreche ich vehement. Zumindest dem Punkt mit der Eignung.


    Dir wird irgendwann auffallen, dass Du das Ausgabeformat umstellen möchtest. Ein Datenfeld hat darin nichts mehr verloren, zwei neue sollen dazu. Schon schauste blöd, wenn Du eine indexbasierte Speicherung via CSV benutzt hast. Schwierig anzupassen.
    Verirrt sich ein UTF Zeichen in Dein CSV oder änderst Du den Separator oder kapselst Du die einzelnen Felder statt in doppelte nur noch in einfache Anführungszeichen oder enthalten Deine Felder dummerweise einen Separator – echt schwierig umzusetzen.
    (Schau Dir mal den Excel CSV Import an – gefühlte Millionen Möglichkeiten)


    XML und JSON bieten mehr Bequemlichkeit beim 'Durchnehmen' für den geringen Preis von etwas mehr Speicherplatz.
    Selbst wenn das Mehr an Speicherplatz sagen wir 100% betrüge, so hätten wir einen Unterschied von 50kb zu 100kb – das ist nichts und 50kb sind schon ne Menge Text.


    Die beste Optimierung hierfür wäre ein serialisiertes JSON/XML Format, wie beispielsweise Apples 'Binary Property List'.
    Ungefähr 25% größer als CSV und damit absolut zu vernachlässigen, doch relativ schwierig in der Implementierung.
    Also alles in Allem eine Optimierung, die absolut keinen Sinn für einen derartigen Anwendungsfall ergibt.


    Die beste Vorgehensweise ist hier, dass du nach dem Login ein Token (UUID/Guid) zurückliefern lässt die eine bestimmte Dauer gültig ist und bei jeder Aktion mitgeschickt und validiert wird


    Auch hier widerspreche ich vehement. Datenschutz ist eine Sache, die man keinesfalls auf die leichte Schulter nehmen sollte.
    HTTPS als 'Requirement' zu definieren ist seit Heartbleed auch so ein bisschen leichtsinnig.
    Statt dessen solltest Du lieber die Google+ API oder die Twitter OAuth API oder eine Facebook OAuth API oder eine OpenID OAuth API oder weiß der Geier was nutzen. (Je mehr desto besser für den Nutzer)
    Zum Einen sparst Du Dir den Ärger mit den ganzen Zertifikaten, zum Anderen bietest Du den Leuten das Gefühl, etwas Bekanntes und Vertrautes zu nutzen.
    Und drittens: wenn irgendwas schief geht ist das nicht Dein Bier, da Du die Nutzerdaten ja überhaupt nicht in die Hände bekommst.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Ahoi Marco,
    bisher habe ich auch immer auf JSON gesetzt weil es sich besser handeln lässt, aber das muss man natürlich je nach use-case entscheiden. Bei kleineren Datenmengen < 50kb macht das keinen spürbaren Unterschied ob JSON oder CSV. Aber wenn man große Datenmengen auf ein Smartphone überträgt, dann finde ich CSV durchaus sinnvoll.


    Zum Datenschutz, das Vorgehen von mir war nur eine grobe Umschreibung des Prozesses.
    Man kann das natürlich OpenID (etc.) nutzen, aber ist auch hier eine Sache des use-cases.

  • Ich will mal einen Link zu dem Thema anheften, der interessant sein kann, wenn man ein "Comfort-Paket" haben möchte: https://parse.com/ (Parse)
    Das ist ein Backend-Provider, der von seinen Preisen her günstig ist und für kleine Apps kostenlos. Es gibt eigene SDKs für beinahe alle Plattformen und man muss sich fast keine Gedanken machen. Eine kleine App hat man damit in Minuten gebastelt und nach oben gibt es damit fast keine Grenzen. Man kann sogar Cloud-Code laufen lassen, was nur wenige solcher Provider anbieten.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!