bealex Dec 20 2019 at 11:13

iOS. Работа с сетью, когда приложение не запущено

14 min

25K

red_mad_robot corporate blogDevelopment for iOS*Swift*

+17

Comments 18

akme Dec 20 2019 at 18:24

А с другими протоколами такой flow работает или только с HTTP?

bealex Dec 20 2019 at 22:20

Я работал только с этими протоколами. Есть какие-то конкретные примеры, про которые хочется узнать? Ситуация с ними очень разная.

akme Dec 22 2019 at 05:23

Ну, например, какой-нибудь мониторинг сделать, ping в бекграунде или отслеживание состояния TCP порта…

bealex Dec 22 2019 at 11:34

Это совсем другое. Для решения такой задачи я бы сделал сервер, который это делает так, как требуется, и отправляет пуши в приложение, когда что-то произошло.

akme Dec 22 2019 at 13:14

Дак интерес как раз в мониторинге с мобильного девайса, а не сервера, в любом случае работу «проверки» должен выполнить девайс, даже если ему сервер пришлет пуш.

bealex Dec 23 2019 at 11:13

Нет, в данном случае проверку должен сделать сервер, а пуш должен присылаться с информацией «проверка прошла» или нет. Это то решение, которое корректно использует возможности iOS.

В любом случае, по пушу небольшую работу в фоне сделать получится, но это будет самый обычный, foreground URLSession. То есть организовать «пуши чтобы проверялось» — вполне возможно, но не рекомендуется, так как если злоупотреблять фичей, можно получить от системы по лбу.

mkll Dec 22 2019 at 00:45

Из документации:

URLSession supports the HTTP/1.1 and HTTP/2 protocols. HTTP/2 support, as described by RFC 7540, requires a server that supports Application-Layer Protocol Negotiation (ALPN).

You can also add support for your own custom networking protocols and URL schemes (for your app’s private use) by subclassing URLProtocol.

akme Dec 22 2019 at 05:26

Похоже это будет непросто) спасибо за линк

bealex Dec 22 2019 at 11:28

«for your app’s private use». Это не для background-сессии, увы.

mkll Dec 22 2019 at 21:11

Мне думается, тут ничего нельзя сказать по поводу возможности или невозможности background-сессии. Процитированное вами — лишь уточнение, что ваш кастомный протокол будет доступен только для вашего же приложения, а не system-wide.

bealex Dec 23 2019 at 11:16

Конечно, я про это и говорю. Работа background сессии происходит вне приложения, внутри системы. Туда нельзя запихнуть никакой кастомный код, включая расширения URLProtocol.

mkll Dec 23 2019 at 17:05

Да, действительно, согласен.

vani2 Dec 21 2019 at 11:13

Полезная информация про фоновую сессию: download task вполне себе умеет докачивать файл, если прерывается соединение, тогда как upload task перезапустит выгрузку с самого начала. Может быть неудобно, если выгружаешь файл большого размера на сервер на плохом соединении.

bealex Dec 21 2019 at 11:36

Всё так. Причём это умеет делать и обычная, foreground-сессия, я упоминал вскользь об этой функции, когда говорил про http-кеширование. А upload-кеширования в стандартах не существует. Что не мешает некоторым компаниям придумывать свою схему аплоада, при которой возможно его частичное восстановление.

dm_zharov Dec 21 2019 at 13:47

В background сессии не вызывается метод делегата didReceiveChallenge: URLAuthenticationChallenge. Доступен только ServerTrust, кому необходим ClientCertificate – знайте это.

bealex Dec 21 2019 at 13:47

Супер дополнение, спасибо. Мне это не требовалось, но вот я нашёл исследование по этому поводу: github.com/Alamofire/Alamofire/issues/1122#issuecomment-246562127

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 не увидел про это никакой информации.

maverickcy Dec 22 2019 at 02:02

А что по поводу VOIP? Испробовал несколько приложений уже, ни одно не держит соединение дольше пары блокировок экранов

bealex Dec 22 2019 at 11:32

Статья про то, как скачать/закачать данные на сервер в фоне (без использования приложения). Не про то, как держать в фоне соединение и реагировать на него. Это совсем другая тема. Насколько мне известно, это надёжно сделать невозможно.