Serverkommunikaiton Architektur ?

    Hallo Leute, ich schreibe gerade zum ersten mal eine App, die unter anderem mit einem Server kommunizieren soll. Dabei soll sie zum einen einen eine dauerhafte Verbindung bestehen, die Notifications auslöst, eine dauerhafte Verbindung für Push Nachrichten Dienste, sowie an mehreren stellen einfach nur einmalig bei Knopfdruck Daten schicken und oder empfangen.
    Dazu habe ich zwei Fragen:
    1. Sollte man das alles in einen einzigen NetwerkService packen, und dann mit Bindern und Handlern die verschiedenen activites drauf zugreifen lassen, oder lieber mehrere kleine Services, die jeder jeweils eine Aufgabe übernimmt (also ein Service zum einmaligen senden und empfangen, einer für die dauerhafte notificaitonsverbindung, einer der nur geöffnet wird wenn man den chat benutzt und so weiter)


    2. In meinem Android Buch steht, dass es zwei Hauptwege gibt um mit einem Server zu kommunizieren: Die HTTP Clients mit der HTTP-Components Library und Sockets. Meine Frage: Sollte man diese vermischen, also für einmaligs Senden und empfangen HTTP Clients und für dauerhafte verbindungen Sockets, oder ist es sinnvoll auch für die einmaligen aktionen einen Socket zu benutzen ( bzw. kann man da wenn man nur einen großen NetzwerkService benutzt den gleichen Socket benutzen? )


    Danke schonmal im Vorraus :)


    mfg

    Also eine Dauerhafte verbindung ist schonmal eine schlechte idee.
    Wenn deine App daten an den server senden möchte kann sie das tun, danach sollte die verbindung aber wieder geschlossen werden.


    Mit deine App PushNotifications empfangen kann solltest du dir mal die GoogleDienste anschauen, Stichwort GCM.
    Google einfach mal danach, es gibt einige Tutorials dafür. :)


    1. Service


    2. puh keine ahnung, aber aus erfahrung denke ich es wird am wenigsten probleme geben wenn du dich für eins entscheidest

    Du willst keine permanente Verbindung zu einem Webserver. Ganz sicher nicht.


    Das möchtest Du schön über Push Notifications regeln. (auch keine dauerhafte Verbindung!)


    1) Im Prinzip sollte jede Teilkommunikation einen Service haben. Da Du aber keine dauerhafte Verbindung brauchst, reicht auch ein etwas generalisierter Netzwerkservice.


    2) Vermischen sollte man das nicht. Socket-Verbindungen sind eh nur gut bei bidirektionalen dauerhaften Verbindungen, die Du ja (wie bereits mehrfach erwähnt) einfach nicht brauchst. Bei einer Socket-Verbindung bist Du permanent am aufbauen, senden, empfangen, zusammenschustern, auswerten und abbauen. Ein HTTP-Request nimmt Dir da einen ganzen Haufen nerviger (und unnützer, da Du ja keine dauerhafte Verbindung brauchst) Arbeit ab.

    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!«

    Ok, danke shconmal für die Antworten, dann werde ich mir jetzt GCM angucken.


    Allerdings habe ich da noch eine Frage, und zwar stand in einigen Foren, in denen ich vorher recherchiert habe, dass GCM für einen Instant Messanger schlecht ist ( ich glaube unter anderem, weil es nicht hundertpro zuverlässig ist laut google selber) und sie eben dafür einen Socket nehmen würden.
    Von Sockets seit ihr ja anscheinend nicht so die Freunde, aber wie würdet ihr es dann machen, dass nachrichten immer direkt angezeigt werden? Trotdem mit GCM, oder mit HTTP Requests in intervallen, oder ist das eine außnahme in der man Sockets verwenden kann?

    Für einen Chat würde ich ein fertiges Framework nehmen. Am Besten auf der XMPP Architektur aufbauen und gut.
    Auch da solltest Du auf jeden Fall die Finger vom Socket lassen. ;)


    Ich persönlich bin übrigens der Meinung, dass das ein ziemlich umfangreiches Projekt für einen Einzelkämpfer wird. :P

    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!«

    wenn du schon einen chat machst dann doch bitte mit innovativen funktionen :P
    es gibt soviele chatclients, viele sind auch nutzlos.
    da muss was neues her, p2p z.b.
    oder was tolles mit webRTC!


    und solltest du es allein machen wird allgemein ein solches projekt ewig dauern :/

    Zitat von 54B074G3

    was genau saugt den Akku so schnell leer bei einer ruhenden offenen Socket-Verbindung ?


    Die bestehende Verbindung zum WLAN/Mobilen Internet sowie die permanente Prozessoraktivität. 'Ruhend' heißt ja nur, dass dort gerade weder Daten ankommen noch abgehen.
    Dennoch wird auch bei einer ruhenden Verbindung permanent auf dem Socket gelauscht.
    Es ist ja nun nicht so, dass ein Männchen mit Wimpel plötzlich aufspringt und dem System anzeigt, dass es jetzt auf dem Socket lauschen muss…


    Zitat von 54B074G3

    Welche Technik nutzt GCM um ad hoc Nachrichten auf das Gerät zu senden, wenn keine
    Socket-Verbindungen bestehen ?


    Wer sagt denn, dass keine Socket-Verbindung besteht? Ich spreche davon, dass man selbst keine Socket-Verbindung für diesen Anwendungsfall aufmachen soll.
    Die Socket Verbindung für GCM wird durch das System offen gehalten und agiert in der Hauptsache mit dem Google Play Store (weshalb der auch zwingend benötigt wird – Android Market reicht nicht)
    Es haben also Menschen aus Fehlern (G2DM) gelernt und etwas Funktionierendes geschaffen. Es wäre überheblich zu glauben, eine Eigenimplementierung liefe besser als Googles Ansatz.

    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!«

    wichtiger aspekt wäre auch das bei einer eigenimplementierung dann eben mehrere sockets aktiv sind (auch wenn sie ruhen).
    Wenn du die bereits implementierte variante nutzt sind es eben weniger und damit auch weniger akku verbrauch


    stellt euch nur vor jeder würde das selber implementieren, wie schnell der akku leer wäre und sich alle beschweren würden ;)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden