I have to develop a chatting application and I want to use socket connection. is there a way in android for it. Which will be better way for long time application.
Give me suggestion about it.
Have you looked at the Sockets class? You can use sockets to write and read data between two clients in background threads that update the UI thread with the data received/sent.
Generally with sockets one device (the client) connects to another (the server) and it is expected that the server's hostname will not change. However, you can't guarantee this with devices on mobile networks so a better approach might be to have two devices connect to a well known server that relays chat messages through. If you're just trying to do a basic chat application between devices on the same LAN it would be fine to directly connect them however.
https://developer.android.com/reference/java/net/Socket.html
Related
Is it possible to do a chat between client and server (two android devices) using socket programming in android?If possible,anybody please offer me a help.Even a link is acceptable.
It is possible. you can use socket programming and create chat application with 2+ devices. one device must act as server and others have to be client. if your want to your server to be android device and don't want have web server side it does not need an internet connection. just a access point or one mobile hotsopt is enough. but all device must be connect to same hotspot or access point.
I wish to create a Cordova/Android app that will be called/executed from my server. Both devices are on the same intranet and connect via WiFi, therefore no cloud messaging required .
For another scenario I have done the opposite. i.e. Android calls, via Ajax, an application on a Raspberry Pi for door opening purposes but this time I want to call an Android application from a Raspberry Pi. Where do I start? Ajax? Socket Server? What is the recommended connection method?
I think that websockets are the way to go. Implementing such a real time application allows you to 'push' data from the server to connected clients.
This can be initiated by clients (like in a chat application) but also by the server based on whatever events.
Have a look at Primus as a possible implementation. It abstracts the functionality from the websockets layer. This way it is possible to work with different websocket implementations.
Most chat applications can run both server and client simultaneously, well in my case all I need is to connect all devices that uses my app to share data( gson object), in official documentation, I found direct WiFi connection (p2p) which doesn't work if the other device is not on local network, and socket ( server client separated ), which work only one way one device for sending and the other for receiving.
So does anyone have an example of connecting two or more devices trough internet by running both server and client socket in the same time.
It's not so simple. The simplest is that each сleint create server. And every minute was looking for other servers on the local network. For example, sending a certain packet to a port.
Look about it here.
Then you will not care how customers relate to each other.
I have a simple app idea in my mind and I need to know how to connect from an Android application (client) to a Windows application (Delphi, server).
There is no need to be specific about the platform, I am familiar with networks in Delphi using winsock or Indy and I'm sure I will be able to figure out the appropriate mechanism in Android.
What I need to know is how to connect to a server (computer), which doesn't have its own public IP and is not in the same network as the client (one can be behind a local router, while the other might be connecting to the internet through 3G, for instance). This should be possible, as many programs work like that (remote desktop programs, TeamViewer, for instance: one computer is assigned an ID and using this ID other computer can connect to it.) I will not have access to the routers behind which the app will be running, so port forwarding is not an option.
I have a working network app, but that only works in LAN, so I'm guessing somewhat another approach is needed.
Thanks for answers
Many of the programs that work that way still use a server with a public IP. Each side of the client connections to the server to say "here I am". The public server can then shuffle data between the two clients.
That still leaves a lot of questions regarding the communication between the public server and each client - i.e. pull vs. push for taking data that was sent to the server and getting it back down to the second client.
You may want to read the specification for Copilot (originally named Project Aardvark). Joel Spolsky published the specification when the started the project. It talks about their use of a reflector service.
The Reflector
A Windows Service which we run on our servers, used to
allow any helper to help any victim even when both of them are behind
firewalls. Both helper and victim connect to the reflector. The
reflector checks that they are authorized and relays messages between
helper and victim until the paid-up time runs out
you could put an intermediate server which they can both route for "nat traversal".
otherwise you will have to put port forwarding on one of those computer's local router to allow incoming connections to be forwarded to the computer.
I'm building a multi-OS mirroring system which I would like to implement using a hybrid client-server and p2p communication method (at least that's the best way I have of describing it).
My issue is that at some point I have a central server (appengine, so there are limitations to what I could do because of time and networking capability constraints) that would need to get a message to a host of different devices which are not necessarily running the same OS (Windows, Android, iOS, Linux, etc...).
Android and iOS (or any other mobile platform) are the main problems it looks like I will be having on 2 levels.
1 - They are both limited by battery power (more so than a laptop and desktops shouldn't have that issue at all), so whichever method I use needs to take that into account.
2 - NAT (harder because the user has relatively less control over their firewall than on a network that they are running). My central server will maintain a table of which device has what IP address, but from what I understand if there is NAT or a firewall it won't be able to get to it if the port was not forwarded.
Since I will be writing a specific client for each OS I prefer a solution that is more universal. I have been leaning towards writing an extremely simple HTTP server that sits on each client and takes requests (which appengine is able to send) and treats them as messages that alert the client to perform an action (either with the server or another client). However, I run into the issue of NAT/firewall. For instance if appengine needs to send a message to AndroidDevice1 it would grab its IP address from a table and make a request to it. However this doesn't work if the ports aren't forwarded correctly, and if the user is on 3g/4g the firewall is controlled by the data provider.
Because of this, I started thinking about using Android C2DM but I want a solution I could implement across platforms.
The only other method I could think of is to just have the client poll the server for messages. This has the battery and network consumption issue though.
Would there be any other way to implement this, and if not, which one of the above methods are best in terms of balancing usability, power and data consumption and user input (the less the user has to do to get the client set up (ie port forwarding, etc...) the better)? Please note that I do not intend for this to become a discussion/flame war but a logical presentation of facts.
Thanks in advance!
You can create a persistent TCP connection from the device to the server and then communicate over this open connection. This would be a very simple connection with keepalive packets for the most part.
In theory this would consume some battery through the radio, but in practice I have experienced that the battery is not affected much at all. Key is to keep the communication over this line to a minimum.
If AppEngine does not allow this approach, you can run your own socket server and then communicate between this server and the appengine server using REST. A socket server I have used is Apache MINA and had no issues with scalability.
Another problem you will have with this approach or any other approach is that on iOS (afaik) you cannot keep a tcp socket open when the App goes into background. The only thing to communicate with the iOS device is Apple Push Notification Service
I would prefer rather than having HTTP Connection you should create TCP/IP tunnel and make communication fast and reliable. I have one Chat application which runs perfact for me using TCP/IP. If you use this you will have same logic for multiple platforms. Only thing you need to write is different code for iOS and android.