Hi all I was wondering what options do we have to exchange data between two different android devices?
For example, User-A and User-B both installs my app. I would like User-A to send data (possibly just a simple message or user-A's location info) to User-B.
The functionality I would need is similar to the functionality that WhatsApp has. However unlike WhatsApp, I do not have a server and I was wondering if we could do data exchange between two different android devices without a server?
I was thinking we build it atop SMS or something.
Options for exchanging information between devices are the following:
Bluetooth - this would be between two devices in the near vicinity
TCP/UDP IP connection - this would be using TCP to open a socket directly to another server socket. That could be hosted on the phone or a shared server. There are pros and cons to both.
The pros of bluetooth would be no need for a central server. The big downside is this means you can only exchange data between two people standing within 20 meter range. The other downside is you have to pair the devices which not everyone finds easiest.
You can use TCP/IP connections to exchange data just like any client-server program you write on a traditional computer. This could be used no matter if your phone is using 3G/4G/WIFI/EDGE or future radio protocols. The problem is the IP address of the phone might not be globally reachable. The IP address of the phone might be a non-routable like a private IP. They might be behind a firewall or NAT address.
This is where a central server is probably needed to either exchange IP addresses for users, or serve as a common location for clients behind infrastructure that could block. This is where protocols like SWIFT come in handy for jumping firewalls. Even with things like P2P you still run into these types of issues with non-accessible devices, and tricks like this have to be used to crawl around them. Unfortunately, that means you probably need a central server even with the P2P model.
Without an external server to keep a list of all connected clients, you would need to implement communication in a P2P fashion. Depending on the needs of your app, you could have the user type in the IP address/email/phone number of the other user they want to exchange data with.
If you wish to use a server approach, you can sign up for Google's App Engine which has good Eclipse integration as well as a plugin to easily interface with an Android app. This would give you an infrastructure option without initially (or maybe never depending on how high you scale) having to put down any money.
Google gave a good IO talk showing an example of a web app that can easily communicate with an Android app. You could extend this to do what you are looking to do.
Related
I'm developing a mobile app that uses WiFi without internet connection (in order to communicate to an IOT device) and it uses cellular data as well (see TL;DR section for more).
The problem -> some devices don't automatically switch their default route to cellular (rmnet interface) while others are capable.
The workaround -> create a *"local" VPN in order to manage and re-routing network traffic via cellular interface (there are apps like Speedify that can do this by assigning priority to interfaces)
The question -> there is a simple way to accomplish this or it's pretty tricky? When I say "simple" I mean the calls of several well documented API and when I say "tricky" I mean to starting read and parse routing table with customized rules depending on every vendors?
"*local" = a VPN without web server or VPN gateway because I'm not actually interested to do the VPN's job (I seem to have understood that I need a VPN level to manage network traffic of others app but I'm pretty newbie of VPN topic)
TL;DR
My goal is to remaining connected to my access point (in order to call its APIs) AND use cellular data for all others requests I.e: login via my backend, use Google Maps and so on.
Handle this scenario it's quite easy because combining network objects, socketFactory and bindProcessToNetwork I'm able to do this.
Troubles come for others app like YouTube, WhatsApp that stop working because as default network they are using my access point without internet (Android doesn't switch default interface to a cellular)
I'm going crazy because seems that each vendor (or Android OS version?) handles "WiFi without connectivity" with cellular active in a different way.
There are certain devices that all work fine (similar to iOS) but there are others that it's a nightmare.
See this question for further details
Thanks for reading, I really love Android but those issues make me sadder every day more and I'm thinking to pass to the Dark Side of mobile development (iOS).
You've the chance to change my mind ;)
I'm making an app using bluetooth, and I realized it'd be pretty neat to exchange data between 2 running devices via bluetooth.
However, as far as I know most Bluetooth devices use a traditional server/client architecture, so the information exchange is one sided, ie, client requests data from server, server sends it, but not the other way around.
To get around this problem, I tried to make each device have a server instance as well as a client instance, so that the client can hook up the the server in the other device. However this does not seem efficient as this requires 2 channels of communication instead of one.
Then I tried going to Bluetooth website, and they suggested "role switching", that is, when server wants some data from client, server makes itself a client and client becomes a server, so the role is reversed. I don't quite like it either, because why can't 2 devices play the same role and exchange data at the same time? What kind of connection is this called then?
I have not had experience in networking so my question might seem naive, but I'd like to have someone point out the answer, or tell me what information/which chapters of textbook I'm missing so I can wiki it.
Role switching affects the underlying Bluetooth topology: which device is master in the piconet. That can have implications for the quality of your connection, but it does not directly affect the direction of communication in the way that you are imagining: it is at a much lower level.
Yes, in Android Bluetooth comm is done using sockets abstraction and the setup of the socket connection is done in a client-server manner. But once the socket is connected both sides have a BluetoothSocket instance and I'm pretty sure that both sides can get an output stream and initiate communication. What makes you think otherwise?
I am developing a turn based two player android game. Is it possible to use one of the user's mobile as server rather than an external server to coordinate the game ?
I do not need much data storage. only 40 fields(text or numbers) to be stored and transmitted (for transmission , one value at a time) while the game is on. after game is over only user's current score is to be stored.
I guess to do any such thing I need to get ip of the mobile. Is it possible ?
You need more than just the IP since the IP is just an endpoint on the Internet and there is no guarantee that it is your device that answers if you talk to that IP. There is usually a local network behind that IP and you can't access devices in there with just the public IP.
The problematic part is establishing a direct connection which is (usually) not possible on the Internet unless you are in control over the Internet connectivity (router etc) and can setup port forwardings / firewall rules / whatever blocks direct connections. If you have no access - for example because you use 3G where the "router" is at your provider's datacenter - you will need at least a server to do things like hole punching.
Also a server used to find other's games (and IPs) would be a good idea.
You can however do all that if both devices are on the same WiFi and they can see each other directly.
I am from Skiller and I think we have exactly what you need.
#zapl is right, if you want your players to connect to your games using 3G or WIFI connection the best solution will be intermediate server that makes it possible to exchange data between the players. Setting up, hosting and scaling such a server may be very expensive and time consuming thing. We provide FREE SDK tools, using which you will be able to set up your turn based two player game in no time. We are handling all the server side maintenance so you could just implement the game logic and fire your game to the market asap.
Download the SDK from www.skiller-games.com and tell me what you think.
If you have any questions write us here or to developers#skiller-games.com
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.
can anybody confirm what are the currently allowed methods for peer-to-peer communications within the Android framework? I need to transfer json strings and I'm currently using SMS which works ok but the problem is that the data also ends up as lots of text messages. I've read Reto Meier's first edition of Professional Android Application Development where he says that the data transfer options were not implemented due to security concerns.
Has this changed at all and how would you do peer-to-peer transfer of data?
Have you looked at Qualcomm's AllJoyn library? It is designed to work over Bluetooth or wifi, so may fit, though if you're connecting over 3G or wider range networks it won't work.
Given the variation and reliability of networks between two remote devices not on the same network, I'd question whether peer-to-peer is the best solution, and would venture to suggest considering using an application server in between, so you could then use Cloud to Device Messaging [deprecated] (perhaps in tandem with Google App Engine). i.e. to send a message the sender passes it to the server, and the server then passes it on to the recipient.
In theory all devices on the net have a unique IP address and can talk to each other, but it's rarely that simple as routers/firewalls are configured differently so you'd need to pay great attention to the ports you use, especially considering many inbound ports are blocked by default for security reasons.
You can simply use UDP/TCP sockets. In a separate thread you set up the server-side listener socket and that's it. Of course your application has to be started first (or should run in the background all the time). Here's an example:
http://thinkandroid.wordpress.com/2010/03/27/incorporating-socket-programming-into-your-applications/
If you also need peer discovery that will make the thing more difficult.
You should also take a look at peerdroid, an open source project available here. I've been looking in to peer communication options from the point of view of having a collection of federated devices (pre-paired, if you like, similar to Bluetooth pairing); this library looks like it may give you the foundation for what you are trying to do.
If you are on your own network (for example a home or office WiFi) then you should be able to query for other connected devices. If the network you are on is not under your control (the mobile network or a public wifi) then the network will have been configured to isolate each device from everything else. In this case you will have no choice but to put a server up to act as the man in the middle. That brings its own architectural compromises - every device has to regularly poll the server or keep a connection open - unless you use Google App Engine which supports push notifications over Google's own infrastructure.
Thanks for your answer ldx but I would need peer discovery as you indicated. Some further research appears to indicate XMPP as a suitable technology and there are now some services on offer, although these appear to be aimed at 'server' to client notifications. There is a good discussion here on XMPP and some more here although it would appear that there are still some issues to deal with such as polling v push, long-running open http connections and battery life. Xtify looks promising, especially their web service. I hope this provides suitable information to others looking at the topic of peer-to-peer data communication.