I am not sure you are experiencing the same thing I am. It's not a
transient "waiting for the radio to turn on" phenomenon.  I spent
several hours last night working with NetworkInfo.  When NetworkInfo
says I am connected, yep, I am connected.  But when I am not
connected, I can spin in a loop waiting for a connection as long as I
please, 30 seconds, a minute, more - still, not connected.  I even
tried to break down and reconnect wifi when it said I was not
connected - waiting a luxurious 30 seconds for the reconnect to
succeed - the result?  Still not connection.

I am really starting to think that there is something wrong with my
handset.  I certainly have no problem with transient disconnects and
such resulting from moving from cell to cell, or from 3G to wifi, or
edge to 3G - but I am sitting 3 feet from a very stable access point.



On Nov 24, 8:13 pm, JP <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to