- ANSWER IPHONE CALLS ON MAC OS 10.3.1 MOVIE
- ANSWER IPHONE CALLS ON MAC OS 10.3.1 CODE
- ANSWER IPHONE CALLS ON MAC OS 10.3.1 PLUS
(My "not always" is "about half the time").Ģ. That is: Home button halts the didWriteData method calls (after a short time which I'll call T), tapping on the app icon does not always resume them. If the problem occurs in that sample (even if it requires a few tweaks to get it to reproduce), that’s definitely bugworthy.Īpple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = "eskimo" + "1" + apologize for digging out an old thread for a problem which may well have been resolved since then, but just to add, for Quinn's benefit:ġ. Have you tried reproducing this with a small test app? The obvious candidate here is the Simple Background Transfer sample code. This is not acceptable in a production app (see QA1561) but it’s handy for testing. You can test this by adding a ‘Quit’ button to your app that terminates the app by calling exit. IMPORTANT Do not test this by force quitting your app. One interesting test would be to terminate your app to see if things work in that case. If this is a problem it’s caused by NSURLSession not correctly reconnecting to the session when you come back from being suspended in the background.
ANSWER IPHONE CALLS ON MAC OS 10.3.1 CODE
See my Testing Background Session Code pinned post for information on why this is important, and for other testing tips. I presume that you’re testing this by running your app from the Home screen rather than from Xcode. On the other hand, your investigation so far seems to strongly indicate that this is a bug in NSURLSession. On the one hand my suspicion is that, if this problem were widespread, I would have seen lots of reports from other developers about it. This is the same behavior I see above in my application.Īny help with this would be greatly appreciated.
ANSWER IPHONE CALLS ON MAC OS 10.3.1 MOVIE
After a given amount of time of the progress not moving the download does eventually finish (the progress indicator disappears) and the Netflix movie is downloaded and able to be played. Progress incremented as expected, they then backgrounded the application and waited ~20 seconds and re-opened the application, only to find the progress get stuck where it was when the app was initially backgrounded and it never moves.
ANSWER IPHONE CALLS ON MAC OS 10.3.1 PLUS
In fact they went a step further and opened the Netflix application on their 10.3.1 iPhone 7 Plus device and began downloading a movie. I also had a co-worker test this as well and they also experienced this. From my testing/debugging I cannot get progress to work in my application on the iPhone 7 Plus running 10.3.1. I am at a bit of a loss and am wondering if there is a known bug we should be looking out for, and if so when we could expect a fix? Or if there are currently any known work arounds. More often than not (9 times out of 10) the progress is never reported on this device after re-opening the application. I have however had a few instances where my iPhone 7 Plus device running iOS 10.3.1 did show progress after bringing the app back into the foreground however those instances I could could on one hand. all happen right at the end in one burst. So the didWriteData, didFinishDownloading, didCompleteWithError, etc. The didFinishDownloading method does end up getting called however it appears to wait until the very end of all the download tasks completions for that method to fire for all of the remaining tasks. The downloads kick off fine, progress is reported as expected in the didWriteData method, however if I background the application and wait ~10 seconds and re-open the application the progress never catches back up to what progress would have been done in the background and the progress never increments at all (it stays where it was when it was backgrounded). Where things get weird is on my iPhone 7 Plus which is running iOS 10.3.1. This also appears to work great on a new 5th generation iPad running iOS 10.3. I am able to put 100+ download tasks into the queue and they all finish and report progress as expected after sending the application into the background and then re-opening the application. Background Transfer Service works great on this device. I did most of my building/testing on an old iPhone 6 device that was running iOS 9.3.5 (I try to keep my previous device back a version of iOS). I've recently been integrating Background Transfer Service into an application so that the user is able to download files in the background.
0 kommentar(er)
