[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" 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
>
>
>
> > 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" 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+T&f=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
>
> > > > 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+T&f=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 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
[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+T&f=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+T&f=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 scenari
[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+T&f=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+T&f=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
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+T&f=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
[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+T&f=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?
[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+T&f=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+T&f=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
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+T&f=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;
> > >
[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+T&f=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
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 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
[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
-~--~~~~--~~--~--~---
[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
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
>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
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
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
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
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
[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
[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
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 on your user
[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 >> > > > c
[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 re
[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
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, visi
[android-developers] Re: Flaky network connections
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
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
-~--~~~~--~~--~--~---
