Невозможно вызвать URLSessionTaskDelegate#willBeginDelayedRequest, несмотря ни на что
Что бы я ни делал, willBeginDelayedRequest не вызывается. Другие вызовы делегатов работают отлично.
Обратите внимание, что это даже не фоновое приложение, это простой случай...
- запустите приложение
- убить подключение к интернету
- теперь отправьте свой вызов API или что-то еще
- см. сообщение «А»
- позже включи интернет
- см. сообщение «С»
- :( вы никогда не увидите сообщение "B"
Я видел такое поведение во многих проектах. Как заставить willBeginDelayedRequest работать??
Делегат...
class Main: UIViewController, CLLocationManagerDelegate, URLSessionTaskDelegate {
код ..
func urlSession(_ session: URLSession, taskIsWaitingForConnectivity task: URLSessionTask) {
print("(A) works perfectly - phone was offline when task was started")
}
// Doesn't seem to work ...
func urlSession(_ session: URLSession, task: URLSessionTask, willBeginDelayedRequest request: URLRequest, completionHandler: @escaping (URLSession.DelayedRequestDisposition, URLRequest?) -> Void) {
print("(B) this is never called, even when the command completes perfectly :/")
}
установка делегата...
let cfg = URLSessionConfiguration.default
cfg.waitsForConnectivity = true
let task = URLSession(configuration: cfg).dataTask(with: request) { [weak self] (data, response, error) in
...
...
print("(C) after net restored, this runs flawlessly")
}
task.delegate = ..
task.resume()
ах! Думаю, ты решил головоломку @Larme !! Спасибо. Возможно, стоит дать ответ для гуглеров? Казалось бы, НЕТ вызова, сообщающего вам, что в нефоновом случае он «начался снова» - вы случайно не знаете, так ли это? ТС снова
Вы ищете доступность (т. е. знаете, когда вернетесь к «подключению к Интернету»)?
ура @Larme, нет, мы используем это в большинстве проектов. Когда я создаю URLSessionDataTask , он сообщит мне (очевидно, через делегата), когда/если возникла проблема с отправкой. Я хочу, чтобы он сообщил мне, когда он снова установил соединение (и/или, неявно, когда он снова попытается и/или поверит, что теперь это возможно).
{В некоторых случаях это можно сделать небрежно с помощью .progress, но на самом деле это не ответ.)
Ответы 1
Важная часть вашего сценария: не в фоновом режиме.
В документе urlSession(_:task:willBeginDelayedRequest:completionHandler:) говорится:
Этот метод вызывается, когда задача фонового сеанса с задержкой время начала (установленное в свойстве EarlyBeginDate) готово к начинать. Этот метод делегата следует реализовывать только в том случае, если запрос может устареть во время ожидания загрузки сети, и его необходимо заменен новым запросом. Чтобы загрузка продолжилась, делегат должен вызовите обработчик завершения, передав расположение, которое указывает как должна выполняться задача. Прохождение Расположение URLSession.DelayedRequestDisposition.cancel эквивалентно для непосредственного вызова метода cancel() для задачи.
В документе urlSession(_:taskIsWaitingForConnectivity:) говорится:
Этот метод вызывается не более одного раза для каждой задачи и только в том случае, если соединение изначально недоступно. Это никогда не требуется фоновые сеансы, поскольку waitsForConnectivity игнорируется для эти сеансы.
Это должно объяснить, почему в вашем тесте вызывается метод URLSessionTaskDelegate, а urlSession(_:taskIsWaitingForConnectivity:) — нет.
«Обратите внимание, что этого нет даже в приложении с поддержкой фонового режима» противоречит обсуждению этого метода: «Этот метод вызывается, когда выполняется задача фонового сеанса с отложенным временем запуска». Другой (тот, который «работает») говорит: «Он никогда не вызывается для фоновых сеансов, потому что waitsForConnectivity игнорируется для этих сеансов», поэтому такое поведение кажется нормальным.