• State Not Answered
  • Replies 6 replies
  • Subscribers 17 subscribers
  • Views 1295 views
  • Users 0 members are here
Options
Related

Why am I not getting a webrequest timeout?

7555607

I'm going to ask a few related questions here.

First, how long does it take for a webrequest to timeout?

Second, does anyone else have webrequests where the callback isn't called?  When I have a connection issue, my callback sometimes fires with a timeout error, but it seems that more often than not, the callback just isn't ever called.

I've tested this with a couple of different Android phones, each connected to my Vivoactive 3 music.  It happens whether I make the webrequest in the foreground or in the background.  When it happens in the foreground, it doesn't bother me so much because my users can easily see that there is an issue and respond accordingly.  However, when I run webrequests in the background, I would like to request to launch my app if there's an error.  As it is, I cannot make the wake request when my webrequest is never complete.

Finally, if this is a common issue that isn't likely to be fixed soon, does anyone know of a reliable way to detect webrequest errors in the background (since it's in the background, I can't just set my own timeout).  I can use Background.exit() to check for errors when the app launches, but I'd rather deal with errors as soon as they occur if possible.

Thanks!

  • 0

    There are a bunch of things going on here.

    The first thing is that when you test in the sim, things are generally much faster than on a real device.  There's no phone involved, and your pc/mac likely has very fast internet access, and isn't impacted by cell phone data speeds.

    Then, you want to consider why you get timeout errors at all.  While the data speeds may be involved, so is the speed of server, and if the server is bogged down in general things can take time.  The size of the response data could also have an impact.  Request the smallest amount of data your app needs, and maybe consider using a proxy to reduce the data down to only what you need if there's a lot of data.

    As far as the the callback not being called, there can be other timeouts involved.  When you run a widget, they can timeout and return to the watch face.  On a vivoactive this timeout is short, while on things like forerunners, it's about 2 minutes.  This timeout can be reset by interacting with the widget.  Just tapping the screen on touch devices will do it.  The very first widget I did that requested external data needed the GPS location, so I'd start GPS and get the location before making the request.  That didn't work too well as GPS often takes more than a few seconds to get the location, and I had to keep tapping the screen to prevent the timeout.

    In a background service things can run 30 seconds at most.  I've found a way to do something like do a Background.exit() with an error code after 28 seconds using Sensor.enableSensorEvents, but It's a kludge and I don't use it in any of my published apps.

    What this all gets down to is understanding why you are seeing any time out errors at all.

  • 0 in reply to jim_m_58
    jim_m_58 said:
    The first thing is that when you test in the sim, things are generally much faster than on a real device.

    I'm only describing what I'm seeing on my actual device.  I'm not looking at the sim right now.

    jim_m_58 said:
    Then, you want to consider why you get timeout errors at all.

    Actually, I find the connection issue itself to be less of an issue.  I can accept that somewhere along the chain of connections from the watch to the phone and the server and back, something may go wrong.  But, I would expect the watch to do a better job of detecting when there is an issue.

    jim_m_58 said:
    In a background service things can run 30 seconds at most.

    This is helpful, but I would expect the webrequest to be set up so that it times out before the service (or app, widget, or whatever is making the webrequest -- in my case it's the background service for my app) runs out of time to call the callback function.  If it's not set up that way, that is a real issue.

    jim_m_58 said:
    I've found a way to do something like do a Background.exit() with an error code after 28 seconds using Sensor.enableSensorEvents, but It's a kludge and I don't use it in any of my published apps.

    To be honest, it is tempting to use this as a work-around. Why don't you do it in published apps?  I mean, it is obvious code smell to use a function for something other than it's intended purpose, but is there something else?  Battery issues?

  • 0 in reply to 7555607

    What I posted I base on having CIQ apps that do comm for many years.

    In the case of a background, if something takes more than 30 second, there's an issue someone in the pipeline.  I have a few things where in the background, I use the lat/lon to request the nearest stations, and then request data for that station, and in another where I request data from two different location.

    When there are errors, I'll generally see them

  • 0 in reply to 7555607

    Have you tried pointing at a different website?

    Then in onBackgroundData, just ignore any data you get.

    That will help to see where the problem is.

  • 0 in reply to jim_m_58

    You're right, I should try another website.  I'll set that up and see what happens.

  • 0

    I think I know what's going on.  I was calling Background.exit() right after making my web request.  I had made a mistake in my code that made me think that I was getting a response from the web, when I was actually just directly calling the callback.  So, the real issue I have is the same as this question.  Can I wake up my app from a web request callback?  I thought I found a way, but I was just fooling myself.