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:

Zitat von fkerber (Beitrag 1061030)

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:

Zitat von Assarbad (Beitrag 1061033)

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:

Zitat von fkerber (Beitrag 1061041)

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:

Zitat von fkerber (Beitrag 1061050)

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

Nein, dann wäre es kein Problem.

Zitat:

Zitat von fkerber (Beitrag 1061050)

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.

[fkerber]

Hi,

ja, vllt. reden wir wirklich etwas aneinander vorbei.
Also ganz am Anfang wird der Client sich einmalig beim Server melden und sagen "hier bin ich".

Dann wäre die Idee, die Verbindung aufrecht zu halten und bei Bedarf (es gab eine Aktualisierung der Daten auf dem Server, z.B. durch anderes Handy) den offenen Kanal zu nutzen, um diese Info an das Handy zu übertragen.

So hatten wir es bei dem anderen Projekt gelöst (allerdings PCs statt Handys und alles nur lokales Netz).


Daher war die Frage:
Kann ich das quasi 1:1 umsetzen oder ist das vllt. nicht so klug?

Ein Problem sah ich schon bei evtl. Internet-Verbindungs-Abbrüchen auf Handy-Seite.


Wäre deiner/eurer Meinung nach die folgende Variante besser:
Handy fragt alle x (x = ~10s) den Server an und bekommt alle relevanten Infos zurück. D.h. der Server würde immer nur antworten und niemals selbst initiiert etwas senden (unabhängig davon, wer den Verbindungsweg geöffnet hat).


Liebe Grüße,
Frederic

[Assarbad]

Zitat:

Zitat von fkerber (Beitrag 1061061)

ja, vllt. reden wir wirklich etwas aneinander vorbei.

Denkbar.

Zitat:

Zitat von fkerber (Beitrag 1061061)

Also ganz am Anfang wird der Client sich einmalig beim Server melden und sagen "hier bin ich".

Dann wäre die Idee, die Verbindung aufrecht zu halten [...]

Wieviele Clients erwartest du? IPv4 oder IPv6? Bei IPv4 wirst du schnell an Grenzen bzgl. Sockets/Ports stossen.

[fkerber]

Hi,

Ich denke, nicht mehr als 30 Clients auf einmal. Aber schon das wird wahrscheinlich praktisch kaum vorkommen. Es geht hier um ein Studentenprojekt, das mit 3-6 Geräten getestet werden wird.
Über dieses Stadium werden wir kaum hinauskommen

IPv4 oder IPv6 - tja gute Frage.
Wenn wir im Uni-Wlan sind, v4 - was nutzen denn die Handy-Betreiber so, wenn ich über UMTS&Co drin bin?


LG,
Frederic

[Assarbad]

Zitat:

Zitat von fkerber (Beitrag 1061065)

Ich denke, nicht mehr als 30 Clients auf einmal. Aber schon das wird wahrscheinlich praktisch kaum vorkommen. Es geht hier um ein Studentenprojekt, das mit 3-6 Geräten getestet werden wird.
Über dieses Stadium werden wir kaum hinauskommen

Aaaaah. Na dann ist es auch bei IPv4 kein Problem. Und HTTP kann persistente Verbindungen, muß aber angefordert werden. Aber meines Wissens nach kann der Server nicht einfach was ohne Anfrage zurückschicken. Ich nehme an, daß dort die von Markus genannten Technologien reinkommen. Allerdings ist es auch nur eine Illusion die von AJAX erzeugt wird. Der Informationsfluß ist immer, daß der Client eine Anfrage sendet und der Server diese Anfrage beantwortet.

Zitat:

Zitat von fkerber (Beitrag 1061065)

IPv4 oder IPv6 - tja gute Frage.
Wenn wir im Uni-Wlan sind, v4 - was nutzen denn die Handy-Betreiber so, wenn ich über UMTS&Co drin bin?

Die meisten vermutlich noch IPv64, leider.

[fkerber]

Hi!

noch IPv6?!
Gibt es noch etwas Neueres?


LG, Frederic

[Assarbad]

Zitat:

Zitat von fkerber (Beitrag 1061068)

noch IPv6?!
Gibt es noch etwas Neueres?

:wall: ... meinte IPv4

[FBrust]

Hallo,

bei "ungefragt" fällt mir nur die Möglichkeit ein, den Handys eine SMS zu schicken, die wiederum die Android-Applikation veranlasst, eine Verbindung zum Server zu etablieren. Frag mich aber nicht, wie das geht, hab nur gelesen, dass sowas möglch ist (hab erst mit Android-Programmierung angefangen :))


Grüße
Frank

[mjustin]

Für Nachrichten vom Internet an ein Android Telefon bietet Google die C2DM (Cloud To Device Messaging) Technologie an.

Diese ist in einem öffentlichen Betatest. Die Home Page ist

http://code.google.com/intl/de-DE/an...2dm/index.html

Mit C2DM kann sich ein Android Telefon für bestimmte Nachrichten auf einem Server registrieren, und erhält von diesem dann Benachrichtigungen, auf die das Programm auf dem Android dann reagieren kann.

Man braucht keinen Webserver aufzusetzen zu dem sich die Androiden verbinden, da die Cloud Infrastruktur von Google (namens App Engine) genutzt werden kann.

Da alle Komponenten, einschliesslich der Nutzung der Google App Engine, bis zu bestimmten Quotas auch für kommerzielle Anwendungen kostenlos sind, habe ich das Beispielprogramm mal getestet und es tatsächlich relativ schnell zum Laufen gebracht.

Für manche Einsatzbereiche ist es sehr gut geeignet, vor allem um Anwendungen auf dem Android zu benachrichtigen die nicht in einem HTML Browser laufen, sondern direkt auf der Virtual Machine.

Update: die Anwendung, an die die Nachrichten gesendet werden, muss zu diesem Zeitpunkt nicht bereits gestartet sein: sie automatisch 'geweckt', vorausgesetzt sie wurde mit den richtigen Rechten konfiguriert.

[fkerber]

Hi,

das klingt genau nach dem, was wir brauchen!
Leider gibt es doch massive Einschränkungen, die wahrscheinlich verhindern werden, dass wir es einsetzen können:

*) Android 2.2 als Voraussetzung
*) Diese Beta-Test-Anmelde-Prozedur etc...

Aber danke trotzdem.


Liebe Grüße,
Frederic

[mjustin]

Weitere Möglichkeiten sind hier beschrieben:

How to Implement Push Notifications for Android

http://tokudu.com/2010/how-to-implem...s-for-android/

MQTT scheint eine Alternative zu C2DM zu sein.


Den Link habe ich unter dieser Stackoverflow Frage gefunden, dort werden weitere Optionen genannt:

http://stackoverflow.com/questions/1...h-notification

Viele Grüße