Java [Android] Konzept- und Umsetzungsidee von Client-Server App mit TCP-IP Sockets

[Firestorm-]

Hallo zusammen,

ich benötige einen Rat...

Ausgangslage:
Es besteht ein Server der, mit TCP-IP Sockets mit Clients kommuniziert. Dabei nutzt er ein ganz bestimmtes Protokoll, welches textbasiert ist und als Bytestrom, nicht als Zeichenstrom übertragen wird. Der/die Client ist eine Android App Version 4.1 oder höher. Logischerweise implementieret der Client ebenso das Protokoll und nutzt dabei auch TCP-IP Sockets. Der Client als solches ist bis auf die Views/Acitivites noch nicht umgesetzt, da ich mir nicht wirklich sicher bin was besser ist: Ich benötige ein Konzept, mit dem ich Nachrichten sowohl vom Client schicken als auch auf dem Client vom Server empfangen kann. Abhängig davon, was in einer Nachricht vom Server steht, sollen die Activties mit Inhalt gefüllt werden. Beispielsweise startet die App mit einem Login. Der User gibt die Daten an, klickt auf Anmelden. Jetzt sollen die Daten zum Server übertragen werden, der Login auf dem Server ausgeführt werden und sofern erfolgreich, eine Statusmeldung zurück an den Client geschickt werden, der darauf wartet, diese zu empfangen. Jetzt kommt die Unterscheidung: Wenn in der Statusmeldung steht, dass der Login erfolgreich war, soll mit einem Intent die neue Activity geladen werden, wenn nicht, irgendeine grafische Ausgabe erscheinen, die den User darüber informiert, dass der Login fehlgeschlagen ist.

Wie würdet ihr das umsetzen? - Ein Service brauche ich nicht, da die App nicht länger laufen soll, wenn sie minimiert ist. Idealerweise soll dann die Connection "gepaused" werden. Deshalb würde ich ein Singleton nehmen, welcher sich eine Connection hält, die solange sie läuft vom InputStream liest. Problem daran: Ich kann den Thread nicht ohne weiteres starten, da er Bestandteil des UI-Threads ist und damit bad practice wäre. Wäre also ein Einsatz von AsyncTasks sinnvoll hier? - Wenn ja, hättet ihr ein Codebeispiel, bei dem ich eine Connection über mehrere Activities mit mehreren AsyncTasks nutzen könnte?

Vielleicht bin ich auch voll auf dem Holzweg, aber ich frage mich wie Beispielsweise Apps wie ImmoScout24 dies umgesetzt haben. Anfangs wird vom User ja auch nur ein Formular mit Suchkriterien ausgefüllt und dann der Request zum Server gesendet und eben so lange gewartet, bis das Ergebnis (zumindest die Texte) ausgeliefert sind und erst dann wird der Content auf der Activity wirklich sichtbar. Ist das auch mit AsyncTasks umgesetzt?

Vielen Dank für jegliche Hilfe im Voraus.

Grüße

 

[tender89]

Immoscout24 basiert auf php/mysql Basis . Da wird nicht mit Sockels gearbeitet. Ich glaube du bist auf dem UHOLZ weg. Sickest werden eher für Chat Programme benutzt die dann immer den Port abhorchen. Ich hab eine Beispiel APP auf meinem Rechner die sowas in der Art wie du gerade baust abdeckt. Ich könnte sie dir morgen schicken. Vorraussetzung ist halt php MySQL aus Server und Java Basis. Ist aber nicht schwer wenn man sich reingearbeitet hat.

MfG isi

 

[blackst0rm]

Singleton ist schon mal eine gute Idee. Ich verstehe deine Aussage nicht das du den Thrrad nicht starten kannst. Wenn du einen neuen Thread erzeugst ist der unabhängig vom UI-Thread. Um über eingehende Nachrichten informiert zu werden bietet sich ein Callback Mechanismus an.

 

[ice-breaker]

Immoscout24 basiert auf php/mysql Basis . Da wird nicht mit Sockels gearbeitet. Ich glaube du bist auf dem UHOLZ weg. Sickest werden eher für Chat Programme benutzt die dann immer den Port abhorchen.

Und das PHP sendet die Antworten über das HTTP-Protokoll, das HTTP-Protokoll basiert auf TCP und TCP ist ein Socket.
Ob er nun die Antworten über HTTP schicken möchte oder TCP ist doch egal, es spielt keinen Unterschied, er ist eben nut mit HTTP ein Layer weiter oben und macht sich die Entwicklung leichter. Er hat aber ggf. gute Gründe wenn er direkt TCP nutzen möchte indem er nämlich ein binäres Protokoll nutzen könnte und damit einiges an Bandbreite einspart

Eventuell entscheidet er sich ja auch, dass UDP sinnvoller als TCP ist. Da er keine Verbindung aufbauen (mehrere RTT für Handshakes gespart) und er Reliability einfach durch mehrmaliges Senden implementieren kann. Und seine Anwendung besser darauf reagiert, wenn der Nutzer mal kurz das Netz verliert, die UMTS-Verbindung getrennt wird um auf LTE zu verbinden usw.

Und btw. ist deine Aussage sowieso falsch. Man sieht schon an der URL, dass Immoscout auf Java aufbaut (*.jsp, jsessionid)