I see, sure sounded like it though. In any case, to manage
communications helped out a great deal to eliminate the breakdowns
I've seen, similar to what you described. Once you've determined the
root cause of your problem I recommend to pull in a layer that handles
calls as I described.
Other than that, do exactly what Mark suggested - try to isolate the
problem. I've had similar thoughts re: the health of my particular
handset on another occasion (responses to touches) when in fact I had
to work out a couple of bugs. One was particularly odd, because it
rippled down to other apps once I had triggered it in mine, so one
would think it wasn't my problem. So... from distance... a handset
problem seems unlikely.
JP
On Nov 25, 4:25 am, joshv <[EMAIL PROTECTED]> wrote:
> 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 android-developers@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
