Конечно, я про это и говорю. Работа background сессии происходит вне приложения, внутри системы. Туда нельзя запихнуть никакой кастомный код, включая расширения URLProtocol.
Нет, в данном случае проверку должен сделать сервер, а пуш должен присылаться с информацией «проверка прошла» или нет. Это то решение, которое корректно использует возможности iOS.
В любом случае, по пушу небольшую работу в фоне сделать получится, но это будет самый обычный, foreground URLSession. То есть организовать «пуши чтобы проверялось» — вполне возможно, но не рекомендуется, так как если злоупотреблять фичей, можно получить от системы по лбу.
Это совсем другое. Для решения такой задачи я бы сделал сервер, который это делает так, как требуется, и отправляет пуши в приложение, когда что-то произошло.
Статья про то, как скачать/закачать данные на сервер в фоне (без использования приложения). Не про то, как держать в фоне соединение и реагировать на него. Это совсем другая тема. Насколько мне известно, это надёжно сделать невозможно.
What I found in the sample app is that with background sessions, server trust challenges are automatically evaluated. You'll never get called when performing the TLS handshake. iOS is just going to evaluate the cert and establish the connection if the cert chain is valid and fail if it's not. I tested both cases with httpbin.org/get and expired.badssl.com. The challenge delegate API just isn't called in either case running on a device or in the simulator. I am assuming this is for performance reasons. If you end up needing to do something like cert pinning or allowing a connection if the cert is invalid (self-signed certs), then you just can't use a background session.
What was interesting is that the delegate is called on a basic-auth challenge. Now from what I can gather from the Handling Authentication docs is that basic-auth challenges are non-session-level challenges. I can only assume that these types of challenges are not automatically evaluated on background sessions, where session-level challenges are.
Long story short, there's nothing we can do here. Server trust challenges are automatically handled by iOS with background session configurations. As such, I'm going to go ahead and close this issue out since there's nothing we can actually do about it in Alamofire.
Thanks everyone for being patient here until we had time to get to the bottom of the behavior.
Сам, повторюсь, не пробовал, и у Apple не увидел про это никакой информации.
Всё так. Причём это умеет делать и обычная, foreground-сессия, я упоминал вскользь об этой функции, когда говорил про http-кеширование. А upload-кеширования в стандартах не существует. Что не мешает некоторым компаниям придумывать свою схему аплоада, при которой возможно его частичное восстановление.
Цель статьи — не показать способы решения задачи, а продемонстрировать одну из возможностей языка.
Про Стратегию. Чуть ниже обсуждают похожее решение. Конечно же, можно использовать и её, ни в коем случае не говорю, что нужно только так и описывать платёжные модели. Это просто пример. :-)
Это можно сделать, вообще не вопрос. Не уверен только, что правильно. И вот почему.
Дело в том, что NSFetchedResultsController был сделан для UITableView, и так себе, например, подходит для UICollectionView с его performBatchUpdates.
Также разнится и источник изменений. В NSFetchedResultsController — внешняя сущность, CoreData. А у меня изменения должны вливаться в модель бизнес-логикой приложения. В этой ситуации проще применить сразу все изменения, нежели выдавать их по-одному.
Другое дело, что, возможно, имеет смысл дать возможность подключить стандартные операции, которые приходят из UI (редактирование таблицы из UI, перемещение ячеек) — это интересная мысль, я подумаю, что тут можно сделать.
Глянул. Ничего особо не должно препятствовать использованию ATableAnimationCalculator даже вместо NSFetchedResultsController. Конечно, мы потеряем события об изменении запросов, но если нужно обновлять по требованию пользователя, то будет даже немного проще.
Ну, или подключиться к событиям, после чего заполнить результат вручную (я имею в виду ATableDiff, там достаточно простые поля), и в controllerDidChangeContent — сказать diff.applyTo(collectionView:collectionView).
Впрочем, не уверен, что только ради второй части нужно использовать ATableAnimationCalculator :)
А для самого ребенка что-то вроде «Смотри, какие лампочки!» :-)
В любом случае, по пушу небольшую работу в фоне сделать получится, но это будет самый обычный, foreground URLSession. То есть организовать «пуши чтобы проверялось» — вполне возможно, но не рекомендуется, так как если злоупотреблять фичей, можно получить от системы по лбу.
Сам, повторюсь, не пробовал, и у Apple не увидел про это никакой информации.
Про Стратегию. Чуть ниже обсуждают похожее решение. Конечно же, можно использовать и её, ни в коем случае не говорю, что нужно только так и описывать платёжные модели. Это просто пример. :-)
Это можно сделать, вообще не вопрос. Не уверен только, что правильно. И вот почему.
Дело в том, что NSFetchedResultsController был сделан для UITableView, и так себе, например, подходит для UICollectionView с его performBatchUpdates.
Также разнится и источник изменений. В NSFetchedResultsController — внешняя сущность, CoreData. А у меня изменения должны вливаться в модель бизнес-логикой приложения. В этой ситуации проще применить сразу все изменения, нежели выдавать их по-одному.
Другое дело, что, возможно, имеет смысл дать возможность подключить стандартные операции, которые приходят из UI (редактирование таблицы из UI, перемещение ячеек) — это интересная мысль, я подумаю, что тут можно сделать.
Ну, или подключиться к событиям, после чего заполнить результат вручную (я имею в виду ATableDiff, там достаточно простые поля), и в controllerDidChangeContent — сказать diff.applyTo(collectionView:collectionView).
Впрочем, не уверен, что только ради второй части нужно использовать ATableAnimationCalculator :)