What is the general communication architecture for two android applications?
Case 1:
I have two android applications,
a) One is a server that waits for client request, process the request( read data from some sqlite db) and return the results to the client. This server application runs on its own independent android phone.
b) The second is the client that sends the request to the server application in (a) and it too runs on its own independent android phone.
Question is, do the two applications have to go through the Mobile Service Provider to enable communication? or they can just talk to each other directly via some public IP/WIFi etc. What is the communication structure/architecture for this applications?
Case 2:
I have an android application running on an independent android phone, and i want it to talk to some server application (Web Server / Application Server) running in some machine somewhere on the internet, sends request and get some feed back.
Again, do the two applications have to go through the Mobile Service Provider to facilitate communication? or they just establish a straight TCP/IP communication via some public IP?
Any reference articles would really help.
Thanks
Gath
Question is, do the two applications
have to go through the Mobile Service
Provider to enable communication?
If you want to use 3G, yes. If you want to use WiFi, no. Generally, Android applications do not care where the Internet connection comes from.
or they can just talk to each other
directly via some public IP/WIFi etc.
If they have a WiFi connection, they have a WiFi connection. What you do with that WiFi connection is up to you, using Java sockets, and respecting all the normal problems with Internet access (e.g., NATs).
Again, do the two applications have to
go through the Mobile Service Provider
to facilitate communication? or they
just establish a straight TCP/IP
communication via some public IP?
You ask for a Java socket. You get a Java socket. You do something with the Java socket. Where that Java socket comes from and how its connection works is generally under the covers: 3G, WiFi, a squadron of very tiny passenger pigeons, etc.
I'd suggest Android – IPC, aidl and IBinder and Grasping Android's IPC mechanism for a start. After that just hunt on Google for 'Android IPC'
Something about sync is here Synchronization in Android
Related
just want to know is there any methods to allow 2 different apps to communicate. Both of the apps are installed on different devices as well. I had gone throught quite a lot of research, but seem that INTENT, BROADCAST RECEIVER failed to meet my scenario. INTENT, BROADCAST RECEIVER can be work if both of the apps installed on the same device.
Here i can say you can use to make your things work :-
Sockets are typically used to accomplish this between Android devices (or between any peer devices).
When two devices desire to interact, you configure one or both of them to "listen" for connections on a socket and accept a connection from the other when that happens (or you can have a dedicated client and server and the client always initiates the connections).
You can exchange messages after the link has been made.
Android client server socket applications come in a variety of forms, but one that I found handy was:
Example of Android Server/Client using Socket on the client side (and its companion server side blog article - link included in the client blog)
It should be noted that you might need to add your own "protocol" on top of this. For instance, if you are sending a file that is unknown in length without a special "end" character, you might want to add a byte (or several bytes to represent an int, long, etc.) at the beginning to indicate the length of the transmission so the receiving side can tell when it has received everything (or that it has not received everything in case of an error).
connecting via networks (such as most 3G/4G) that forbid inbound connections
Even though there is nothing theoretically blocking sockets from functioning in these situations, many mobile operators will not permit inbound socket connections in practise. You would also need to determine the mobile's public IP address, which is doable but adds complexity. Whether your solution will only ever operate on a single operator's network, you can test it out to see if it works; but, if it doesn't, you could discover that using a server in the "middle" is preferable and easier: Devices A and B establish connections with servers Device A "discovers" device B after requesting the addresses of connected devices from the server. Device A sends device B a message.
Actually, it indicates that the messages should be forwarded to device B while sending them to the server. Device B is informed by the server that a message is available for it (using some sort of message notification like Google Cloud Messaging for example, or simply by the devices polling regularly to see if they have any messages). Device B accesses the server and downloads the messages. The aforementioned will function on pretty much any network that permits internet connectivity. It does have the drawback of having a server, but for the majority of mobile networks, it is probably a necessary approach.
You make one app a server using ServerSocket.
You make the other app a client using a Socket.
With both devices in the same network the client can connect to the server knowing its local ip.
After connection established they can communicate.
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
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.
I want to connect a web service to android phone i.e. a request is to be made from web service to android phone. All i can find is article about android to web service but in it (as far as i know..may be wrong) a request is sent to server from android but i want vice versa.
Most carriers give you an IP address inside their networks, so you can't access the devices through any standard method. If the device is online via WiFi then you may have a chance (depending on your ISP and router policies, and given the case you have a web server or a permanent socket listening for requests). Nevertheless, it's still a very bad idea.
I would recommend you to use a different approach: make your android device call a Web Service that recognizes it (either via IMEI, IMSI, both, or a user parameter, depending on your app) and see if it has some "news" for him. If it does, then it should take an action depending on the received data. If you're familiar to Java, it's roughly like the MDB (EJB) idea.