Comments 17
Неплохой подход. Наверное, каждый что-то подобное пилит в каждом своем проекте)) У меня тоже что-то такое встроено самописное поверх Аламофаера. Но возьму на заметку, спасибо. Если будете поддерживать либу, то отлично.
P.S. Где-то в разметке статьи забыли <i* тег закрыть, или закрыли не там, где стоило) Пофиксите пж, а то весь подвал в курсиве)
P.S. Где-то в разметке статьи забыли <i* тег закрыть, или закрыли не там, где стоило) Пофиксите пж, а то весь подвал в курсиве)
UFO just landed and posted this here
в случае какой-то ошибки с запросом вы увидите только что «что-то не работает»Все что может пойти не так на мой взгляд охвачено, это:
— либо нет связи, таймаут
— либо ответ от сервера с неожиданной ошибкой, например 401 вместо 200
— либо ошибка декодирования о которой вы получите полную информацию в дебагере, иначе будет брошен код -2 или enum `_undecodable`
Можно конечно добавить еще и парсинг объекта ошибки сервера, например если сервер всегда бросает на ошибку json вида {error: 401, reason: «Not authorized because token is empty»} или просто строку тогда это можно будет спарсить. Можно было бы сделать, но тогда надо будет больше дженериков(в принципе уже даже придумал как сделать красиво). А так все ошибки видно в дебагере более чем полностью с указанием и всех данных о запросе и об ответе.
Про использование структур вместо классов промолчуА вот чем вам структуры не угодили я не понимаю. Их правильно использовать для Codable, потому что если вы будете использовать классы, то наверняка из-за наследования, а Codable не умеет в наследование и будут ошибки, т.к. часть переменных из суперклассов потеряются, если вы не пропишете кастомный encoder/decoder вручную. Попробуйте в playground сделать JSONEncode класса с наследованием, он выведет вам только значения из суперкласса. Или попробуйте используйте Mirror для чтения переменных класса, он выведет вам только все из первого класса, а из суперкласса нет. Чтобы никто с этим не сталкивался дан пример со структурами.
UFO just landed and posted this here
предполагаю, что логика на сервере может поменяться в любой моментЛогика на сервере не может поменяться в любой момент, это уже будет другая версия API.
Запрос и ответ в нормальном API как раз строгий, поэтому и можно и нужно применять модели. В случае если какие-то поля опциональные можно помечать их опциональными.
То, что нужно прописывать инициализатор это к сожалению недоработка текущей версии Swift, но если структура находится в том же файле, где ее будут инициализировать, то инициализатор прописывать не нужно, так как все-таки отработает дефолтный. По идее дефолтный инициализатор должен работать из любого места, а не только из того же файла, тогда будет всем радость.
В случае со структурами вы обязаны написать километровый init с кучей входных параметров, чтобы инициализировать все поля?Актуально только для структур для запросов, для ответов никакие инициализаторы не нужны. Кстати с классом вы тоже будете писать километровый init чтобы инициализиировать все поля если вы не расставили `!` у каждого поля конечно же (а force unwrapping это кстати зло)
получите рефакторинг всех конструкторовЗвучит совсем не страшно, так как делать это придется очень редко и это не так уж и сложно.
Есть плагины для Xcode чтобы генерировать иниты, например github.com/rjoudrey/swift-init-generator. Я так понимаю, что в классах у вас все проперти являются var, чтобы избавиться от конструктора, тогда мы теряем иммутабельность объекта. К тому же структуры более эффективны касательно работы с памятью, правда если все проперти так же являются value типами.
Планируете поддержку ReactiveCocoa и RxSwift?
Перечитал статью, подумал вот о чем. Мне сильно не хватает в оберточных либах возможности делать dependent-запросы. То есть, зачастую нужно, чтобы отработал вот этот запрос, потом вот этот, и еще вот этот, и только тогда считать группу запросов выполненной. Например, если каждый из них отработал без ошибок, или только парочка из трех запрошенных, допустим. Сейчас решаю это тупой вложенностью (один запрос — onSuccess — второй запрос — onSuccess, и т.д.), что не совсем верно, так как запросы не одновременно идут, но мне хватает. Есть ли планы ввести что-то подобное в либу?
Еще похожая тема — chained-запросы, при котором один запрос идет строго после другого, цепочкой, а результатом является опять результат выполнения группы цепных запросов.
И еще одно — отмена запросов. Юзер перешел на другой экран, ткнул отмену или что-то такое — надо иметь возможность обрубить левые запросы, которые более не нужны.
С этими плюшками будет прям огонь.
Еще похожая тема — chained-запросы, при котором один запрос идет строго после другого, цепочкой, а результатом является опять результат выполнения группы цепных запросов.
И еще одно — отмена запросов. Юзер перешел на другой экран, ткнул отмену или что-то такое — надо иметь возможность обрубить левые запросы, которые более не нужны.
С этими плюшками будет прям огонь.
Sign up to leave a comment.
Codable для API запросов и как навести в коде порядок