Pull to refresh
36
0
Alexander Babaev @bealex

Creating applications and leading development

Send message
Поиграть можно в бесплатную или EAP-версию, можно получить версию для OpenSource проекта (если я верно помню), в общем, возможностей хватает.
О, класс! Не ковырял настолько глубоко и далеко, с удовольствием воспользуюсь.
Для себя: «А давайте будем следить за температурой в комнате ребенка?»

А для самого ребенка что-то вроде «Смотри, какие лампочки!» :-)
Arduino IDE отличная, пользуюсь ей постоянно.
Конечно, я про это и говорю. Работа background сессии происходит вне приложения, внутри системы. Туда нельзя запихнуть никакой кастомный код, включая расширения URLProtocol.
Нет, в данном случае проверку должен сделать сервер, а пуш должен присылаться с информацией «проверка прошла» или нет. Это то решение, которое корректно использует возможности iOS.

В любом случае, по пушу небольшую работу в фоне сделать получится, но это будет самый обычный, foreground URLSession. То есть организовать «пуши чтобы проверялось» — вполне возможно, но не рекомендуется, так как если злоупотреблять фичей, можно получить от системы по лбу.
Это совсем другое. Для решения такой задачи я бы сделал сервер, который это делает так, как требуется, и отправляет пуши в приложение, когда что-то произошло.
Статья про то, как скачать/закачать данные на сервер в фоне (без использования приложения). Не про то, как держать в фоне соединение и реагировать на него. Это совсем другая тема. Насколько мне известно, это надёжно сделать невозможно.
«for your app’s private use». Это не для background-сессии, увы.
Супер дополнение, спасибо. Мне это не требовалось, но вот я нашёл исследование по этому поводу: 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 не увидел про это никакой информации.
Всё так. Причём это умеет делать и обычная, foreground-сессия, я упоминал вскользь об этой функции, когда говорил про http-кеширование. А upload-кеширования в стандартах не существует. Что не мешает некоторым компаниям придумывать свою схему аплоада, при которой возможно его частичное восстановление.
Я работал только с этими протоколами. Есть какие-то конкретные примеры, про которые хочется узнать? Ситуация с ними очень разная.
Цель статьи — не показать способы решения задачи, а продемонстрировать одну из возможностей языка.

Про Стратегию. Чуть ниже обсуждают похожее решение. Конечно же, можно использовать и её, ни в коем случае не говорю, что нужно только так и описывать платёжные модели. Это просто пример. :-)
Почему перечисления предполагается совмещать именно с int'ом? Какие недостатки у Свифтового подхода?
Какие именно дела имеются в виду?
Упс :) Спасибо!
Я обновил код до 0.9.12, он стал сильно стабильнее и умнее. Если будете пользоваться — лучше использовать именно эту версию.
Добавил немного методов, чтобы проще было подключить методы редактирования UITableViewDataSource. (код в обновлении статьи про 0.9.12)
Никаких обид, отличное предложение.

Это можно сделать, вообще не вопрос. Не уверен только, что правильно. И вот почему.

Дело в том, что NSFetchedResultsController был сделан для UITableView, и так себе, например, подходит для UICollectionView с его performBatchUpdates.

Также разнится и источник изменений. В NSFetchedResultsController — внешняя сущность, CoreData. А у меня изменения должны вливаться в модель бизнес-логикой приложения. В этой ситуации проще применить сразу все изменения, нежели выдавать их по-одному.

Другое дело, что, возможно, имеет смысл дать возможность подключить стандартные операции, которые приходят из UI (редактирование таблицы из UI, перемещение ячеек) — это интересная мысль, я подумаю, что тут можно сделать.
Глянул. Ничего особо не должно препятствовать использованию ATableAnimationCalculator даже вместо NSFetchedResultsController. Конечно, мы потеряем события об изменении запросов, но если нужно обновлять по требованию пользователя, то будет даже немного проще.

Ну, или подключиться к событиям, после чего заполнить результат вручную (я имею в виду ATableDiff, там достаточно простые поля), и в controllerDidChangeContent — сказать diff.applyTo(collectionView:collectionView).

Впрочем, не уверен, что только ради второй части нужно использовать ATableAnimationCalculator :)

Information

Rating
Does not participate
Works in
Date of birth
Registered
Activity

Specialization

Software Developer, Mobile Application Developer
Lead
iOS development
iOS Human Interface Guidelines
SWIFT
SwiftUI