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 -~----------~----~----~----~------~----~------~--~---