I am making POST web service calls in parallel which are asynchronous, setting the time interval of NSMutableURLRequest to 180 seconds.
But my didFailWithError: delegate is not getting triggered exactly at the interval of 180 seconds, rather it goes too less to 75 seconds or too greater value to 220 seconds and so on, but not once for 180 seconds.
As far I scanned through the similar questions, there is no solid solution for this. But at much places, I could see like timeOutInterval will not work for POST methods.
I just want to know whether this issue is true with POST methods and Is there any way to overcome this at least in iOS8?
If you are using POST and an iOS version bellow 6, you have to set a value above 240 seconds. Otherwise, your timeout will be ignored. See this post and this question.
Related
I am using Google Ads REST API to pull Ads data. I am not using client library.
One question, how do you programatically check current API usage when calling requests, so you can stop and wait before continuing? Other APIs like Facebook Marketing API has a header in the result that tells you how much requests you have left, so I could stop and wait. Is there a similar info on Google Ads REST API?
Thank you for reading this.
I've seen nothing in the documentation so far to suggest that there is :(
(There is, separately, a RateExceeded error, which includes a retryAfterSeconds field, if you're going too fast / the API is overloaded.)
Ultimately, I tried this method. So far, I haven't reached limit with it:
The basic developer token for Google Ads API allow 15,000 requests per day as of this answer (Link: https://developers.google.com/google-ads/api/docs/access-levels). So that's 15,000 / 24 = 625 requests every hours.
Further divisions show that I can have 625/60 = 10.4 requests every minutes. So 1 request every 6 seconds will ensure I won't reach rate limit.
So my solution is:
Measure the time it takes to complete a request call and subsequent processing
If total time is over 6 seconds, perform the next request. Else, wait so the total time is 6 seconds, then perform the next request.
The below code is what I used to perform this. Hope it helps you guys.
import time
from math import ceil
waiting_seconds = 6
start_time = time.time()
###############PERFORM API REQUEST HERE
#Measure how long it takes, should be at least 6 secs to be under API limit
end_time = time.time()
elapsed = end_time - start_time
if elapsed < waiting_seconds:
remaining = ceil(waiting_seconds - elapsed)
time.sleep(remaining)
I have a program in SWIFT, that detects when a beacon or multiple beacons are out of range and based on
that it will perform something like saving some data into database and etc. Everything works well, however I do get lots of
false positive in a way that "didExitRegion" getting fired and few secs later "didEnterRegion" getting fired while I haven't been moved or etc.
I know this has lot to do with the tuning of the beacons and their qualities, but at this time I have come up with an alternative solution.
So I decided to use NSTimer to see if I am really off range or is it just a false positive that I am getting?
so when didExitRegion is getting fired, I start a NSTimer for 60 secs. If the 60 secs is up and didEnterRegion didn't get fire, then I know
I am really out of range and perform whatever data saving I need to do.
Otherwise if didEnterRegion is called within that 60 secs, then I'll assume it was a false positive and invalidate the
nstimer and not doing anything.
Everything works well as long as I am working with one beacon. The problem I have with timer is when multiple beacons go out of range.
lets say first beacon is out of range, so didExitRegion is getting fire and start the NSTimer
Let say 20 secs later second beacon is off range and again didExitRegion is getting fired and that one starts the NSTimer again.
Now my NStimer is all out of synch and at that time, things are not working correct and the NSTimer continuously start itself when 60 secs
is up and etc.
So my question is what is the work around this solution? How can I keep my nstimer in synch when is called again before is invalidated?
Is there a better way to this solution? Again, I know a better quality beacons can help, but that is not an option for me at this time.
One solution is to keep a dictionary like this:
var pendingExits = Dictionary<CLBeaconRegion,NSDate>()
Each time you get a didExitRegion call:
Only start the NSTimer if the dictionary is empty -- otherwise, assume the timer is already running.
Add the region to the dictionary along with a new NSDate() to set the timestamp of when it was added.
When you get a didEnterRegion callback:
Look for the region in the dictionary. If it is there, remove it.
When the timer goes off:
Look for any entry with a timestamp 60 seconds or more old. For this, remove the region from the dictionary and fire your custom exit logic.
Find the newest remaining timestamp (if any) in the dictionary. Start the timer to go off at that time plus 60 seconds.
I want to ask how is GeofenceState.Exited intended?
When I have a background task with GeofenceState.Entered, when I move inside the circle, I get IBackgroundTask.Run() run every 2 minutes (why 2 minutes?)
But with GeofenceState.Exited, I can walk miles, but it never gets triggered. Is there some bug, or is that intended differently than I suppose? I guess it should work this way: when the check is done after 2 minutes, when I'm outside of the circle, the method Run is called.
I have a parameter 50 and dwell time 1 sec.
Thanks
I have some tests that are very slow and I want to set as timeout 15 minutes.
As test purpose I have this example:
[Test, Timeout(900000)]
public void Test1()
{
Thread.Sleep(900001);
}
The test after some time stops without errors.
What's the correct way to do it?
As you know, both Thread.Sleep and NUnit's TimeoutAttribute take time in milliseconds. Specifying times that are 1 millisecond off from each other isn't enough to guarantee a timeout due to thread scheduling and general timer accuracy. See this answer for a little more discussion about the accuracy of Thread.Sleep, and by extension NUnit's timeout thread's accuracy.
Try specifying a larger difference between the two numbers and I suspect you'll see it behaves as you'd expect. For instance, sleep for 900100 milliseconds and leave the timeout value as is. With a timeout of 15 minutes, you won't notice an extra tenth of a second waiting for it to timeout.
I use a AFHTTPRequestOperation to upload between 1-6 images to a web server. The weird thing is that when it reports progress in my "setUploadProgressBlock" it reports totalBytesWritten as:
32,768
32,768
32,768
32,768
3,238
2,420
2,420... and keeps repeating 2420 until final chunk which is the remainder.
I'm using a UIProgressView to report upload progress, which jumps to 30% or so immediately because of the unequal chunks in the beginning (32,768 byte chunks). I have cheated this to basically ignore the first four large chunks, but I'm wondering if anyone has an explanation for why it does this, or a more elegant way to handle it. Also, once it reports that all bytes have been written, it sits there "doing nothing" for several seconds which seems like an unreasonably long delay. I've handled this with a UIActivityIndicator (spinner), but it's annoying that the delay is so long. I should mention that this is tested on 3g as that will be the target environment.
Can you double check that you're not reading the value for bytesWritten, which reports how many bytes were uploaded in the last batch, as opposed to totalBytesWritten? Alternatively, it may be that several uploads are being performed simultaneously, which could be confusing if you're logging these all in the same callback.
The "doing nothing" for several seconds could be waiting for the response from the server. Do you have any more details about that?