[android-developers] Re: Flaky network connections
Hi
I have the same problem.
I noticed that i have this problem when i'm debugging and that the
device is connected via USB .
when i disconnect the cable , i still have this behaviour until i stop
and start the wifi.
after restarting the wifi , connections are fine.
Chris
On 25 nov 2008, 16:49, Tom Gibara m...@tomgibara.com wrote:
Yes, it's on the UI thread.
I still think the balance of probabilities is a bug in your code. As far as
I know, permissions are assigned on a app-process basis. And what's the
likelihood of some unspecified change causing the problems, versus a race
condition in your code triggered by a difference in speed between the
emulator and the phone?
Produce a tidy test case and report an issue, then everyone can find out
it's a bug in the Android framework. Until then I think we have to assume
its your bug.
Tom.
2008/11/25 joshv jvanderb...@gmail.com
Tom, see upstream - it works fine for me now when I launch the polling
thread from the UI thread. I was launching it from the constructor of
another class, and for some reason this causes issues. It's quite
reproducible. If I launch the polling thread from the UI thread it
works. If I go back to launching it in the constructor it goes back
to being very unreliable.
I assume your example below is being called directly in the UI thread
as you are updating UI objects directly.
On Nov 25, 9:15 am, Tom Gibara m...@tomgibara.com wrote:
I just spent a minute knocking out a test case over a cup of tea. Seems
to
work fine for me on WIFI, GPRS, and 3G.
Tom.
void testConnection() {
TextView view = (TextView) findViewById(R.id.message);
HttpURLConnection conn = null;
try {
URL url = new URL(
http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2;);
conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod(GET);
conn.connect();
Reader reader = new InputStreamReader( conn.getInputStream() );
StringWriter writer = new StringWriter();
for (int c = reader.read(); c = 0; c = reader.read())
writer.write(c);
view.setText(writer.toString());
} catch (IOException e) {
Log.e(test, connection test failed, e);
} finally {
if (conn != null) conn.disconnect();
}
}
2008/11/25 joshv jvanderb...@gmail.com
I can disclose the URL, it's publicly available and always up - yahoo
finance csv stock price download. For example:
http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2
It doesn't get much more highly available than this. I could test
other URLs, but as I have mentionned before, the exact same code, with
the exact same URL runs marvelously in the emulator, so I very much
doubt it has anything to do with the URL. It's also not specific to
wi-fi on the handset. I get the same behavior when I disable wi-fi
and use only 3G.
It would take me a bit of work to create a reproducible snippet, no
proprietary concerns - just space. The code snippet I've already
posted is simply running in another thread spawned by the UI thread.
If I get some time I will try to work on a self-contained demo that
reproduces the problem on my handset.
On Nov 25, 7:02 am, Mark Murphy mmur...@commonsware.com wrote:
joshvwrote:
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.
Here's my recommendation on how to proceed:
First, create a separate really simple application that uses your
current techniques (URLConnection or HTTPComponents) to access a Web
site. Retrieve a Web page that is a no-brainer
always-gonna-work-for-everyone page, particularly one that is OK for
you
to disclose.
If this gives you the same symptoms as you're experiencing in your
main
application, post the manifest, layout, and activity source code, so
some of us can try it and see if we get problems on our devices.
If, however, this simplified example works just fine, start to slowly
convert it to look more like what's giving you problems (e.g., switch
to
the actual Web page you're trying to hit instead), and see where the
problems creep in.
At the point when you start getting problems again, if your test code
is
still safe for public release (e.g., no proprietary information),
post
the manifest, layout, and activity source code, so some of us can try
it
out and see if we get the same problems.
Going all the way back to your original post, the snippet of source
you
provided doesn't seem problematic (other than I'm a fan of
HTTPComponents over URLConnection), but, then
[android-developers] Re: Flaky network connections
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
[android-developers] Re: Flaky network connections
joshv wrote: 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. Here's my recommendation on how to proceed: First, create a separate really simple application that uses your current techniques (URLConnection or HTTPComponents) to access a Web site. Retrieve a Web page that is a no-brainer always-gonna-work-for-everyone page, particularly one that is OK for you to disclose. If this gives you the same symptoms as you're experiencing in your main application, post the manifest, layout, and activity source code, so some of us can try it and see if we get problems on our devices. If, however, this simplified example works just fine, start to slowly convert it to look more like what's giving you problems (e.g., switch to the actual Web page you're trying to hit instead), and see where the problems creep in. At the point when you start getting problems again, if your test code is still safe for public release (e.g., no proprietary information), post the manifest, layout, and activity source code, so some of us can try it out and see if we get the same problems. Going all the way back to your original post, the snippet of source you provided doesn't seem problematic (other than I'm a fan of HTTPComponents over URLConnection), but, then again, we aren't going to be able to reproduce your problem with just that snippet. In the end, if we collectively get a reproducible scenario that works, that sample code should serve us well on the issue tracker to make sure this gets looked at. -- Mark Murphy (a Commons Guy) http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009 http://www.bignerdranch.com/schedule.shtml --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
I can disclose the URL, it's publicly available and always up - yahoo finance csv stock price download. For example: http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2 It doesn't get much more highly available than this. I could test other URLs, but as I have mentionned before, the exact same code, with the exact same URL runs marvelously in the emulator, so I very much doubt it has anything to do with the URL. It's also not specific to wi-fi on the handset. I get the same behavior when I disable wi-fi and use only 3G. It would take me a bit of work to create a reproducible snippet, no proprietary concerns - just space. The code snippet I've already posted is simply running in another thread spawned by the UI thread. If I get some time I will try to work on a self-contained demo that reproduces the problem on my handset. On Nov 25, 7:02 am, Mark Murphy [EMAIL PROTECTED] wrote: joshvwrote: 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. Here's my recommendation on how to proceed: First, create a separate really simple application that uses your current techniques (URLConnection or HTTPComponents) to access a Web site. Retrieve a Web page that is a no-brainer always-gonna-work-for-everyone page, particularly one that is OK for you to disclose. If this gives you the same symptoms as you're experiencing in your main application, post the manifest, layout, and activity source code, so some of us can try it and see if we get problems on our devices. If, however, this simplified example works just fine, start to slowly convert it to look more like what's giving you problems (e.g., switch to the actual Web page you're trying to hit instead), and see where the problems creep in. At the point when you start getting problems again, if your test code is still safe for public release (e.g., no proprietary information), post the manifest, layout, and activity source code, so some of us can try it out and see if we get the same problems. Going all the way back to your original post, the snippet of source you provided doesn't seem problematic (other than I'm a fan of HTTPComponents over URLConnection), but, then again, we aren't going to be able to reproduce your problem with just that snippet. In the end, if we collectively get a reproducible scenario that works, that sample code should serve us well on the issue tracker to make sure this gets looked at. -- Mark Murphy (a Commons Guy)http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009http://www.bignerdranch.com/schedule.shtml --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
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
[android-developers] Re: Flaky network connections
Not putting words in Mark's mouth but he meant to explain that you need to eliminate uncertainties; one being the site you try to access and if it's bomb proof as you describe; done. Next - you've got to isolate the problem. No way around it even though recreating the problem in a sandbox will cost you a couple of hours. Wireless comms is a tricky environment; the spiel of the different states of the underlying stack and their impact on your app are more complex than what you will find in the emulator. For test purposes, you definitely should reduce the complexity of your multi-threaded environment. The correct approach for the architecture of your app (perhaps more complicated than need be?), but a candidate to cause trouble if you do not fully understand the dynamics of the underlying communications stack (emulator vs. the real thing). On Nov 25, 5:43 am, joshv [EMAIL PROTECTED] wrote: I can disclose the URL, it's publicly available and always up - yahoo finance csv stock price download. For example:http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2 It doesn't get much more highly available than this. I could test other URLs, but as I have mentionned before, the exact same code, with the exact same URL runs marvelously in the emulator, so I very much doubt it has anything to do with the URL. It's also not specific to wi-fi on the handset. I get the same behavior when I disable wi-fi and use only 3G. It would take me a bit of work to create a reproducible snippet, no proprietary concerns - just space. The code snippet I've already posted is simply running in another thread spawned by the UI thread. If I get some time I will try to work on a self-contained demo that reproduces the problem on my handset. On Nov 25, 7:02 am, Mark Murphy [EMAIL PROTECTED] wrote: joshvwrote: 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. Here's my recommendation on how to proceed: First, create a separate really simple application that uses your current techniques (URLConnection or HTTPComponents) to access a Web site. Retrieve a Web page that is a no-brainer always-gonna-work-for-everyone page, particularly one that is OK for you to disclose. If this gives you the same symptoms as you're experiencing in your main application, post the manifest, layout, and activity source code, so some of us can try it and see if we get problems on our devices. If, however, this simplified example works just fine, start to slowly convert it to look more like what's giving you problems (e.g., switch to the actual Web page you're trying to hit instead), and see where the problems creep in. At the point when you start getting problems again, if your test code is still safe for public release (e.g., no proprietary information), post the manifest, layout, and activity source code, so some of us can try it out and see if we get the same problems. Going all the way back to your original post, the snippet of source you provided doesn't seem problematic (other than I'm a fan of HTTPComponents over URLConnection), but, then again, we aren't going to be able to reproduce your problem with just that snippet. In the end, if we collectively get a reproducible scenario that works, that sample code should serve us well on the issue tracker to make sure this gets looked at. -- Mark Murphy (a Commons Guy)http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009http://www.bignerdranch.com/schedule.shtml --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
I just spent a minute knocking out a test case over a cup of tea. Seems to
work fine for me on WIFI, GPRS, and 3G.
Tom.
void testConnection() {
TextView view = (TextView) findViewById(R.id.message);
HttpURLConnection conn = null;
try {
URL url = new URL(
http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2;);
conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod(GET);
conn.connect();
Reader reader = new InputStreamReader( conn.getInputStream() );
StringWriter writer = new StringWriter();
for (int c = reader.read(); c = 0; c = reader.read())
writer.write(c);
view.setText(writer.toString());
} catch (IOException e) {
Log.e(test, connection test failed, e);
} finally {
if (conn != null) conn.disconnect();
}
}
2008/11/25 joshv [EMAIL PROTECTED]
I can disclose the URL, it's publicly available and always up - yahoo
finance csv stock price download. For example:
http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2
It doesn't get much more highly available than this. I could test
other URLs, but as I have mentionned before, the exact same code, with
the exact same URL runs marvelously in the emulator, so I very much
doubt it has anything to do with the URL. It's also not specific to
wi-fi on the handset. I get the same behavior when I disable wi-fi
and use only 3G.
It would take me a bit of work to create a reproducible snippet, no
proprietary concerns - just space. The code snippet I've already
posted is simply running in another thread spawned by the UI thread.
If I get some time I will try to work on a self-contained demo that
reproduces the problem on my handset.
On Nov 25, 7:02 am, Mark Murphy [EMAIL PROTECTED] wrote:
joshvwrote:
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.
Here's my recommendation on how to proceed:
First, create a separate really simple application that uses your
current techniques (URLConnection or HTTPComponents) to access a Web
site. Retrieve a Web page that is a no-brainer
always-gonna-work-for-everyone page, particularly one that is OK for you
to disclose.
If this gives you the same symptoms as you're experiencing in your main
application, post the manifest, layout, and activity source code, so
some of us can try it and see if we get problems on our devices.
If, however, this simplified example works just fine, start to slowly
convert it to look more like what's giving you problems (e.g., switch to
the actual Web page you're trying to hit instead), and see where the
problems creep in.
At the point when you start getting problems again, if your test code is
still safe for public release (e.g., no proprietary information), post
the manifest, layout, and activity source code, so some of us can try it
out and see if we get the same problems.
Going all the way back to your original post, the snippet of source you
provided doesn't seem problematic (other than I'm a fan of
HTTPComponents over URLConnection), but, then again, we aren't going to
be able to reproduce your problem with just that snippet.
In the end, if we collectively get a reproducible scenario that works,
that sample code should serve us well on the issue tracker to make sure
this gets looked at.
--
Mark Murphy (a Commons Guy)http://commonsware.com
Android Training on the Ranch! -- Mar 16-20, 2009
http://www.bignerdranch.com/schedule.shtml
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
I appear to have found the problem. The polling thread was starting in the constructor of a different class, and NOT from the UI thread. I changed the code to launch the polling thread from the main UI thread in the call to the Activity's onResume method - and it seems to be working quite well on the handset now. Why would this make a difference? No idea. I am assuming it's some subtlety of the security implementation with respect to threading. Perhaps the reason it worked on the emulator is that my handset and the emulator are at different release levels. On Nov 25, 8:12 am, JP [EMAIL PROTECTED] wrote: Not putting words in Mark's mouth but he meant to explain that you need to eliminate uncertainties; one being the site you try to access and if it's bomb proof as you describe; done. Next - you've got to isolate the problem. No way around it even though recreating the problem in a sandbox will cost you a couple of hours. Wireless comms is a tricky environment; the spiel of the different states of the underlying stack and their impact on your app are more complex than what you will find in the emulator. For test purposes, you definitely should reduce the complexity of your multi-threaded environment. The correct approach for the architecture of your app (perhaps more complicated than need be?), but a candidate to cause trouble if you do not fully understand the dynamics of the underlying communications stack (emulator vs. the real thing). On Nov 25, 5:43 am, joshv [EMAIL PROTECTED] wrote: I can disclose the URL, it's publicly available and always up - yahoo finance csv stock price download. For example:http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2 It doesn't get much more highly available than this. I could test other URLs, but as I have mentionned before, the exact same code, with the exact same URL runs marvelously in the emulator, so I very much doubt it has anything to do with the URL. It's also not specific to wi-fi on the handset. I get the same behavior when I disable wi-fi and use only 3G. It would take me a bit of work to create a reproducible snippet, no proprietary concerns - just space. The code snippet I've already posted is simply running in another thread spawned by the UI thread. If I get some time I will try to work on a self-contained demo that reproduces the problem on my handset. On Nov 25, 7:02 am, Mark Murphy [EMAIL PROTECTED] wrote: joshvwrote: 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. Here's my recommendation on how to proceed: First, create a separate really simple application that uses your current techniques (URLConnection or HTTPComponents) to access a Web site. Retrieve a Web page that is a no-brainer always-gonna-work-for-everyone page, particularly one that is OK for you to disclose. If this gives you the same symptoms as you're experiencing in your main application, post the manifest, layout, and activity source code, so some of us can try it and see if we get problems on our devices. If, however, this simplified example works just fine, start to slowly convert it to look more like what's giving you problems (e.g., switch to the actual Web page you're trying to hit instead), and see where the problems creep in. At the point when you start getting problems again, if your test code is still safe for public release (e.g., no proprietary information), post the manifest, layout, and activity source code, so some of us can try it out and see if we get the same problems. Going all the way back to your original post, the snippet of source you provided doesn't seem problematic (other than I'm a fan of HTTPComponents over URLConnection), but, then again, we aren't going to be able to reproduce your problem with just that snippet. In the end, if we collectively get a reproducible scenario that works, that sample code should serve us well on the issue tracker to make sure this gets looked at. -- Mark Murphy (a Commons Guy)http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009http://www.bignerdranch.com/schedule.shtml --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
No, its probably a bug in your code :) Tom. 2008/11/25 joshv [EMAIL PROTECTED] I appear to have found the problem. The polling thread was starting in the constructor of a different class, and NOT from the UI thread. I changed the code to launch the polling thread from the main UI thread in the call to the Activity's onResume method - and it seems to be working quite well on the handset now. Why would this make a difference? No idea. I am assuming it's some subtlety of the security implementation with respect to threading. Perhaps the reason it worked on the emulator is that my handset and the emulator are at different release levels. On Nov 25, 8:12 am, JP [EMAIL PROTECTED] wrote: Not putting words in Mark's mouth but he meant to explain that you need to eliminate uncertainties; one being the site you try to access and if it's bomb proof as you describe; done. Next - you've got to isolate the problem. No way around it even though recreating the problem in a sandbox will cost you a couple of hours. Wireless comms is a tricky environment; the spiel of the different states of the underlying stack and their impact on your app are more complex than what you will find in the emulator. For test purposes, you definitely should reduce the complexity of your multi-threaded environment. The correct approach for the architecture of your app (perhaps more complicated than need be?), but a candidate to cause trouble if you do not fully understand the dynamics of the underlying communications stack (emulator vs. the real thing). On Nov 25, 5:43 am, joshv [EMAIL PROTECTED] wrote: I can disclose the URL, it's publicly available and always up - yahoo finance csv stock price download. For example: http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2 It doesn't get much more highly available than this. I could test other URLs, but as I have mentionned before, the exact same code, with the exact same URL runs marvelously in the emulator, so I very much doubt it has anything to do with the URL. It's also not specific to wi-fi on the handset. I get the same behavior when I disable wi-fi and use only 3G. It would take me a bit of work to create a reproducible snippet, no proprietary concerns - just space. The code snippet I've already posted is simply running in another thread spawned by the UI thread. If I get some time I will try to work on a self-contained demo that reproduces the problem on my handset. On Nov 25, 7:02 am, Mark Murphy [EMAIL PROTECTED] wrote: joshvwrote: 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. Here's my recommendation on how to proceed: First, create a separate really simple application that uses your current techniques (URLConnection or HTTPComponents) to access a Web site. Retrieve a Web page that is a no-brainer always-gonna-work-for-everyone page, particularly one that is OK for you to disclose. If this gives you the same symptoms as you're experiencing in your main application, post the manifest, layout, and activity source code, so some of us can try it and see if we get problems on our devices. If, however, this simplified example works just fine, start to slowly convert it to look more like what's giving you problems (e.g., switch to the actual Web page you're trying to hit instead), and see where the problems creep in. At the point when you start getting problems again, if your test code is still safe for public release (e.g., no proprietary information), post the manifest, layout, and activity source code, so some of us can try it out and see if we get the same problems. Going all the way back to your original post, the snippet of source you provided doesn't seem problematic (other than I'm a fan of HTTPComponents over URLConnection), but, then again, we aren't going to be able to reproduce your problem with just that snippet. In the end, if we collectively get a reproducible scenario that works, that sample code should serve us well on the issue tracker to make sure this gets looked at. -- Mark Murphy (a Commons Guy)http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009 http://www.bignerdranch.com/schedule.shtml --~--~-~--~~~---~--~~ 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
[android-developers] Re: Flaky network connections
Tom, see upstream - it works fine for me now when I launch the polling
thread from the UI thread. I was launching it from the constructor of
another class, and for some reason this causes issues. It's quite
reproducible. If I launch the polling thread from the UI thread it
works. If I go back to launching it in the constructor it goes back
to being very unreliable.
I assume your example below is being called directly in the UI thread
as you are updating UI objects directly.
On Nov 25, 9:15 am, Tom Gibara [EMAIL PROTECTED] wrote:
I just spent a minute knocking out a test case over a cup of tea. Seems to
work fine for me on WIFI, GPRS, and 3G.
Tom.
void testConnection() {
TextView view = (TextView) findViewById(R.id.message);
HttpURLConnection conn = null;
try {
URL url = new
URL(http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2;);
conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod(GET);
conn.connect();
Reader reader = new InputStreamReader( conn.getInputStream() );
StringWriter writer = new StringWriter();
for (int c = reader.read(); c = 0; c = reader.read())
writer.write(c);
view.setText(writer.toString());
} catch (IOException e) {
Log.e(test, connection test failed, e);
} finally {
if (conn != null) conn.disconnect();
}
}
2008/11/25 joshv [EMAIL PROTECTED]
I can disclose the URL, it's publicly available and always up - yahoo
finance csv stock price download. For example:
http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2
It doesn't get much more highly available than this. I could test
other URLs, but as I have mentionned before, the exact same code, with
the exact same URL runs marvelously in the emulator, so I very much
doubt it has anything to do with the URL. It's also not specific to
wi-fi on the handset. I get the same behavior when I disable wi-fi
and use only 3G.
It would take me a bit of work to create a reproducible snippet, no
proprietary concerns - just space. The code snippet I've already
posted is simply running in another thread spawned by the UI thread.
If I get some time I will try to work on a self-contained demo that
reproduces the problem on my handset.
On Nov 25, 7:02 am, Mark Murphy [EMAIL PROTECTED] wrote:
joshvwrote:
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.
Here's my recommendation on how to proceed:
First, create a separate really simple application that uses your
current techniques (URLConnection or HTTPComponents) to access a Web
site. Retrieve a Web page that is a no-brainer
always-gonna-work-for-everyone page, particularly one that is OK for you
to disclose.
If this gives you the same symptoms as you're experiencing in your main
application, post the manifest, layout, and activity source code, so
some of us can try it and see if we get problems on our devices.
If, however, this simplified example works just fine, start to slowly
convert it to look more like what's giving you problems (e.g., switch to
the actual Web page you're trying to hit instead), and see where the
problems creep in.
At the point when you start getting problems again, if your test code is
still safe for public release (e.g., no proprietary information), post
the manifest, layout, and activity source code, so some of us can try it
out and see if we get the same problems.
Going all the way back to your original post, the snippet of source you
provided doesn't seem problematic (other than I'm a fan of
HTTPComponents over URLConnection), but, then again, we aren't going to
be able to reproduce your problem with just that snippet.
In the end, if we collectively get a reproducible scenario that works,
that sample code should serve us well on the issue tracker to make sure
this gets looked at.
--
Mark Murphy (a Commons Guy)http://commonsware.com
Android Training on the Ranch! -- Mar 16-20, 2009
http://www.bignerdranch.com/schedule.shtml
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
Yes, it's on the UI thread.
I still think the balance of probabilities is a bug in your code. As far as
I know, permissions are assigned on a app-process basis. And what's the
likelihood of some unspecified change causing the problems, versus a race
condition in your code triggered by a difference in speed between the
emulator and the phone?
Produce a tidy test case and report an issue, then everyone can find out
it's a bug in the Android framework. Until then I think we have to assume
its your bug.
Tom.
2008/11/25 joshv [EMAIL PROTECTED]
Tom, see upstream - it works fine for me now when I launch the polling
thread from the UI thread. I was launching it from the constructor of
another class, and for some reason this causes issues. It's quite
reproducible. If I launch the polling thread from the UI thread it
works. If I go back to launching it in the constructor it goes back
to being very unreliable.
I assume your example below is being called directly in the UI thread
as you are updating UI objects directly.
On Nov 25, 9:15 am, Tom Gibara [EMAIL PROTECTED] wrote:
I just spent a minute knocking out a test case over a cup of tea. Seems
to
work fine for me on WIFI, GPRS, and 3G.
Tom.
void testConnection() {
TextView view = (TextView) findViewById(R.id.message);
HttpURLConnection conn = null;
try {
URL url = new URL(
http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2;);
conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod(GET);
conn.connect();
Reader reader = new InputStreamReader( conn.getInputStream() );
StringWriter writer = new StringWriter();
for (int c = reader.read(); c = 0; c = reader.read())
writer.write(c);
view.setText(writer.toString());
} catch (IOException e) {
Log.e(test, connection test failed, e);
} finally {
if (conn != null) conn.disconnect();
}
}
2008/11/25 joshv [EMAIL PROTECTED]
I can disclose the URL, it's publicly available and always up - yahoo
finance csv stock price download. For example:
http://finance.yahoo.com/d/quotes.csv?s=GOOG+Tf=sl1c1p2
It doesn't get much more highly available than this. I could test
other URLs, but as I have mentionned before, the exact same code, with
the exact same URL runs marvelously in the emulator, so I very much
doubt it has anything to do with the URL. It's also not specific to
wi-fi on the handset. I get the same behavior when I disable wi-fi
and use only 3G.
It would take me a bit of work to create a reproducible snippet, no
proprietary concerns - just space. The code snippet I've already
posted is simply running in another thread spawned by the UI thread.
If I get some time I will try to work on a self-contained demo that
reproduces the problem on my handset.
On Nov 25, 7:02 am, Mark Murphy [EMAIL PROTECTED] wrote:
joshvwrote:
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.
Here's my recommendation on how to proceed:
First, create a separate really simple application that uses your
current techniques (URLConnection or HTTPComponents) to access a Web
site. Retrieve a Web page that is a no-brainer
always-gonna-work-for-everyone page, particularly one that is OK for
you
to disclose.
If this gives you the same symptoms as you're experiencing in your
main
application, post the manifest, layout, and activity source code, so
some of us can try it and see if we get problems on our devices.
If, however, this simplified example works just fine, start to slowly
convert it to look more like what's giving you problems (e.g., switch
to
the actual Web page you're trying to hit instead), and see where the
problems creep in.
At the point when you start getting problems again, if your test code
is
still safe for public release (e.g., no proprietary information),
post
the manifest, layout, and activity source code, so some of us can try
it
out and see if we get the same problems.
Going all the way back to your original post, the snippet of source
you
provided doesn't seem problematic (other than I'm a fan of
HTTPComponents over URLConnection), but, then again, we aren't going
to
be able to reproduce your problem with just that snippet.
In the end, if we collectively get a reproducible scenario that
works,
that sample code should serve us well on the issue tracker to make
sure
this gets looked at.
--
Mark Murphy (a Commons Guy)http://commonsware.com
Android Training on the Ranch! -- Mar 16-20, 2009
http://www.bignerdranch.com/schedule.shtml
[android-developers] Re: Flaky network connections
Even with a 10-second pause between the end of a response and the next
request, you're likely to keep the radio (either cell or wifi) turned
on all the time, since they tend to stay up for about that long even
when there's no activity before powering back down. That could limit
the phone's battery life to as little as 3 or 4 hours (with the screen
constantly off and the CPU idle most of the time).
The APIs that you're using are built on top of a foundation that was
designed for environments where the conditions that trigger exceptions
were indeed more exceptional than what you're seeing on a device
indeed. Such is the cost of making Android compatible with APIs that
developers are likely to be familiar with.
JBQ
On Mon, Nov 24, 2008 at 8:51 AM, joshv [EMAIL PROTECTED] wrote:
The polling happens only while the apps is loaded and displayed on
screen. The second the screen turns off or another app is loaded, the
polling stops. It's pretty well behaved in that respect. Also, I
don't hammer the connection 6 times a minute no matter what - each
thread waits for the previous to finish, waits ten seconds, and then
attempts to connect.
My issue is that URLConnections seem to be so unreliable that
Exceptions seem to be the rule, not the exception. This might be
something unique to my handset, I only have one, so I can't tell. It
certainly doesn't happen in the emulator. I might expect it to happen
if I have a marginal 3G or edge connection - but not when the handset
is literally 3 feet away from the WiFi access point it's using for a
connection.
On Nov 24, 10:00 am, Andrew Stadler [EMAIL PROTECTED] wrote:
If your code is going to access a site every 10 seconds, the radio is
going to, essentially, stay on continuously. This is going to have
a significant impact on your users' battery life. Is this definitely
what you want to do?
On Mon, Nov 24, 2008 at 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
-~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
As I pointed out in my previous post, the polling occurs only when the
application is active and on screen. It starts/stops in onResume/
onPause - so I am not sure how this is going to limit battery life
unless the user forces the application to remain active for hours at a
time.
Could you please explain to me why, with a solid wi-fi signal and
connection to a local access point, my URLConnections would ever throw
an exception unless there is a problem with the remote website? Are
the implementations of these APIs that brittle? Is the hardware
really that flaky?
Are there other APIs that bang on the hardware until it works, without
throwing exceptions? Am I doing something wrong? Or is this level of
unreliability, even over local wi-fi, to be expected?
On Nov 24, 10:58 am, Jean-Baptiste Queru [EMAIL PROTECTED] wrote:
Even with a 10-second pause between the end of a response and the next
request, you're likely to keep the radio (either cell or wifi) turned
on all the time, since they tend to stay up for about that long even
when there's no activity before powering back down. That could limit
the phone's battery life to as little as 3 or 4 hours (with the screen
constantly off and the CPU idle most of the time).
The APIs that you're using are built on top of a foundation that was
designed for environments where the conditions that trigger exceptions
were indeed more exceptional than what you're seeing on a device
indeed. Such is the cost of making Android compatible with APIs that
developers are likely to be familiar with.
JBQ
On Mon, Nov 24, 2008 at 8:51 AM, joshv [EMAIL PROTECTED] wrote:
The polling happens only while the apps is loaded and displayed on
screen. The second the screen turns off or another app is loaded, the
polling stops. It's pretty well behaved in that respect. Also, I
don't hammer the connection 6 times a minute no matter what - each
thread waits for the previous to finish, waits ten seconds, and then
attempts to connect.
My issue is that URLConnections seem to be so unreliable that
Exceptions seem to be the rule, not the exception. This might be
something unique to my handset, I only have one, so I can't tell. It
certainly doesn't happen in the emulator. I might expect it to happen
if I have a marginal 3G or edge connection - but not when the handset
is literally 3 feet away from the WiFi access point it's using for a
connection.
On Nov 24, 10:00 am, Andrew Stadler [EMAIL PROTECTED] wrote:
If your code is going to access a site every 10 seconds, the radio is
going to, essentially, stay on continuously. This is going to have
a significant impact on your users' battery life. Is this definitely
what you want to do?
On Mon, Nov 24, 2008 at 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
-~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
If your code is going to access a site every 10 seconds, the radio is
going to, essentially, stay on continuously. This is going to have
a significant impact on your users' battery life. Is this definitely
what you want to do?
On Mon, Nov 24, 2008 at 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
-~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
joshv wrote: Could you please explain to me why, with a solid wi-fi signal and connection to a local access point, my URLConnections would ever throw an exception unless there is a problem with the remote website? Are the implementations of these APIs that brittle? Is the hardware really that flaky? Try the Apache HTTPComponents, available in the SDK, documented (somewhat) with the SDK and also at the HTTPComponents Web site (http://hc.apache.org). Best-case scenario: your problem goes away. Worst-case scenario: you get better diagnostic information to give to us so we can help you past your problem. -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 1.4 Published! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
I don't know if this is related to what you're experiencing, but it's my
understanding that the wifi connections shuts down when the phone sleeps. I
believe this is because, unlike the radio, it requires the CPU to be active
to maintain the connection.
Also, contrary to your view, I think it's not intrinsically a hardware or
software problem. It's simply that in the context of mobile phone software,
the probability of a connection failure is greater than that you may be used
to, and due to the necessary limitations in powering the device, simple
solutions (like constantly striving to maintain a wifi connection) aren't an
option.
Perhaps a better perspective is to see the various data connections (wifi,
GPRS, EDGE, 3G etc.) as fallible primitives which you can combine to form a
more reliable transport suited to your application's needs.
Tom.
2008/11/24 joshv [EMAIL PROTECTED]
As I pointed out in my previous post, the polling occurs only when the
application is active and on screen. It starts/stops in onResume/
onPause - so I am not sure how this is going to limit battery life
unless the user forces the application to remain active for hours at a
time.
Could you please explain to me why, with a solid wi-fi signal and
connection to a local access point, my URLConnections would ever throw
an exception unless there is a problem with the remote website? Are
the implementations of these APIs that brittle? Is the hardware
really that flaky?
Are there other APIs that bang on the hardware until it works, without
throwing exceptions? Am I doing something wrong? Or is this level of
unreliability, even over local wi-fi, to be expected?
On Nov 24, 10:58 am, Jean-Baptiste Queru [EMAIL PROTECTED] wrote:
Even with a 10-second pause between the end of a response and the next
request, you're likely to keep the radio (either cell or wifi) turned
on all the time, since they tend to stay up for about that long even
when there's no activity before powering back down. That could limit
the phone's battery life to as little as 3 or 4 hours (with the screen
constantly off and the CPU idle most of the time).
The APIs that you're using are built on top of a foundation that was
designed for environments where the conditions that trigger exceptions
were indeed more exceptional than what you're seeing on a device
indeed. Such is the cost of making Android compatible with APIs that
developers are likely to be familiar with.
JBQ
On Mon, Nov 24, 2008 at 8:51 AM, joshv [EMAIL PROTECTED] wrote:
The polling happens only while the apps is loaded and displayed on
screen. The second the screen turns off or another app is loaded, the
polling stops. It's pretty well behaved in that respect. Also, I
don't hammer the connection 6 times a minute no matter what - each
thread waits for the previous to finish, waits ten seconds, and then
attempts to connect.
My issue is that URLConnections seem to be so unreliable that
Exceptions seem to be the rule, not the exception. This might be
something unique to my handset, I only have one, so I can't tell. It
certainly doesn't happen in the emulator. I might expect it to happen
if I have a marginal 3G or edge connection - but not when the handset
is literally 3 feet away from the WiFi access point it's using for a
connection.
On Nov 24, 10:00 am, Andrew Stadler [EMAIL PROTECTED] wrote:
If your code is going to access a site every 10 seconds, the radio is
going to, essentially, stay on continuously. This is going to have
a significant impact on your users' battery life. Is this definitely
what you want to do?
On Mon, Nov 24, 2008 at 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
[android-developers] Re: Flaky network connections
If you sniff the wire just past the wifi access point, how many requests/responses do you see during this time? On Mon, Nov 24, 2008 at 2:59 PM, joshv [EMAIL PROTECTED] wrote: My issues is that I am sitting 3 feet from a stable wi-fi access point and for minutes on end every single URLConnection attempt will fail. I could certainly understand if maybe the first attempt failed, or took longer, because I was waiting for the radio to turn on, but 100% failure for minutes on end is just weird. There is no good reason for it. It should be considered a bug. And even when it does work, it's still not 100%, the failure rate is still very high. This makes for a really crappy application experience, as I simply cannot predict when my user will see their data update. I feel like there are reliable ways of communicating, as even when my application is experiencing errors, I get emails and IMs on the phone, and I can browse the internet - so somehow the google apps are able to communicate. That's why I am asking if I am doing something wrong or if there is some other API I should try. I can try out the Apache HTTPComponents, but I am assuming they just wrap the lower level java network APIs. I am not sure what benefit I would get. On Nov 24, 1:44 pm, Tom Gibara [EMAIL PROTECTED] wrote: I don't know if this is related to what you're experiencing, but it's my understanding that the wifi connections shuts down when the phone sleeps. I believe this is because, unlike the radio, it requires the CPU to be active to maintain the connection. Also, contrary to your view, I think it's not intrinsically a hardware or software problem. It's simply that in the context of mobile phone software, the probability of a connection failure is greater than that you may be used to, and due to the necessary limitations in powering the device, simple solutions (like constantly striving to maintain a wifi connection) aren't an option. Perhaps a better perspective is to see the various data connections (wifi, GPRS, EDGE, 3G etc.) as fallible primitives which you can combine to form a more reliable transport suited to your application's needs. Tom. 2008/11/24 joshv [EMAIL PROTECTED] As I pointed out in my previous post, the polling occurs only when the application is active and on screen. It starts/stops in onResume/ onPause - so I am not sure how this is going to limit battery life unless the user forces the application to remain active for hours at a time. Could you please explain to me why, with a solid wi-fi signal and connection to a local access point, my URLConnections would ever throw an exception unless there is a problem with the remote website? Are the implementations of these APIs that brittle? Is the hardware really that flaky? Are there other APIs that bang on the hardware until it works, without throwing exceptions? Am I doing something wrong? Or is this level of unreliability, even over local wi-fi, to be expected? On Nov 24, 10:58 am, Jean-Baptiste Queru [EMAIL PROTECTED] wrote: Even with a 10-second pause between the end of a response and the next request, you're likely to keep the radio (either cell or wifi) turned on all the time, since they tend to stay up for about that long even when there's no activity before powering back down. That could limit the phone's battery life to as little as 3 or 4 hours (with the screen constantly off and the CPU idle most of the time). The APIs that you're using are built on top of a foundation that was designed for environments where the conditions that trigger exceptions were indeed more exceptional than what you're seeing on a device indeed. Such is the cost of making Android compatible with APIs that developers are likely to be familiar with. JBQ On Mon, Nov 24, 2008 at 8:51 AM, joshv [EMAIL PROTECTED] wrote: The polling happens only while the apps is loaded and displayed on screen. The second the screen turns off or another app is loaded, the polling stops. It's pretty well behaved in that respect. Also, I don't hammer the connection 6 times a minute no matter what - each thread waits for the previous to finish, waits ten seconds, and then attempts to connect. My issue is that URLConnections seem to be so unreliable that Exceptions seem to be the rule, not the exception. This might be something unique to my handset, I only have one, so I can't tell. It certainly doesn't happen in the emulator. I might expect it to happen if I have a marginal 3G or edge connection - but not when the handset is literally 3 feet away from the WiFi access point it's using for a connection. On Nov 24, 10:00 am, Andrew Stadler [EMAIL PROTECTED] wrote: If your code is going to access a site every 10 seconds, the radio is going to, essentially, stay on continuously. This is going to have a significant impact
[android-developers] Re: Flaky network connections
joshv wrote: That's why I am asking if I am doing something wrong or if there is some other API I should try. I can try out the Apache HTTPComponents, but I am assuming they just wrap the lower level java network APIs. I am not sure what benefit I would get. You want to find out if there is some other API [you] should try, but then you don't want to try it because you are not sure what benefit [you] would get? I can tell you that URLConnection gave me tons of grief on Java SE and I abandoned it ages ago in favor HTTPComponents (originally called HTTPClient). I can tell you that I have not experienced any of the problems you describe when using HTTPComponents on Android, though I have mostly been using WiFi due to weak T-Mo signal strength and no 3G in my work area. -- Mark Murphy (a Commons Guy) http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009 http://www.bignerdranch.com/schedule.shtml --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
I don't have any sniffing capabilities. The no route to host error would suggest that the attempt never leaves the phone, as the other devices on my network have no issues accessing the internet at the same time. This is by the way replicable on my access point at work, as well as at home, so it's not something in my access point - unless perhaps it's an issue with WPA. But I also see the same behavior when I have a strong 3G connection as well. On 3G I might expect a little bit of flakiness, though again, not 100% failure for minutes on end. On Nov 24, 2:01 pm, Dorn Hetzel [EMAIL PROTECTED] wrote: If you sniff the wire just past the wifi access point, how many requests/responses do you see during this time? On Mon, Nov 24, 2008 at 2:59 PM, joshv [EMAIL PROTECTED] wrote: My issues is that I am sitting 3 feet from a stable wi-fi access point and for minutes on end every single URLConnection attempt will fail. I could certainly understand if maybe the first attempt failed, or took longer, because I was waiting for the radio to turn on, but 100% failure for minutes on end is just weird. There is no good reason for it. It should be considered a bug. And even when it does work, it's still not 100%, the failure rate is still very high. This makes for a really crappy application experience, as I simply cannot predict when my user will see their data update. I feel like there are reliable ways of communicating, as even when my application is experiencing errors, I get emails and IMs on the phone, and I can browse the internet - so somehow the google apps are able to communicate. That's why I am asking if I am doing something wrong or if there is some other API I should try. I can try out the Apache HTTPComponents, but I am assuming they just wrap the lower level java network APIs. I am not sure what benefit I would get. On Nov 24, 1:44 pm, Tom Gibara [EMAIL PROTECTED] wrote: I don't know if this is related to what you're experiencing, but it's my understanding that the wifi connections shuts down when the phone sleeps. I believe this is because, unlike the radio, it requires the CPU to be active to maintain the connection. Also, contrary to your view, I think it's not intrinsically a hardware or software problem. It's simply that in the context of mobile phone software, the probability of a connection failure is greater than that you may be used to, and due to the necessary limitations in powering the device, simple solutions (like constantly striving to maintain a wifi connection) aren't an option. Perhaps a better perspective is to see the various data connections (wifi, GPRS, EDGE, 3G etc.) as fallible primitives which you can combine to form a more reliable transport suited to your application's needs. Tom. 2008/11/24 joshv [EMAIL PROTECTED] As I pointed out in my previous post, the polling occurs only when the application is active and on screen. It starts/stops in onResume/ onPause - so I am not sure how this is going to limit battery life unless the user forces the application to remain active for hours at a time. Could you please explain to me why, with a solid wi-fi signal and connection to a local access point, my URLConnections would ever throw an exception unless there is a problem with the remote website? Are the implementations of these APIs that brittle? Is the hardware really that flaky? Are there other APIs that bang on the hardware until it works, without throwing exceptions? Am I doing something wrong? Or is this level of unreliability, even over local wi-fi, to be expected? On Nov 24, 10:58 am, Jean-Baptiste Queru [EMAIL PROTECTED] wrote: Even with a 10-second pause between the end of a response and the next request, you're likely to keep the radio (either cell or wifi) turned on all the time, since they tend to stay up for about that long even when there's no activity before powering back down. That could limit the phone's battery life to as little as 3 or 4 hours (with the screen constantly off and the CPU idle most of the time). The APIs that you're using are built on top of a foundation that was designed for environments where the conditions that trigger exceptions were indeed more exceptional than what you're seeing on a device indeed. Such is the cost of making Android compatible with APIs that developers are likely to be familiar with. JBQ On Mon, Nov 24, 2008 at 8:51 AM, joshv [EMAIL PROTECTED] wrote: The polling happens only while the apps is loaded and displayed on screen. The second the screen turns off or another app is loaded, the polling stops. It's pretty well behaved in that respect. Also, I don't hammer the connection 6 times a minute no matter what - each thread waits for the previous to finish, waits ten seconds, and then attempts to
[android-developers] Re: Flaky network connections
There are obviously many possible causes of the network problems you're experiencing (including bugs in the framework or even faulty hardware). All I can say is that I have not experienced problems like that, nor I believe, have the users of my applications. Tom. 2008/11/24 joshv [EMAIL PROTECTED] I don't have any sniffing capabilities. The no route to host error would suggest that the attempt never leaves the phone, as the other devices on my network have no issues accessing the internet at the same time. This is by the way replicable on my access point at work, as well as at home, so it's not something in my access point - unless perhaps it's an issue with WPA. But I also see the same behavior when I have a strong 3G connection as well. On 3G I might expect a little bit of flakiness, though again, not 100% failure for minutes on end. On Nov 24, 2:01 pm, Dorn Hetzel [EMAIL PROTECTED] wrote: If you sniff the wire just past the wifi access point, how many requests/responses do you see during this time? On Mon, Nov 24, 2008 at 2:59 PM, joshv [EMAIL PROTECTED] wrote: My issues is that I am sitting 3 feet from a stable wi-fi access point and for minutes on end every single URLConnection attempt will fail. I could certainly understand if maybe the first attempt failed, or took longer, because I was waiting for the radio to turn on, but 100% failure for minutes on end is just weird. There is no good reason for it. It should be considered a bug. And even when it does work, it's still not 100%, the failure rate is still very high. This makes for a really crappy application experience, as I simply cannot predict when my user will see their data update. I feel like there are reliable ways of communicating, as even when my application is experiencing errors, I get emails and IMs on the phone, and I can browse the internet - so somehow the google apps are able to communicate. That's why I am asking if I am doing something wrong or if there is some other API I should try. I can try out the Apache HTTPComponents, but I am assuming they just wrap the lower level java network APIs. I am not sure what benefit I would get. On Nov 24, 1:44 pm, Tom Gibara [EMAIL PROTECTED] wrote: I don't know if this is related to what you're experiencing, but it's my understanding that the wifi connections shuts down when the phone sleeps. I believe this is because, unlike the radio, it requires the CPU to be active to maintain the connection. Also, contrary to your view, I think it's not intrinsically a hardware or software problem. It's simply that in the context of mobile phone software, the probability of a connection failure is greater than that you may be used to, and due to the necessary limitations in powering the device, simple solutions (like constantly striving to maintain a wifi connection) aren't an option. Perhaps a better perspective is to see the various data connections (wifi, GPRS, EDGE, 3G etc.) as fallible primitives which you can combine to form a more reliable transport suited to your application's needs. Tom. 2008/11/24 joshv [EMAIL PROTECTED] As I pointed out in my previous post, the polling occurs only when the application is active and on screen. It starts/stops in onResume/ onPause - so I am not sure how this is going to limit battery life unless the user forces the application to remain active for hours at a time. Could you please explain to me why, with a solid wi-fi signal and connection to a local access point, my URLConnections would ever throw an exception unless there is a problem with the remote website? Are the implementations of these APIs that brittle? Is the hardware really that flaky? Are there other APIs that bang on the hardware until it works, without throwing exceptions? Am I doing something wrong? Or is this level of unreliability, even over local wi-fi, to be expected? On Nov 24, 10:58 am, Jean-Baptiste Queru [EMAIL PROTECTED] wrote: Even with a 10-second pause between the end of a response and the next request, you're likely to keep the radio (either cell or wifi) turned on all the time, since they tend to stay up for about that long even when there's no activity before powering back down. That could limit the phone's battery life to as little as 3 or 4 hours (with the screen constantly off and the CPU idle most of the time). The APIs that you're using are built on top of a foundation that was designed for environments where the conditions that trigger exceptions were indeed more exceptional than what you're seeing on a device indeed. Such is the cost of making Android compatible with APIs that developers are likely to be familiar with. JBQ On Mon, Nov 24, 2008 at 8:51 AM, joshv [EMAIL PROTECTED]
[android-developers] Re: Flaky network connections
I am assuming that HTTPComponents just wraps the underlying java networking APIs - but perhaps I am wrong and they wrote an HTTP client all the way down to the socket level. Regardless, it can't hurt to try. In generally I have absolutely no problems using URLConnection. The code I've written works marvelously in the emulator, and I have other non-Android projects that use URLConnection, so I am not exactly sure what's wrong. On Nov 24, 2:10 pm, Mark Murphy [EMAIL PROTECTED] wrote: joshv wrote: That's why I am asking if I am doing something wrong or if there is some other API I should try. I can try out the Apache HTTPComponents, but I am assuming they just wrap the lower level java network APIs. I am not sure what benefit I would get. You want to find out if there is some other API [you] should try, but then you don't want to try it because you are not sure what benefit [you] would get? I can tell you that URLConnection gave me tons of grief on Java SE and I abandoned it ages ago in favor HTTPComponents (originally called HTTPClient). I can tell you that I have not experienced any of the problems you describe when using HTTPComponents on Android, though I have mostly been using WiFi due to weak T-Mo signal strength and no 3G in my work area. -- Mark Murphy (a Commons Guy)http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009http://www.bignerdranch.com/schedule.shtml --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
joshv wrote: I am assuming that HTTPComponents just wraps the underlying java networking APIs - but perhaps I am wrong and they wrote an HTTP client all the way down to the socket level. Regardless, it can't hurt to try. I suspect it's written to Java sockets. The code I've written works marvelously in the emulator Now *that's* odd. Is there anything unusual about the URL you are trying to connect to: SSL? Oddball port? IP address instead of domain name? The server you're trying to hit is on the same PC as the emulator you were running? -- Mark Murphy (a Commons Guy) http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009 http://www.bignerdranch.com/schedule.shtml --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
It's identical code - identical URL, no SSL, using a domain name. In the emulator I very rarely get a socket timeout - but that's because I've set a pretty aggressive 5 second timeout - which periodically the target website (or our intervening network path) fails to meet - this is to be expected, but other than that it never errors out in the emulator. If it worked this well on the actually phone I'd be perfectly happy. -josh On Nov 24, 2:53 pm, Mark Murphy [EMAIL PROTECTED] wrote: joshv wrote: I am assuming that HTTPComponents just wraps the underlying java networking APIs - but perhaps I am wrong and they wrote an HTTP client all the way down to the socket level. Regardless, it can't hurt to try. I suspect it's written to Java sockets. The code I've written works marvelously in the emulator Now *that's* odd. Is there anything unusual about the URL you are trying to connect to: SSL? Oddball port? IP address instead of domain name? The server you're trying to hit is on the same PC as the emulator you were running? -- Mark Murphy (a Commons Guy)http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009http://www.bignerdranch.com/schedule.shtml --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
From the phone, connections will almost certainly be proxied by T-mobile. Perhaps it's the interaction between your server and the proxies that is at the root of your problem? Tom. 2008/11/24 joshv [EMAIL PROTECTED] It's identical code - identical URL, no SSL, using a domain name. In the emulator I very rarely get a socket timeout - but that's because I've set a pretty aggressive 5 second timeout - which periodically the target website (or our intervening network path) fails to meet - this is to be expected, but other than that it never errors out in the emulator. If it worked this well on the actually phone I'd be perfectly happy. -josh On Nov 24, 2:53 pm, Mark Murphy [EMAIL PROTECTED] wrote: joshv wrote: I am assuming that HTTPComponents just wraps the underlying java networking APIs - but perhaps I am wrong and they wrote an HTTP client all the way down to the socket level. Regardless, it can't hurt to try. I suspect it's written to Java sockets. The code I've written works marvelously in the emulator Now *that's* odd. Is there anything unusual about the URL you are trying to connect to: SSL? Oddball port? IP address instead of domain name? The server you're trying to hit is on the same PC as the emulator you were running? -- Mark Murphy (a Commons Guy)http://commonsware.com Android Training on the Ranch! -- Mar 16-20, 2009 http://www.bignerdranch.com/schedule.shtml --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
Proxied via t-mobile even when I am using my own wi-fi network? On Nov 24, 3:29 pm, Tom Gibara [EMAIL PROTECTED] wrote: From the phone, connections will almost certainly be proxied by T-mobile. Perhaps it's the interaction between your server and the proxies that is at the root of your problem? Tom. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
Errr, no. I should have thought a bit more before I posted that. I was reasoning that if the problem occurs via radio, and wifi (in two separate locations) then the server seems a possible cause. There are only three common elements across each case: the phone, your app and the server. Since you say that you have written other applications that have performed network operations on the phone without problems, that leaves the server as most suspect element (based on the information to hand - as I see it). Saying it might be related to proxying was clearly irrelevant. Tom. 2008/11/24 joshv [EMAIL PROTECTED] Proxied via t-mobile even when I am using my own wi-fi network? On Nov 24, 3:29 pm, Tom Gibara [EMAIL PROTECTED] wrote: From the phone, connections will almost certainly be proxied by T-mobile. Perhaps it's the interaction between your server and the proxies that is at the root of your problem? Tom. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Flaky network connections
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
-~--~~~~--~~--~--~---
