Pull to refresh

Comments 17

Неплохой подход. Наверное, каждый что-то подобное пилит в каждом своем проекте)) У меня тоже что-то такое встроено самописное поверх Аламофаера. Но возьму на заметку, спасибо. Если будете поддерживать либу, то отлично.

P.S. Где-то в разметке статьи забыли <i* тег закрыть, или закрыли не там, где стоило) Пофиксите пж, а то весь подвал в курсиве)
Спасибо большое, текст исправил, там был код который парсер срезал и получился глюк)
Либа будет жить долго ^_^
поправьте меня если ошибаюсь, но в случае какой-то ошибки с запросом вы увидите только что «что-то не работает». Либо вам придется писать полноценный парсинг значений, с которым Codable отличается от существующих решений только тем, что поставляется с ios sdk.
Про использование структур вместо классов промолчу — на клиенте ужасно неудобная штука, но может на сервере все по-другому
в случае какой-то ошибки с запросом вы увидите только что «что-то не работает»
Все что может пойти не так на мой взгляд охвачено, это:
— либо нет связи, таймаут
— либо ответ от сервера с неожиданной ошибкой, например 401 вместо 200
— либо ошибка декодирования о которой вы получите полную информацию в дебагере, иначе будет брошен код -2 или enum `_undecodable`

Можно конечно добавить еще и парсинг объекта ошибки сервера, например если сервер всегда бросает на ошибку json вида {error: 401, reason: «Not authorized because token is empty»} или просто строку тогда это можно будет спарсить. Можно было бы сделать, но тогда надо будет больше дженериков(в принципе уже даже придумал как сделать красиво). А так все ошибки видно в дебагере более чем полностью с указанием и всех данных о запросе и об ответе.

Про использование структур вместо классов промолчу
А вот чем вам структуры не угодили я не понимаю. Их правильно использовать для Codable, потому что если вы будете использовать классы, то наверняка из-за наследования, а Codable не умеет в наследование и будут ошибки, т.к. часть переменных из суперклассов потеряются, если вы не пропишете кастомный encoder/decoder вручную. Попробуйте в playground сделать JSONEncode класса с наследованием, он выведет вам только значения из суперкласса. Или попробуйте используйте Mirror для чтения переменных класса, он выведет вам только все из первого класса, а из суперкласса нет. Чтобы никто с этим не сталкивался дан пример со структурами.
когда разрабатываю клиента, то предполагаю, что логика на сервере может поменяться в любой момент. Да и сам до конца не знаю, как будет выглядеть мой код в конце. В случае с классами объявляю класс и перечисляю в нем список переменных и если нужно, то добавляю init без параметров, если приложение ругается и требует инициализации эти переменных.
В случае со структурами вы обязаны написать километровый init с кучей входных параметров, чтобы инициализировать все поля? В статье вы это уже делаете. А если хотите изменить внутренности структуры — получите рефакторинг всех конструкторов, потому что конструктор структуры меняется даже если поменять просто порядок слеования переменных
предполагаю, что логика на сервере может поменяться в любой момент
Логика на сервере не может поменяться в любой момент, это уже будет другая версия API.
Запрос и ответ в нормальном API как раз строгий, поэтому и можно и нужно применять модели. В случае если какие-то поля опциональные можно помечать их опциональными.

То, что нужно прописывать инициализатор это к сожалению недоработка текущей версии Swift, но если структура находится в том же файле, где ее будут инициализировать, то инициализатор прописывать не нужно, так как все-таки отработает дефолтный. По идее дефолтный инициализатор должен работать из любого места, а не только из того же файла, тогда будет всем радость.

В случае со структурами вы обязаны написать километровый init с кучей входных параметров, чтобы инициализировать все поля?
Актуально только для структур для запросов, для ответов никакие инициализаторы не нужны. Кстати с классом вы тоже будете писать километровый init чтобы инициализиировать все поля если вы не расставили `!` у каждого поля конечно же (а force unwrapping это кстати зло)

получите рефакторинг всех конструкторов
Звучит совсем не страшно, так как делать это придется очень редко и это не так уж и сложно.
Есть плагины для Xcode чтобы генерировать иниты, например github.com/rjoudrey/swift-init-generator. Я так понимаю, что в классах у вас все проперти являются var, чтобы избавиться от конструктора, тогда мы теряем иммутабельность объекта. К тому же структуры более эффективны касательно работы с памятью, правда если все проперти так же являются value типами.
Уже получал этот вопрос, планирую.
Или может быть у вас есть желание прислать pull request? :)

Спасибо! Обязательно попробую на следующем проекте

Перечитал статью, подумал вот о чем. Мне сильно не хватает в оберточных либах возможности делать dependent-запросы. То есть, зачастую нужно, чтобы отработал вот этот запрос, потом вот этот, и еще вот этот, и только тогда считать группу запросов выполненной. Например, если каждый из них отработал без ошибок, или только парочка из трех запрошенных, допустим. Сейчас решаю это тупой вложенностью (один запрос — onSuccess — второй запрос — onSuccess, и т.д.), что не совсем верно, так как запросы не одновременно идут, но мне хватает. Есть ли планы ввести что-то подобное в либу?

Еще похожая тема — chained-запросы, при котором один запрос идет строго после другого, цепочкой, а результатом является опять результат выполнения группы цепных запросов.

И еще одно — отмена запросов. Юзер перешел на другой экран, ткнул отмену или что-то такое — надо иметь возможность обрубить левые запросы, которые более не нужны.

С этими плюшками будет прям огонь.
все что вы описали можно сделать с помощью реактивщины.
Можно. А все, что сделал автор в либе, можно сделать и без этой либы. Но я говорю конкретно о ней и ее фишках, а не о других способах выполнить задачу. Другие способы есть всегда.
Спасибо большое, я постарался сделать описанный вами функционал.
Надеюсь, что все понял правильно, посмотрите пожалуйста UPD2 в статье :)
Очень неплохо, спасибо, стало значительно круче.
Only those users with full accounts are able to leave comments. Log in, please.