GA
Alamofire и codable поддерживает. Почему он деприкейтнут?
Size: a a a
2020 July 24
M
а как версия свифта связана с аламофайром?
Сдк*
FG
Alamofire и codable поддерживает. Почему он деприкейтнут?
потому что очень много проблем решает URLSession
AT
Кто кстати что использует для сериализации? Я пока продолжаю использовать SwiftyJSON так как пока модель не устоялась реально более простого варианта не знаю (Codable - страшный сон, если вдруг меняется модель). Пару раз смотрел что там по производительности, были идеи что-то ещё попробовать, но так в итоге и не менял инструмент
FG
Кто кстати что использует для сериализации? Я пока продолжаю использовать SwiftyJSON так как пока модель не устоялась реально более простого варианта не знаю (Codable - страшный сон, если вдруг меняется модель). Пару раз смотрел что там по производительности, были идеи что-то ещё попробовать, но так в итоге и не менял инструмент
а можно подробнее про кодабл?
FG
почему страшный сон при смене модели
QH
Важно ли, что там по производительности — 10 мс парсить JSON в бэкграунде или 25?
AT
Если коротко, то
- Кодеры/Декодеры - когда есть строго структурированная и типизированная модель. Как только стуктура и типы модели начинают плавать, то, чтобы продолжать использовать декодеры, нужно использовать различные ухищрения типа перечеслений, оборачивающих конкретный типы
- JsonSerialization - тупо перевод из массивов и словарей в json и обратно. Если в исходных объектах будут типы, которые фреймворк не способен будет интерпретировать как примитив, то он выкинет ошибку.
- Кодеры/Декодеры - когда есть строго структурированная и типизированная модель. Как только стуктура и типы модели начинают плавать, то, чтобы продолжать использовать декодеры, нужно использовать различные ухищрения типа перечеслений, оборачивающих конкретный типы
- JsonSerialization - тупо перевод из массивов и словарей в json и обратно. Если в исходных объектах будут типы, которые фреймворк не способен будет интерпретировать как примитив, то он выкинет ошибку.
вот тут подробнее) с этими обёртками работать намного сложнее, если меняется структура - надо переписывать
FG
Важно ли, что там по производительности — 10 мс парсить JSON в бэкграунде или 25?
разница в 2.5 раза!!!
AT
Важно ли, что там по производительности — 10 мс парсить JSON в бэкграунде или 25?
вот поэтому и не менял инструмент)
AT
был какой-то бенчмарк очень старый и там SwiftyJSON был не лучшим, но он давно не обновлялся
SP
вот тут подробнее) с этими обёртками работать намного сложнее, если меняется структура - надо переписывать
разве кодабл перестает работать от неломающих изменений (ну типа добавили еще поле) модели?
AT
от таких нет, а если меняется вложенность - переписывать дофига
AT
приходили проекты на кодабл, “там чуть поменялась модель” и ты зарываешься в изменения на дофига времени, дебажить при этом очень неудобно
AT
а со SwiftyJSON это делается на раз-два
GA
приходили проекты на кодабл, “там чуть поменялась модель” и ты зарываешься в изменения на дофига времени, дебажить при этом очень неудобно
ну вроде протоколом можно закрыть при проектировании. И менять только в netслое.
GA
хотя конечно от архитектуры зависит что там у вас
QH
был какой-то бенчмарк очень старый и там SwiftyJSON был не лучшим, но он давно не обновлялся
а зачем ему обновляться? Давно спецификация JSON обновлялась? :)
AT
либы за 4 года думаю обновлись и не раз)