I am working on an app with similar requirements and behavior. 15
seconds polling cycle to XML server. (User can set it, so user decides
the level of load (;->))
I've had similar problems as you describe, and here's a couple of
strategies I've employed successfully (i.e. surviving multiple test
runs such as leaving WiFi coverage down office building elevator onto
street level walk down into subway ride subway and back out onto
street level with on-and-off 3G/Edge coverage, you get the idea...)
- Check network status. Obviously there are no UDP/TCP connects
possible when the device is not connected to a data network ("zero
bars"). Check this through the status info from the NetworkInfo class.
You need to request proper permission
(android.permission.ACCESS_NETWORK_STATE). If not connected, I cycle
through this twelve times on a one second interval. This is typically
sufficient to wait for the completion of data network connections
after the device wakes up. The device enters different levels of
sleep, depending on the period of inactivity; you can see this in the
DDMS log; things like DHCP release in Wifi mode, for example. So,
after the device resumes, I give it up to twelve attempts to check
data network connection status, take a break, and try again later, or
if user triggers these twelve attempts. Provide UI feedback showing
you're trying to connect.
- Having established data network connectivity, you cannot assume a
UDP/TCP (=URL) connect or read goes through. Either not at all, or
things are just plain too slow (high latency) in comparison to the
polling cycle. If the programmed URL timeouts extend beyond your
polling cycle, you run into problems,. Which you are, because the
standard timeouts are carry-overs from the dial-up Internets; you are
looking at default timeouts in the 30s neighborhood. This means you
need to set the connect and read timeouts of your network interactions
to values below your polling cycle, and wrap everything in try/catch
blocks. Again, provide user feedback if connections fail. The URL
connect and read timeouts are set with
java.net.URLConnection.setConnectTimeout(int) and .setReadTimeout
(int). I've been experimenting with 4s to 8s.
These strategies helped stabilize the action. I am under the
impression that the data network/TCP stack connectivity gets confused
if you try to connect at inopportune times (no data network
connectivity) or while a connect/read is timing out, and then throw
additional connection attempts at it.
Hope this helps.
On Nov 24, 5:17 am, joshv <[EMAIL PROTECTED]> wrote:
> I am attempting to write an application that regularly polls data from
> a publicly available website using a URLConnection. The code is
> pretty basic (urlStr contains the URL...)
>
> URL url = new URL(urlStr);
> URLConnection urlConn = url.openConnection();
> urlConn.setConnectTimeout(5000);
> BufferedReader in = new BufferedReader(new InputStreamReader
> (urlConn.getInputStream()));
> String line;
> while ((line = in.readLine())!=null) { ....
>
> Anyway, even when the G1 is connected to the network (verified in
> browser) this block of code will regularly throw
> java.net.SocketException: No route to host,
> java.net.SocketTimeoutException: Socket is not connected (though this
> is probably because I added a timeout), and many times throw an
> Exception claiming that it could not resolve the hostname in urlStr -
> oddly the web browser has no such issues resolving the name.
>
> The above block of code runs every 10 seconds (or longer if the
> previous request takes longer), and I'd guess succeeds approximately
> 25-50% of the time, though it tends to be a bit streaky. When the
> connection succeeds, it take less than a second to connect and
> download the data, it's a very small data set - so the timeout setting
> should not be an issue.
>
> The periods of error do not correspond to a loss of connectivity, as I
> can browser the web at the same time the errors are happening. This
> happens whether connected to local wi-fi or 3G.
>
> Am I doing something wrong, or is network connectivity on the G1 just
> this flaky?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
