I will have two android tablets working in the same retail location, both connected to a local network.
A customer will use one tablet to place an order. That tablet needs to send a notification to another tablet when the order is placed.
I am using a MySql database, and I could poll constantly from the tablet that needs to receive information, but that would drain the battery.
I could use C2DM, but it is absolutely necessary that the system works even if there is an internet slowdown/loss of connectivity.
How can I do what is basically C2DM over a local network from android device to android device? No android device will have cell phone service.
You've asked a general question so the best I can do is give you a general answer. Traditionally, Long Polling has been used in this situation. Essentially, the first tablet polls the second tablet. When the second tablet gets the poll request it just sits on it until it actually has something to tell the other device. Once it has a message to send to the other device, it responds to that initial poll request.
Before the introduction of C2DM we used the XMPP protocol to provide Push Notification.. the best library to acomplish that function was asmack.
Althought, C2DM works perfectly with loss of connectivity (when you reconnect you receive the missed messages)
Related
I want to make an application is via WiFi would send and receive data without sending them to a specific recipient. I explained to the example of a simple chat: The user sends a message via WiFi, but without a specific destination. As a result, his report available to all users nearby. Similarly other users can receive and send messages. I also want to realize the function of repeater, where each user's device not only receives a message from the other devices, and retransmits them to others allowing increase the coverage area of WiFi connection.
But at the moment it is not possible to send data without a specific recipient. The same WiFi Direct necessarily require pairing before data transfer. Can not specify that the recipient is unknown.
Recently I heard the news about the technology WiFi Aware, which involves greater interaction between WiFI devices. Please reply, WiFi Aware allows to do what I described above? Namely - the transfer of data and we will without a clear indication of the recipient and the need to do additional work (eg preliminary pairing between devices).
If WiFi Aware allows to do what I described - when it is expected to release its API? In particular, for Android devices. And if not - you can tell me how to implement what I need? And in general - it is technically possible?
Thank you for your time and sorry for my bad English.
You should try to look into nsd via wifi-direct. This Network Service discovery via Wifi-Direct. What this helps you to achieve is broadcast information to all listening devices.
On the device which wants to convey the information you addLocalService and on the other devices you should discoverServices. In the ServiceInfo object you can the pass the information you want to communicate to the other devices who are listening for services. Please try to study from the link attached above.
I am not very sure about how repeater will work with this.
My question is that is it possible to send and receive data between multiple android devices via broadcasting over wifi without establishing p2p connection?
Our professor asked us to design a wireless network system in which you broadcast a message within your android phone, and the other android phones nearby receive it and broadcast it again so that the other phones can receive it and it continues like that. In this way, for example, when someone writes a message in a classroom or café everyone will be able to receive it and broadcast it again. (like an adhoc network system). And although my professor believes it can be achievable, I didn't find anything online like this kind of android network system. So my question is again is it possible to do something like that?
Any helpful leads and references will be appreciated.
Edit: I had to change the title of the question.
I couldn't find a proper solution so I tried the following method so far: I set up a UDP messaging app using Wifi hotspot (it works perfectly for multi clients). The phone who turns on the hotspot is the server and others who connect to it are the clients. Then, I decided to turn this system into an adhoc-like system where there would be more than one hotspot and the clients would connect to them in cycling order and serve as a bridge among these servers.(every second, they will switch to other hotspot and vice versa.) So, they will carry the messages from one network to another. (I know it is very inefficient and prone to time delays; but it is the only idea I have come up with so far.)
When I told this system to my professor, he said that it is too complicated and I just need to broadcast a message from a device to a common channel(without setting up a network connection), and other devices will listen to this broadcast channel(without connecting to a network system), receive the message and broadcast their own messages along with received ones to this channel again as I described in the question body. (he never mentions hotspot, Wifi direct, and etc.) He even told me that the only thing I need to do was to think simpler and use the properties of 802.11. But, I do not think it is that easy to set up such a wireless system, at least for Android where ad hoc systems are not supported yet. So any help will be greatly appreciated. Thanks!
The Nearby Connections API in Google Play Services released last week uses WiFi multicast: https://developers.google.com/games/services/android/nearby
It works for devices already on the same WiFi network. However, it uses a host/clients model, and doesn't work with WiFi direct or a tethered hotspot connection.
You could also use the WiFi direct APIs from ICS: https://developer.android.com/guide/topics/connectivity/wifip2p.html
You can have multiple devices connected together via WiFi direct, so firing UDP packets as #willis suggests would seem the way to go
It is implementable. Do you know the aircrack? similarly, you can receive all packets even not sent to you, and you can send any kinds of packets even not sent by you.
I want to send notification from one android device (android tv without bluetooth, telephony) to another android device (phone/tablet). Both are on same wifi network. Through the notification, I want to launch an app or open a page in phone/tablet browser.
I went through GCM messaging and also saw some options where we can have a kind of http server on the phone running but could not understand implementation.
Can someone help with idea and if possible, some piece of code as well.
As I need it for demo, so even any hack solution is fine for me :-)
Thanks for any help or reading.
Your best bet as a hacky solution is to do simple Socket connection between two devices. Since they are on same Wifi, it will be simpler and won't have any firewall restrictions.
Avoid GCM, it requires setting up a GCM Server and then complex registration. It also makes your solution dependent upon Internet connectivity & Google ofcourse.
See an example here:
http://android-er.blogspot.in/2014/02/android-sercerclient-example-client.html
Basically one device such as TV can be a socket listener. The phone/tablet can connect to that socket and then you can initiate a notification on either device based on your requirements and data exchange.
As the topic name suggests, what I am looking for is to add my android app the option to send data to a different phone running the same application so the receiving phone will process it accordingly.
The obvious option for me was to use app engine and use push notification with the phone number acting as the identifier.
Does a simpler solution exist?
Thanks ahead :)
The best and most robust solution is to have something like your messaging clients, in which Device A sends data to the server, which pushes it to Device B. Device B sends a reply to the server, which pushes it to Device A.
This process has the advantage of retrying the sending without requiring your users to stay connected, as may be required if Device B is offline when A sends a message.
A less foolproof solution is to have a server work as a middle man, and get each device's IP Address, and then open up a direct socket between them. In this solution, you'll lose any data that doesn't make it through.
If the devices are on the same network or in Bluetooth range, you could try Bluetooth or WiFi direct.
I am having issues with C2DM. Sometimes works perfectly, sometimes my messages simply do not get pushed. Is there reliable way to enforce this connection? To pull messages. I read somewhere that what google do is keep low bandwidth TCP connection to their server at all time. So I assume that
when switching between network types TCP connection falls down and Android tries to reestablish connection to C2DM servers. So that might fail on WiFi with restricted network. Is that wrong assumption?
I have noticed with WhatsApp that on WiFi sometimes I do not get messages. When I switch to 3G I usually get them at the moment of the switch. What tips from your experience with C2DM would you offer?
C2DM is not suitable for critical parts of your application, since Google currently does not offer an SLA or paid tiers that will guarantee you reliable service and throughput.
I've considered several alternatives myself: XMPP via asmack, Parse, Deacon, Urban Airship, and MQTT.
After some reading and experimenting I decided to go with MQTT. It is a very lightweight telemetry protocol invented at IBM that fits quite nicely in the Android push notifications scenario. I recommend you give it a try, here's a nice blog post to guide you: Using MQTT in Android mobile applications.
Hope this helps.
C2DM does not guarantee that your message will be delivered, and your application should not assume that in order to work correctly. Therefore, your C2DM message should never contain the data itself but, rather, a notification that there is data available. In other words, the loss of a C2DM message should never cause your application to lose data; it should, at most, cause it to take longer to notice that a certain piece of data is available on your server.
A typical app should connect to its server once in a while (a long while) to retrieve messages, even when using C2DM, to cover the case where C2DM messages might not be delivered.
Depending on network configuration, the device might not be able to receive C2DM messages; restrictive firewalls or other strange WiFi configs might do that.
With C2DM reliability is not a guarantee. So best to have a ACK
message or some way in which you (the sender) the realize the message was received successfully.
Also make it a point to override onRegister class properly because the device Reg ID keep on shuffling.
Lastly, if you are planning to send updates regularly, I'd prefer polling to C2DM just because of the amount of requirements to get it functioning while reliability and ultimate control is still not assured.
I've been struggling with the same problem myself. The behaviour you describe is accurate. I'm developing an app that uses c2dm mainly with Wifi connection, and I had to implement an AsyncTask to periodically (minute and a half) call WifiManager.reassociate() (turning wifi off and on again triggers the arrival of all pending notifications, that's what inspired this solution) so I can keep the notification arrival as accurate as possible. Not so sure about the correctness of this practice, though.
Have you tested it every 15 minute connection? I created a schedule task to send the message. I use NotifyMyAndroid to push it. C2DM sometime pushes the message about 10 mninutes after not instantly. But, sometimes you get it in around a second.
The best way you can do this is by testing. I have a mechanism in my app that when I enable debugging I receive a HTTP request from the client saying that they received the message.
I find that this number is about 80%. Fortunately that's enough for the scope of my application.
Wifi shouldn't interfere in the C2DM ability of receive messages. At least while the phone is active.
What happens is that android turns the wifi OFF after the phone is in standby for a while. The messages won't be available at that period of time, simply because there's no internet connection available. Right after the user wakes the phone up, they should receive the messages.
After a long time research pretty much "all the internet" for an answer, I've found it. As I posted before, I was struggling with the problem myself and found out it was not a C2DM problem, or even a implementation problem. It was simply a router or firewall misconfiguration. Android uses a persistent TCP connection with a heartbeat keep-alive mecanism to ensures that the connection stays up. Google uses the state of the connection to determine if your device is idle or not. But if your router has a protection policy that checks for "unused" connections and terminates them, that won't work. Android notifications should be delivered (close to) instantly. I've tested this in my school network and home network, with two diferrent behaviour.
To resume: be sure to check your network configurations.
Some APNs work better than others with C2DM. Google "gtalk apn", for example, to find forums about the impact of the APN on C2DM.