I need to either get an actually TCP connection between two android phones or minimally the ability to do a 4 step order dependent protocol ( A sends to B, B sends to A, A sends to B, B Sends to A) with small payloads (at worst 20kb per message )
This needs to work
without wifi, bluetooth, or nfc enabled (i.e. over 2/3/4G)
between Andriod phones and preferably between and Android and IOs as well as between iphones
Not require a third party server and preferably not require me to run a server
I am perfectly willing to make someone scan a qr code to "pair" the phones or exchange basic identifiers.
Is there anything better that I can do other than setting up my own server and running some network hole punching solution to open up a TCP or UDP stream between the two devices?
If there isn't, whats the best network hole punching solution for android?
What seems not to work:
Googles C2DM push notification seems to be meant for server to device messaging to trigger a pull.
Alljoyn seems to do exactly what I want in terms of messaging, except it appears requires users to enable wifi or bluetooth. The idea is to avoid using the cellular modem.
Android natively supports this for WiFI via this api, but again this is a non starter.
Finally, there is the Bump api , which does almost everything I want but requires a third party server. This is a no go on privacy grounds since the server learns when people use the app.
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 a situation where I want my computer in my local network to send a notification (push notification, SMS or whatever) to either an IOS of Android device that is on this same LAN. The trick is that I want to send this notification only when the LAN connection to the internet goes down. This means of course that my LAN cannot communicate with email servers, it cannot communicate with any APNs or GCMs, etc.
Is there any way to do this? My computer (the sender) is a Linux box and it will know the local IP addresses for any IOS or Android devices locally.
Yes this is possible.
You either need:
A) A server on the LAN to connect to, that the app knows about (compile-time or runtime configurable). The apps can connect to the server to exchange data, including messages. The server might be HTTPS, and the clients might poll every 5 seconds, or something more refined - using WebSockets.
OR
B) A peer-to-peer scheme. This can get quite complex, particularly given the varying nature of networking for mobile operating systems. As an extreme, you could use UDP for multicasting to multiple devices.
These are just two general examples, and you would need to research how to implement them for your needs. You should start with [A] for prototyping.
I'm planning to build an Android application.
In this app the users must be able to communicate each other when they are close (a priori fixed distance).
I think that the easiest way to implement this model is with a server-client architecture where every message goes from a client to the central server and then the server will forward the message to the target client.
CLIENT A ---M---> SERVER ---M---> CLIENT B
But this way the the system doesn't scale and, in a scenario with a lot of Clients, the Server will become the bottleneck.
I'd like to ask what are the alternatives (on Android) to allow two smartphones to communicate and exchange message in a bidirectional way when they are close to each other.
CLIENT A ---> CLIENT B CLIENT C ---> CLIENT D
CLIENT A <--- CLIENT B
For example, is it possible, assuming a distance small enough, a solution based on Bluetooth? Or it is possible open a TCP/UDP socket between the two devices?
You could use NFC (if the device has it) to pair the devices via Bluetooth or WiFi Direct. If you don't have NFC, simple Bluetooth pairing without it should still work, NFC just makes it convenient.
I have used this server solution, and it's pretty awesome: http://www.rabbitmq.com/
RabbitMQ is a messaging service with a pretty awesome interface for Android.
I can't speak as to how you would implement either bluetooth or TCP/UDP.
I am a little stumped. I've been trying to find a way for a wireless device (i.e. Android/ios/Windows mobile devices) to receive a message from a central server and then launch the device web browser.
The Scenario: a server on a WLAN network monitors a certain system. when something on the system goes wrong, the system stops what it is doing and sends an error message to the server and wait for the user to enter a response on the server before it resumes what it was doing.
Now, I want to send a message from the server(when the system it is monitoring crashes) to the wireless devices, so the user does not have to go to the server all the time to continue the system but can just do it over the wireless device (in the web browser).
Just to clarify, I know how to send a message out from the server to everybody connected to the wireless network, i just don't know what to do with that message on the devices...
Any ideas or solutions would be HIGHLY appreciated...
Thanks in advance
You can do this a few different ways:
1) Using commercially available Push Notifications (Google & Apple for example). The advantage is your application will work outside of your wireless LAN, but the disadvantage is you're using their platform, which is restricted in its ability and functionality (having designed and built a couple of these platforms myself I can attest to their limitations - they were going for "least common denominator" when they designed and implemented theirs).
2) If your app is only going to run on a LAN (you control the network) you can put your own system together. The advantage here is there is almost nothing that cannot be done (except on iOS which has several limitations related to the topic). The disadvantage, though, is this is a lot of work.
3) Leveraging an existing platform that might have been designed for a different purpose but can easily be used with minimal changes for your own purposes, and offers a nice compromise between options #1 and #2 (this will require some additional backend/middleware servers to add to your mix). Look at XMPP and Jabber as an example.
Once you have this piece of your architecture in place - receiving pushed data - the only missing item is invoking the handset's browser (or browser type component in your own native application) in response to the received payload.
** As possible alternatives it's worth noting that most mobile platforms allow your native application to directly interact with the handset's IMs or e-mails. For example, you can write code that intercepts a specifically formatted IM, with a small payload, and use that as a "poor man's push engine." I have put together little POCs (proof of concepts) for clients using this technique on Windows Mobile, BlackBerry, and Android (not sure what's possible with iOS in this regard) as it's quick and easy.
The hard part is the pushed data (but several available options on how to handle this requirement), the easy part is invoking the browser.
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.