I have an Android app which, as part of its core functionality, makes ASP.NET WebService calls. I have authored the app successfully using ksoap2 to make the calls and it does what I need it to.
Our client reports that they have found some phones where the app does not work. Namely, during some of the WebService calls it appears to time out. This befuddled me because it works perfectly on the handful of phones we've tested it with here in my office.
One of the phones the client reported having an issue with was the Samsung Galaxy S2 on Sprint (the other phone they reported was either a Samsung Galaxy S or a Samsung Galaxy S3 - real similar phone, in other words). As luck would have it I was able to hunt down an employee in the company who had a Samsung Galaxy S2 on Sprint and was willing to let me borrow it. And I was able to re-create the issue. Attached to Eclipse it appears to be getting a SocketTimeoutException. Not every time, but more often than not.
As part of my testing, I connected the phone to a MiFi on Verizon. So, essentially I was taking it off of Sprint's network and putting it on Verizon's. When I did this, the app worked as expected, no timeouts.
At first I thought maybe Sprint's network was just bad but that seemed unlikely seeing as how my client is on the other side of the country from me so unless their network is consistently bad I doubt that's the case.
But what I noticed is - in the status bar of the phone, when connected to Sprint, I saw 3G and 4G icons, and they appeared to be switching back and forth (the way they're laid out, they both appear, just turned off/on right next to each other). When I was connected to the MiFi, as far as the phone knows or cares I'm connected to a Wi-Fi point.
So what I wonder is - could it be that the phone is "switching" back and forth between the 3G and 4G networks and the response to the webservice call is getting lost? On the iPhone if you make a request for a webpage in Safari with your phone on the 3G network (for example) and the phone then finds a Wi-Fi point to connect to and switches over, you still get the webpage on your device even after it connects to Wi-Fi. I presume that the OS is allowing the 3G calls to finish out before switching that network off.
Could something that Samsung has done with the OS for the Galaxy S* line be causing my responses to be getting lost? And if so, is there something I can do about it to prevent this from happening? Is there a way to figure out what network connections are still alive?
UPDATE: See my answer below, this question's premise turned out not to be the reason, although it does occur to me that I forgot to point out that the particular calls that fail or timeout contain base64-encoded images and so they're larger than normal webservice calls.
For what it's worth, the answer appears to be "no"
I used the code from this blog entry which allows me to monitor when a network connection change occurs and I was able to verify that the behavior occurs even when the network connection doesn't change.
So it does appear that for whatever reason this particular combination (Sprint/Samsung Galaxy S or S2) doesn't like what I'm doing.
One thing I forgot to mention is that I'm sending a Base64-encoded image across the web service call so the size may have some relation to it but I can't figure out what the issue is exactly.
I am facing a rather weird problem with my android app. It is a very basic app which connects to a server and posts requests.
When the phone is switched on initially, and the app is started with only a 3G connection - the server connection times-out each and every time. The moment i connect to a wifi network it works. And to top it off - if i switch back to 3G after this , it works fine. I am very confused as to what is going on.
Do I need to turn on some parameter in order for the app to work without wifi and only 3G in the first try? Any insight would be appreciated :)
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?
This strange thing just happens: whenever a startDiscovery() is called, the application is (as you would expect) still responding during the next initial 10-12 seconds. But whenever a Http Request is fired during this period it is stalled (no data could be requested or downloaded on a http connection).
I use the DefaultHttpClient.execute() method to request data from over the wifi network.
I not only see this happening in my own application. I also see this when the application is doing bluetooth discovery in the background and I want to download something off the Google Market place.
Had someone experienced something similar?
UPDATE 18-aug-'11:
When listening to a stream on the internet: I noticed the stream was dropping out on me whenever discovery was activated. I looked at the active network traffic and indeed I could confirm the two drops. The things that wonders me, as this was the network traffic from my computer and not my android device. Soo it seems the android devices somehow conflicts with the active wifi network?
Anybody familiar with this?
Backround: Android 2.x on a tablet
That a the second post on this. Now the WiFi don't get turned off by android but I although loose the connectivity after some, means the server can no longer reach the android device (I get a timeout). I tried this at least on four different tablets so I don't think that it depends on the hardware. A continous polling prevent this but this should be just a workaround.
The answer lays in the wifi router AP (access point). There is a value thats called TTL (time to live) which controls how long a connection is held open after last activity before closing from no activity. You need to change this value in the router.