Search
Write a publication
Pull to refresh

Comments 11

Возьмите Rx/Combine/await+async, чем городить своё. Не вижу довольно обычного кейса, когда один запрос отвалился и нужно остальное отменить. count и dictonary обновляются в разных потоках, предполагаю, что может быть race conditon и done никогда не вызовется. Пока больше похоже на вредные советы.

Да кто же спорит). Я же специально написал, что это пример реализации для того, чтобы было понятно как и что работает. Вы вероятно не представляете, сколько людей в лоб пользуются решениями/библиотеками и т.д. абсолютно не вникая в происходящее. Для этого и я набросал этот фейкокод. Возможно мало предупреждений добавил, поправлю.

Просто вы сделали самую легкую часть, это не интересно) Намного сложнее и важнее как раз детали, ради чего я и зашел прочитать статью. Думал тут увижу супер умный сервис, который по определенный правилам собирается параллельно данные с разных web сервисов и мержит результат и всё на протоколах и дженериках, а еще лучше await/async.

Если Вам подобное интересно, то можно и заморочиться.) Но конкретно в этой публикации мои мотивы несколько в другом, я очень радею за популизацию языка в России и Вы же понимаете, что доступной информации очень мало. А для новоиспеченных разработчиков, так и вовсе не найти. Все ограничивается туториалами про различие переменных и констант. В примере я хотел обозначить несколько моментов. Практический пример передачи замыканий, использование didSet, обращение к экземпляру по цепочке, примитивы работы с сетью. Мне кажется получилось не плохо. А вот с предупреждениями конечно прогадал. Когда я готовил материал, мне казалось очевидным, что это далеко не рабочее решение.

Дженерики я не очень жалую если честно, я законченный адепт kiss. Если и реализовываю что-либо, то стараюсь делать это изолировано и под определенные задачи со строго определенным типом. Понятно, что без них не обойтись, но всегда стараюсь свести их количество к минимуму, но это уже мои сугубо личные предпочтения.

Обратите внимание, что Swift-овый нативный async/await, который сейчас доступен в iOS 15+, будет доступен в iOS 13+ в следующем релизе Xcode. И там всё это делается гораздо-гораздо проще.

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

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

UFO landed and left these words here

А Вы предисловие, читали перед подобным комментарием? Это код написан за 10 минут в информационных целях как наглядная демонстрация возможностей языка. Для новичков в разработке. Не более. Наглядно, быстро, по факту. Плюс я сам писал, что это костыли. Насколько было можно склеить воедино различные плюшки Swift, настолько я и склеил. Или вы предлагаете обернуть все в протоколы с расширениями, на дженериках и т.д. но тогда это уже будет не учебный материал. Перечитайте, будьте любезны.

Приветствую желание писать руководства для начинающих разработчиков.

Но что с кодстайлом? Это же очень тяжело читать. Вместо углубления в детали постоянно отвлекаешься на 100500 действий в одну строк, явный вызов init или разное количество пробелов в коде.

По запросу Swift Style Guide можно найти отличные примеры, как нужно, а как не стоит писать. И всегда спасает SwiftLint, ИМХО

Спасибо, я понимаю о чем Вы, мне сейчас тоже больно читать свое творение. Но оно, есть в том виде, в котором я его создал и править я его не буду. В какой-нибудь новой статье, да, это будет уместно, редактировать существующее - нарциссизм как по мне. В остальном согласен на 70-80%, код стаил конечно классная история, но разработка как правило, история про бизнес, а не про код. А бизнес предпочитает финансы и сроки. Отсюда небольшой тезис. Работающий код - не всегда красив, а красивый код - не всегда работает.

Sign up to leave a comment.

Articles