Kommunikation mit Mobil-Telefon

[fkerber]

Hi,

Ich bin nicht zu 100% sicher, ob hier jemand meine Frage beantworten kann, aber ich bin guter Hoffnung. Ich habe die Frage auch schon in einem entsprechenden Android-Forum gestellt - leider ohne Antwort bisher: http://www.androidpit.de/de/android/...-Kommunikation

Sollte jemand also zufällig noch ein gutes Android-Forum kennen, nur her damit

Zur eigentlichen Frage, die wohl nicht nur auf Android bezogen ist, sondern wohl generell für alle Mobil-Telefon <-> Server-Kommunikationen gilt:

Es soll einen Server geben, der über Internet erreichbar ist (vermutlich in Java programmiert, aber ich denke, das ist sekundär) und eine Reihe von Android Handys in "freier Wildbahn". Nun sollen die Handys sich am Server anmelden können und von ihm Informationen bekommen können. Darin sehe ich an sich kein Problem, da las ich die typischen Schlagwörter wie GET und POST etc.
Die Frage, die sich mir nun stellt, ist, wie kann ich vom Server aus, quasi "ungefragt" Informationen an die Handys "pushen". Im "Nicht-Handy-Umfeld" habe ich solche Sachen durch eine Socket-Connection (TCP/UDP) realisiert. Ist das auch der Weg, den ich mit Android gehen würde (also alles auf Socket-Connection aufbauen) oder gibt es da andere Möglichkeiten?


Liebe Grüße,
Frederic

[mkinzler]

Sollte genauso gehen. Androidprogramme sind ja auch Java-Programme. Bei WebOS würde man einen PDK-Teil in C/C++, Pascal, ... schreiben., bei den anderem Mobil OSen sollte das ähnlich sein, oder man verwendet halt AJAX, was von den neuren Mobil-OSen ja unterstützt wird (dank WebKIT)

[Assarbad]

Moin.

Zitat von fkerber:

Die Frage, die sich mir nun stellt, ist, wie kann ich vom Server aus, quasi "ungefragt" Informationen an die Handys "pushen".

Indem du eine einfache TCP-Verbindung von der Serverseite aus aufbaust. Allerdings wird das vermutlich relativ unpraktikabel sein, wg. allerlei Unwägbarkeiten (Proxies sind nur eine Variante).

Warum also nicht den anderen Weg gehen und das Handy einfach anweisen alle X sec beim Server nachzufragen ob was "neues" da ist was gezogen werden soll?

Wenn du es clever anstellst, könnte die Abfrage einer statischen Datei gelten die eine Seriennummer (ähnlich wie die bei DNS-Records) enthält. So kann der Client anhand der Seriennummer die er kennt einschätzen ob er sich an das aufwendigere CGI-Skript (oder was immer du benutzt) wenden soll. Damit sparst du eine Menge Rechenzeit und auch Bandbreite.

Nachtrag: die meisten Aktualisierungsdienste funktionieren so, daß der Client die Verbindung initiiert.

[mkinzler]

Zitat:

Nachtrag: die meisten Aktualisierungsdienste funktionieren so, daß der Client die Verbindung initiiert.

Anders wird es auch nicht gehen. Wie gesagt würde ich eine Web-UI (HTML 5/CSS/JS/AJAX) basteln

[fkerber]

Hi,

genauso? Wie was?
Meintest du Socket-Connections?

Meine Frage zielte darauf ab, ob es vllt. noch was anderes/besseres gibt.

Inwiefern kann mit AJAX helfen, wenn ich vom Server etwas auf den Client "pushen" will?


Es geht z.B. darum, dass das Handy die Verfügbarkeit von irgendwelchen Gegenständen anzeigt.
Ein anderer Nutzer entfernt jetzt einen solchen Gegenstand, das wird dem Server gemeldet und der muss es dann quasi allen anderen pushen.


Liebe Grüße,
Frederic

[mkinzler]

Der Client meldet sich beim Server für ein Update an, dieses wird dann asyncron vom Server gepusht.

http://www.phonegap.com/
http://jqtouch.com/
http://sourceforge.net/projects/quickconnect/

[fkerber]

Hi,

Zitat von Assarbad:

Indem du eine einfache TCP-Verbindung von der Serverseite aus aufbaust. Allerdings wird das vermutlich relativ unpraktikabel sein, wg. allerlei Unwägbarkeiten (Proxies sind nur eine Variante).

Von was für Unwägbarkeiten sprichst du denn da?
Wo spielen z.B. Proxies eine Rolle oder könnten ein Problem darstellen?


Liebe Grüße,
Frederic

[Assarbad]

Zitat von fkerber:

Von was für Unwägbarkeiten sprichst du denn da?
Wo spielen z.B. Proxies eine Rolle oder könnten ein Problem darstellen?

Wenn du von deinem Server aus eine Verbindung aufbauen willst und diese nicht vom Client käme, wie willst du bspw. hinter einen Zwangsproxy des Zugangsproviders oder in das NAT eines Routers dringen? Geht nicht - ergo: unpraktikabel.

[fkerber]

Hi,

ist das auch ein Problem, wenn der Client die Verbindung aufbaut?
Also der Plan an sich ist:

Die Handy-App kennt die Server-Daten und initiiert einen Login-Vorgang. Dazu wird eine Socket-Connection aufgebaut. Der Server weiß ja dann, von wo (IP) die Anfrage kommt und kann dann dahin was zurückschicken.

Das haben wir PC<->"Server" (allerdings alle im selben lokalen Netz) schon erfolgreich umgesetzt.

Wären die Umstände hier so anders?


Liebe Grüße,
Frederic

[Assarbad]

Zitat von fkerber:

ist das auch ein Problem, wenn der Client die Verbindung aufbaut?

Nein, dann wäre es kein Problem.

Zitat von fkerber:

Die Handy-App kennt die Server-Daten und initiiert einen Login-Vorgang. Dazu wird eine Socket-Connection aufgebaut. Der Server weiß ja dann, von wo (IP) die Anfrage kommt und kann dann dahin was zurückschicken.

Das haben wir PC<->"Server" (allerdings alle im selben lokalen Netz) schon erfolgreich umgesetzt.

Wären die Umstände hier so anders?

Ich merke hier hapert es bei Begrifflichkeiten. Klar kann der Server was zurückschicken, wenn der Client es anfragt. Aber was der Server eben in vielen Fällen nicht wirklich kann (ansonsten reden wir quasi über einen zweispurigen Tunnel) ist selber eine Verbindung zum Client aufzubauen.

Und dann wäre hier ohnehin noch die Frage ob (und wenn ja warum) die Verbindung persistent sein soll.

Prinzipiell würde es wohl reichen wenn der Client sich in Intervallen an den Server wendet. Von dort bekommt er bspw. die Info (statisch): ja, es liegt eine Aktualisierung vor. Dann - unter der Annahme daß du beide Seiten entwickelst - kann der Client sich doch an eine andere URI auf dem gleichen Server wenden und bspw. authentifizieren und dann bei nachgewiesener Berechtigung die Aktualisierung runterladen. Aber in allen genannten Fällen würde die Initiierung der Verbindung immer durch den Server stattfinden.