I don't have any sniffing capabilities. The "no route to host" error
would suggest that the attempt never leaves the phone, as the other
devices on my network have no issues accessing the internet at the
same time. This is by the way replicable on my access point at work,
as well as at home, so it's not something in my access point - unless
perhaps it's an issue with WPA. But I also see the same behavior when
I have a strong 3G connection as well. On 3G I might expect a little
bit of flakiness, though again, not 100% failure for minutes on end.
On Nov 24, 2:01 pm, "Dorn Hetzel" <[EMAIL PROTECTED]> wrote:
> If you sniff the wire just past the wifi access point, how many
> requests/responses do you see during this time?
>
> On Mon, Nov 24, 2008 at 2:59 PM, joshv <[EMAIL PROTECTED]> wrote:
>
> > My issues is that I am sitting 3 feet from a stable wi-fi access point
> > and for minutes on end every single URLConnection attempt will fail.
> > I could certainly understand if maybe the first attempt failed, or
> > took longer, because I was waiting for the radio to turn on, but 100%
> > failure for minutes on end is just weird. There is no good reason for
> > it. It should be considered a bug. And even when it does work, it's
> > still not 100%, the failure rate is still very high.
>
> > This makes for a really crappy application experience, as I simply
> > cannot predict when my user will see their data update. I feel like
> > there are reliable ways of communicating, as even when my application
> > is experiencing errors, I get emails and IMs on the phone, and I can
> > browse the internet - so somehow the google apps are able to
> > communicate. That's why I am asking if I am doing something wrong or
> > if there is some other API I should try. I can try out the Apache
> > HTTPComponents, but I am assuming they just wrap the lower level java
> > network APIs. I am not sure what benefit I would get.
>
> > On Nov 24, 1:44 pm, "Tom Gibara" <[EMAIL PROTECTED]> wrote:
> >> I don't know if this is related to what you're experiencing, but it's my
> >> understanding that the wifi connections shuts down when the phone sleeps. I
> >> believe this is because, unlike the radio, it requires the CPU to be active
> >> to maintain the connection.
> >> Also, contrary to your view, I think it's not intrinsically a hardware or
> >> software problem. It's simply that in the context of mobile phone software,
> >> the probability of a connection failure is greater than that you may be
> >> used
> >> to, and due to the necessary limitations in powering the device, simple
> >> solutions (like constantly striving to maintain a wifi connection) aren't
> >> an
> >> option.
>
> >> Perhaps a better perspective is to see the various data connections (wifi,
> >> GPRS, EDGE, 3G etc.) as fallible primitives which you can combine to form a
> >> more reliable transport suited to your application's needs.
>
> >> Tom.
>
> >> 2008/11/24 joshv <[EMAIL PROTECTED]>
>
> >> > As I pointed out in my previous post, the polling occurs only when the
> >> > application is active and on screen. It starts/stops in onResume/
> >> > onPause - so I am not sure how this is going to limit battery life
> >> > unless the user forces the application to remain active for hours at a
> >> > time.
>
> >> > Could you please explain to me why, with a solid wi-fi signal and
> >> > connection to a local access point, my URLConnections would ever throw
> >> > an exception unless there is a problem with the remote website? Are
> >> > the implementations of these APIs that brittle? Is the hardware
> >> > really that flaky?
>
> >> > Are there other APIs that bang on the hardware until it works, without
> >> > throwing exceptions? Am I doing something wrong? Or is this level of
> >> > unreliability, even over local wi-fi, to be expected?
>
> >> > On Nov 24, 10:58 am, Jean-Baptiste Queru <[EMAIL PROTECTED]> wrote:
> >> > > Even with a 10-second pause between the end of a response and the next
> >> > > request, you're likely to keep the radio (either cell or wifi) turned
> >> > > on all the time, since they tend to stay up for about that long even
> >> > > when there's no activity before powering back down. That could limit
> >> > > the phone's battery life to as little as 3 or 4 hours (with the screen
> >> > > constantly off and the CPU idle most of the time).
>
> >> > > The APIs that you're using are built on top of a foundation that was
> >> > > designed for environments where the conditions that trigger exceptions
> >> > > were indeed more exceptional than what you're seeing on a device
> >> > > indeed. Such is the cost of making Android compatible with APIs that
> >> > > developers are likely to be familiar with.
>
> >> > > JBQ
>
> >> > > On Mon, Nov 24, 2008 at 8:51 AM, joshv <[EMAIL PROTECTED]> wrote:
>
> >> > > > The polling happens only while the apps is loaded and displayed on
> >> > > > screen. The second the screen turns off or another app is loaded,
> >> > > > the
> >> > > > polling stops. It's pretty well behaved in that respect. Also, I
> >> > > > don't hammer the connection 6 times a minute no matter what - each
> >> > > > thread waits for the previous to finish, waits ten seconds, and then
> >> > > > attempts to 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
-~----------~----~----~----~------~----~------~--~---
