There is quite a bit of varience in how long it takes for WiFI connectivity to be established. I would like some input on what is the best way to get connectivity established. In particular I am considering how to make multiple attempts to connect to a server where one does not know ahead of time how long it will take for wifi to get established. For example is it better to make three tries spaced apart by 10 seconds. or to make on long continuous try for 30 seconds? I am trying to make this connectivity as robust as possible. Getting connected to server over wifi in a reliable best effort manner is my goal, and I would welcome any suggestions on how to make this more reliable. One environment I have is Sprint 3G and Sprint 4G/ Wireless Sierra. Another is AT&T both 3G and 4G. Thanks AM I the only one who deals with this? Really?
Related
I am attempting to connect two Android devices close-range without a 3rd party service to transfer two small json payloads back and forth before closing the connection. Think adding nearby contacts.
I am using the P2P_POINT_TO_POINT Strategy and have both devices advertising and discovering using the code found here: https://developers.google.com/nearby/connections/android/get-started. It consistently works, however it repeatedly takes 10-15 seconds to find the connection and prompt to accept the connection.
Ideally I could get this below 10 seconds.
I read that having one dedicated to advertising another dedicated to discovering helps but it does not work for my use case.
Is there a way to improve the connection rate?
Unfortunately, the best you can do is to try to connect in one direction. That should lower the connection latency to 2~7 seconds. When both devices connect to each other at the same time, that causes thrashing and while we do our best to handle it gracefully, it will cause increased latency.
Stopping discovery before calling request connection would help too, but not by much. We already do it internally during the most sensitive operations.
Our advertising and discovery stack is based off of Bluetooth, and we've experimented with other technologies to compliment it. But they typically have harsher limitations than Bluetooth does (needs a router, needs a very recent Android phone, can't handle simultaneous connections, can't advertise and discover at the same time). Of all the technologies I know of, only mDNS would be faster while still allowing bi-directional connection attempts, and that requires both phones to be connected to the same router (and that the router hasn't disabled mDNS). Typically this means it only works at home. If that's a reasonable limitation for you, then I can pass that on to the team.
I have a simple async client application for android that connects to a server on my desktop. Now over wifi the application works fine(unless the client network is super slow). But when I try to use it over the mobile network it randomly disconnects with the classic "connection reset by peer" error. I think the highest chance of it happening is connecting and then leaving it for a few seconds to do nothing over the connection. But the thing is sometimes it "survives" and happens later on, and maybe one in a hundred times doesn't disconnect at all. It makes no sense and there are a lot of applications on the appstore that work fine across mobile network so it can't be that hard...
EDIT: This also happens if i just put my phone on a table, great signal, no movement, or anything that would distrubt the connection.
This is not because of mobile's movement. You should check your setting in mobile network and keep only one setting 3g or 4g. Don't put this on "Both" connections.
Hope this will help.
Can anyone point me to any sample code which explains (even slightly) how to write a simple wifi speedtest program for Android? I have looked everywhere!
Thanks in advance!
-Michael
It's not easy. Let me give you some suggestions but you will need to investigate more.
I'm not sure whether it is possible to access low level metrics of the WiFi connection or a 3G connection. Supposing it's not possible, my suggestions are oriented to use a ping or a ping-similar solution with some server and obtain the round-trip time (RTT).
Now, when you connect to a server, there are many factors affecting the RTT, these are the main ones:
WiFi speed, congestion, and communication errors
Latency in the whole path to the server, including ISP capacity and backbones.
Congestion in the path
Server speed to respond
Usually you execute a ping to test reachability and a taste of RTT. Ping is implemented with ICMP Echo Request. However, Java does not provide the means to send an ICMP message. So you might try to establish a TCP connection to some server.
You could use InetAddress::isReachable with a timeout various times until you find out the limit timeout. I wouldn't recommend this.
http://docs.oracle.com/javase/7/docs/api/java/net/InetAddress.html#isReachable(int)
I would create a TCP socket and call connect and then determine the time it took since connect was called. Of course you have to deal with all factors that affect speed.
Another point to consider is that if you use connect in a TCP socket, you have to understand that there is actually a three-way handshake: client sends a SYNC, server sends SYN/ACK, client sends ACK. But this last ACK doesn't add significant time to the return of connect because it's just sent by the client.
Having said that, I'll go with some suggestions:
First thing I would try, only with a WiFi, is trying to establish a connection to the access point, to port 80, 8080 or 443. That would eliminate other the last three factors.
If it doesn't work you could try a fix server, www.google.com for example. In this case you will have to deal with all the mentioned factors.
In the case of 3G, I don't know how you could could establish a connection to the access point like a Gateway GPRS Support Node in UMTS. But you can connect to a fix server, considering all 4 factors mentioned above.
Other point to consider si that when the smartphone has connectivity to WiFi and Cellular, it always uses WiFi. There are ways to force it to use 3g though, some links:
Android: Force data to be sent over radio vs WiFi
Force Android to use 3G when on local area wifi without net access
I hope this helps.
Like many apps my app depends on WIFI and Http Connection to operate. What I am not clear on is how I can time a wait until WIFI is enabled AND device is attached to WIFI network is. What is the best way to delay on application startup long enough for this to happen? during this time I would for example keep buttons deactivated. Also is there any way to make the device attempt to connect to its preferred network? Thanks
Take a look at ConnectivityManager and WiFiManager. Using these you can get events when network state changes
Use WifiManager to get the state of the connection.
Generally you will have to try. A Wifi connection can show as connected but not be able to actually send/receive because the signal is too weak. Once the connection is up, the app should try connecting and only when it succeeds, the buttons should be activated and so forth.
By default, Wifi sleep policy is "Sleep on screen idle".
With this policy, is it possible for a Background Service at a later time to wake up Wifi using some API?
Am trying the following, but does not work:
When my Background Service wakes up, it calls "ConnectivityManager.getActiveNetworkInfo()" to get active network.
Since, the wireless is off on idle, I tried waking it up using "WifiManager.startScan" on a previously used Wifi connection.
But still dont get Wifi connectivity.
Any ideas?
I preferably do not want to change my sleep policy to "Never".
Thanks
Hemant
There are no real simple solutions for this. To with a high probability ensure you have WIFI connectivity when the phone/screen goes to sleep the best way is to turn it off. Look here for a lot of details - http://wififixer.wordpress.com/
It is important to realize that in sleep mode the Wifi enters a low power mode. This will become tricky then to programmatically check as it might have connectivity to the Wifi but the Wifi connection is too weak or too slow to complete the HTTP request and hence it times out. This would force you to also check the speed of the Wifi connectivity as well as you will have an active network but a pretty lousy one.
Proper handling of the escaping when timeout occurs for the HTTP call you make makes it ok to use but ultimately the only way to have a background thread constantly running to get data is only doable when you have the Wifi mode to never sleep.
It is tricky and not the best way I know. :-( It is however the only path I have found which is reliable enough.