GDXRepo Sep 14 2016 at 21:13

Архитектура сетевого ядра в iOS-приложении на Swift 3. Часть 1

10 min

16K

Development for iOS*Swift*

Tutorial

Comments 32

house2008 Sep 15 2016 at 06:01

Мне кажется enum для ResponseError было бы удобнее

enum ResponseError {
    case Success()
    case Fail(ErrorType, Int)
}

ResponseError.Fail(NSError(domain: "AppDomain", code: -1, userInfo: nil) , 500)

Почему бы не использовать struct вместо классов?

GDXRepo Sep 15 2016 at 11:17

На мой взгляд, по поводу enum — тут больше вопрос вкуса. Я пока не привык к таким конструкциям. Кроме того, получится ли сделать нормальную обработку входного JSON в такого рода перечислениях? Можно попробовать, но я особо преимуществ пока не вижу. А по поводу структур — нет, не стоит. Здесь копирование данных ни к чему, ссылки здесь более корректны, на мой взгляд. Структуры — вещь хорошая, но их не стоит использовать прямо везде, насколько я понял из советов Apple в WWDC. В нашей архитектуре вполне уместны классы.

-2

house2008 Sep 17 2016 at 12:23

Здесь копирование данных ни к чему

На самом деле структуры очень эффективны если все поля в них value types, что мы как раз видим в случае с ResponseError классом. Счетчик ссылок для ref types создает достаточно большие накладные расходы, если мы говорим о производительности. То есть в данном случае дешевле скопировать, чем сделать инкремент и декремент счетчика. Насколько мне известно, есть некоторые оптимизации для value types на уровне стека методов, чтобы как можно реже обращаться в heap.

GDXRepo Sep 17 2016 at 13:12

Совершенно согласен, и поскольку в нашем случае в состав входят далеко не value-типы, я предпочел не пользоваться структурами) Так-то верно, при использовании value-типов структуры становятся куда более оптимальным решением.

IgorFedorchuk Sep 21 2016 at 12:29

Можно вместо ResponseError использовать NSError, так как поля code и message уже есть у NSError.

GDXRepo Sep 21 2016 at 16:26

Совершенно верно, но я взял свой класс, так как на реальном серваке поля могут быть другими, так сразу понятно, где и как их можно прописать. Так-то да, в данном случае свой класс избыточен.

UFO just landed and posted this here

house2008 Sep 26 2016 at 12:13

Всё верно. Некоторые добавляют map/flatMap чтобы выстраивать цепочку трансформаций.

enum Result<E> {
    case Success(E)
    case Fail(Error)
    
    func map<V>(_ fn: (E) -> V) -> Result<V> {
        switch self {
        case .Success(let result): return .Success(fn(result))
        case .Fail(let error): return .Fail(error)
        }
    }
}

s1dd0k Sep 15 2016 at 12:50

Есть еще вот такой фреймворк, призванный помочь в организации сетевого кода

https://github.com/Moya/Moya

GDXRepo Sep 15 2016 at 12:52

Посмотрел, спасибо, интересное решение. Отчасти похоже на то, что мы в статье разбираем.

DenHeadless Sep 15 2016 at 14:32

А вот еще =)

https://github.com/MLSDev/TRON

GDXRepo Sep 15 2016 at 14:34

Вот это уже значительно больше похоже на то, чего я пытаюсь добиться с помощью описываемого способа) Очень любопытно, спасибо! Изучу, как только его обновят до третьей версии языка, пока что, опять-таки, не получится им воспользоваться в моих проектах. Но реализация прямо похожа на то, что нужно. Благодарю!

DenHeadless Sep 15 2016 at 14:35

Мы обновим его до свифт 3 на этих выходных =) Пока что есть девелопмент версия в бранче swift3, она почти готова к релизу, осталось отполировать использование Alamofire 4.0 до нормального вида.

GDXRepo Sep 15 2016 at 14:36

Супер! Определенно нужно посмотреть)

UFO just landed and posted this here

Florelit Sep 15 2016 at 13:53

Неплохой фреймворк для таких целей https://github.com/Alamofire/Alamofire

GDXRepo Sep 15 2016 at 13:54

Вы невнимательно прочитали первые два абзаца в моей статье. Поэтому немножко не поняли, о чем она, и почему Alamofire не касается темы статьи.

Florelit Sep 15 2016 at 17:58

Простите, воспаленный мозг выразился абсолютно не верно. Цель обвязки описанной в статье очевидно совершенна другая. А моя фраза была отсылом к пункту 3 секции «С чего начнем?»

Также условимся, что для «низкоуровневого» сетевого общения нам не потребуется отдельная сетевая библиотека, мы напишем эту часть сами (тем более, на момент написания этой статьи сетевых библиотек, обновленных до версии языка 3.0, попросту нет).

GDXRepo Sep 17 2016 at 13:13

А))) Тогда понятно. В данном случае я не стал использовать прослойку, во-первых, для упрощения кода и упрощения объяснений, а во-вторых, потому что и стандартного URLSession нам будет более, чем достаточно, да и реализуется он очень быстро)) В реальном проекте, конечно, зачастую предпочтительнее использовать специализированное решение.

Ariandr Sep 15 2016 at 16:15

Интересно!
А когда выйдет 2 часть статьи и о чем там собственно будет написано?

GDXRepo Sep 15 2016 at 16:15

Я уже занимаюсь второй частью. Там я расскажу о практическом применении созданной архитектуры.

Ariandr Sep 15 2016 at 16:21

Окей, будем ждать. :)

eserikov7 Sep 15 2016 at 23:07

А не проще использовать AFNetworking + ObjectMapper? И описывать только модели.

GDXRepo Sep 15 2016 at 23:14

Не совсем проще. Так и происходит в проектах, как правило, и за неимением толковой структуры это обычно превращается в мусорку (сколько я успел понаблюдать).

eserikov7 Sep 16 2016 at 12:22

А чем эта альтернативная реализация библиотеки AFNetworking решает проблему?

GDXRepo Sep 16 2016 at 14:24

Это НЕ альтернатива AFNetworking. Смысл решения из статьи совершенно другой.

askl Sep 16 2016 at 09:48

Хотелось бы увидеть удобную реализацию решения на базе этого ядра такой популярной проблемы как обновление токена авторизации к апи и повторение запросов, которые привели к обновлению. Т.е. допустим токен авторизации протухает каждые 3 часа. Соответсвенно, следующий запрос вернет ошибку авторизации (что-то типа session token expired). Обычно, в такой ситуации, все следующие запросы становятся в очередь до момента обновления токена.

GDXRepo Sep 16 2016 at 14:25

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

ChapayHabr Sep 19 2016 at 21:15

Если session token expired отвалился, то на клиенте есть refresh token который посылается на сервак и сервак отдает новый session token
у нас этот так реализовано:
— запрос на котором он отвалился мы «запомнили»
— попробовали обновить токен
— если токен обновился, то снова выполняем запрос на котором он отвалился

Сбрасывать всю очередь запросов есть смысл когда от юзера просим перелогин, вы наверное имели ввиду такой кейс

GDXRepo Sep 19 2016 at 21:17

любопытно. А на основе чего генерите рефреш токен? Безопасно ли его хранение в приложении, если он статический?

ChapayHabr Sep 21 2016 at 18:09

вроде тут описано нормально
https://geektimes.ru/post/77648/undefined/?checklogin=true

FirsofMaxim Sep 18 2016 at 20:59

Спасибо, идеи хорошие! Можно еще добавить статический конструктор для сервиса (в «chain» стиле), в котором можно указать внешние модули: парсер данных, низкоуровневая сетевая библиотека, обработчик ошибок, логгер и т/д — как вишенка на торт.

Show the best of all time