Как решили проблему с асинхронным кодом из-за Combine
Актуальный кейс с интересным решением. Только код асинхронный не из-за combine, а из-за реализации. Код мог бы быть синхронным и с combine.
Как мы решили проблему с асинхронным кодом из-за замыканий
Тоже самое. Так же бросаются в глаза фразы "задачи на background-потоке", при том что работаете вы с очередями.
Он заблокирует вызываемый поток до тех пор, пока все задачи на background queue не завершатся.
Это утверждение верно лишь до тех пор, пока этот вызов происходит в главной очереди (и на главном потоке соответственно). По-этому хотелось бы больше детерминированности в терминологии)
Может в вашем проекте не актуально, но так же можно было бы привести варианты тестирования кода который работает с таймерами.
Но вообще, по хорошему в тестах нужно стремится свести к нулю любую асинхронность. Для этого нужно концентрировать силы не на combine или queues, а на месте где она возникает. Как правило, это те самые зависимости которые вы заменяете заглушками.
Как с комбайном, так и с замыканиями тестовая реализация может оставаться синхронной. На мой взгляд это самый важный момент в поднятом вопросе, но вы об этом ничего не сказали.
Создавайте кнопку со стилем .system и задавайте background image для состояния .normal.
Анимация будет такая же как и сделали Вы.
> А откуда информация про 250 мс? Есть ссылка или что-то подобное?
В документации по Core Animation говориться, что длительность анимаций по умолчанию — 0.25 сек. Возможно для кнопки это и не так, но я предполагаю что длительность именно такая.
Читая статью, все ждал когда же начнется часть о продвижении и раскрутке…
Мы почти не вкладывались в маркетинг, надеялись, что будет органический приток игроков.
Стало искренне обидно после этой фразы.
Такие огромные усилия вложены в разработку и без маркетинга.
Повсюду твердят о том, что готовый продукт это даже не половина успеха, но тем не менее, все мы продолжаем наступать на те же грабли.
3 года это большая цена за подобный опыт. Надеюсь Вы сделаете правильные выводы и желаю Вам успехов в следующих проектах!
Как разработчик, скажу, что делать такие анимации сложно и долго. И все они очень затянутые. Стандартное время каких-либо анимационных эффектов на iOS — 250 мс. И плюс рекомендация от Apple — это проигрывание анимаций по ease-out кривой, т.е. вся основная анимация происходит за малую часть от основного времени, а остальное время — просто плавная догонка до нужного состояния…
В статье же приведены примеры с очень затянутыми анимациями. Нужно экономить время своих пользователей и в первую очередь предоставлять функционал, а не заставлять смотреть на красивые анимации.
Ваш DRHTableViewDataModelItem — это View Model — модель не содержащая в себе данных, а только их строковые представления, которая используется сугубо для конфигурации View.
DRHTableViewDataModel — фетчит данные (из сервера, я так предпологаю) и выполняет роль какого-то сервиса (название точно соответствует назначению?). И возвращает данные непосредственно во View. Как правило, в приложениях данные обычно кешируются — не хватает бд для их хранения (хотелось бы увидеть, что Вы будете хранить там, неужели DRHTableViewDataModelItem?)
По хорошему не хватает еще отдельного Data Source для таблички, контроллеру совсем не обязательно брать на себя эту обязанность (Вы же говорите про переиспользуемость). И именно датасорс мог бы взять на себя ответственность следить за изменениями в бд и предоставлению актуальных ViewModel для таблички.
А контроллеру бы оставили только то, что ему положено — обработка действия пользователя.
Хорошая тема затронута в статье, важная.
Актуальный кейс с интересным решением. Только код асинхронный не из-за combine, а из-за реализации. Код мог бы быть синхронным и с combine.
Тоже самое. Так же бросаются в глаза фразы "задачи на background-потоке", при том что работаете вы с очередями.
Это утверждение верно лишь до тех пор, пока этот вызов происходит в главной очереди (и на главном потоке соответственно). По-этому хотелось бы больше детерминированности в терминологии)
Может в вашем проекте не актуально, но так же можно было бы привести варианты тестирования кода который работает с таймерами.
Но вообще, по хорошему в тестах нужно стремится свести к нулю любую асинхронность. Для этого нужно концентрировать силы не на combine или queues, а на месте где она возникает. Как правило, это те самые зависимости которые вы заменяете заглушками.
Как с комбайном, так и с замыканиями тестовая реализация может оставаться синхронной.
На мой взгляд это самый важный момент в поднятом вопросе, но вы об этом ничего не сказали.
Анимация будет такая же как и сделали Вы.
> А откуда информация про 250 мс? Есть ссылка или что-то подобное?
В документации по Core Animation говориться, что длительность анимаций по умолчанию — 0.25 сек. Возможно для кнопки это и не так, но я предполагаю что длительность именно такая.
Тем что она выполняется не 250 мс а 400 мс?
Стало искренне обидно после этой фразы.
Такие огромные усилия вложены в разработку и без маркетинга.
Повсюду твердят о том, что готовый продукт это даже не половина успеха, но тем не менее, все мы продолжаем наступать на те же грабли.
3 года это большая цена за подобный опыт. Надеюсь Вы сделаете правильные выводы и желаю Вам успехов в следующих проектах!
В статье же приведены примеры с очень затянутыми анимациями. Нужно экономить время своих пользователей и в первую очередь предоставлять функционал, а не заставлять смотреть на красивые анимации.
DRHTableViewDataModel — фетчит данные (из сервера, я так предпологаю) и выполняет роль какого-то сервиса (название точно соответствует назначению?). И возвращает данные непосредственно во View. Как правило, в приложениях данные обычно кешируются — не хватает бд для их хранения (хотелось бы увидеть, что Вы будете хранить там, неужели DRHTableViewDataModelItem?)
По хорошему не хватает еще отдельного Data Source для таблички, контроллеру совсем не обязательно брать на себя эту обязанность (Вы же говорите про переиспользуемость). И именно датасорс мог бы взять на себя ответственность следить за изменениями в бд и предоставлению актуальных ViewModel для таблички.
А контроллеру бы оставили только то, что ему положено — обработка действия пользователя.