Учитывая что вы предполагаете один вечер на такого рода задание, что вы предполагаете в нем увидеть? Большинство людей работают на готовых проектах и даже при идеальном понимании архитектуры, вдумчиво воссоздать ее с нуля — дело требующее некоторого времени на обдумывание.
Накидать «абы как» лишь бы работало — да, можно и за вечер. Вдумчиво подойти к архитектуре, учесть корнер кейсы, написать хоть пару тестов — нуууу, я бы сказал дня 3 точно займет.
>Такая логика загромождает код и при некорректной имплементации может просочиться в релизную версию сборки
Подключенная Frida как-бы тоже рискует просочиться, но это уже дело вкуса.
Один из бенефитов вайпера, это упрощение тестирования компонентов за счет соблюдения solid ( как уже было скзаано выше). Как вы предполагаете тестировать ваши компоненты, если бОльшая их часть завязана на UIKit?
Я имел в виду следующее.
Нормальный поток данных: юзер нажал на кнопку. View через ViewModel сообщила наверх о событии. Произошли необходимые действия. Сверху поменяли ViewModel и она сообщила об изменении View.
Под сообщениями можно понимать прямые сообщения, байндинг или подписки на изменения.
Случай текстового поля: юзер что-то вводит в текстовое поле, текстовое поле _уже_ изменилось и после этого View оповещает ViewModel об изменениях. Таким образом не кто-то сверху ( Презентер) запрашивает изменения ViewModel, а View запрашивает их, т.к. по факту эти изменения уже произошли.
Для меня это выглядит как строго обратный поток данных. Поправьте меня, если я не прав.
Как будет работать данный подход в случае наличия на экране текстовых полей? Текстовое поле по определению изменяется юзером напрямую, соответственно в этом случае данные текут уже в другом напревлении.
По расходу позволю с вами не согласиться — двушка с кондеем, электроплитой и галогенками выходила максимум в 800 кВт, хотя все конечно зависит, но не скажу что мы особо экономили.
По ресурсу, если все так как вы говорие, то да — печаль. Но в таком случае, не более чем через 2 года мы увидим много недовольных обладателей.
Ресурс жизни аккумулятора или ресурс по емкости?
Если о жизни, то к сожалению не обалдаю данными и буду благодарен, если расскажете.
Если по емкости, то я беру за расчет среднемесячное потребеление в ~ 500 кВт, что составляет порядка 17 кВт в день.
Вопрос — В чем принципиальное отличие данного подхода от одной выделенной очереди (NSOperationQueue) с выставленным ограничением на число параллельных тасков? В чем бенефит своей очереди, планировщика и ранлупа?
Накидать «абы как» лишь бы работало — да, можно и за вечер. Вдумчиво подойти к архитектуре, учесть корнер кейсы, написать хоть пару тестов — нуууу, я бы сказал дня 3 точно займет.
Подключенная Frida как-бы тоже рискует просочиться, но это уже дело вкуса.
Да вроде давно уже работают
PS. С тем что XCode — это боль, всецело согласен.
Нормальный поток данных: юзер нажал на кнопку. View через ViewModel сообщила наверх о событии. Произошли необходимые действия. Сверху поменяли ViewModel и она сообщила об изменении View.
Под сообщениями можно понимать прямые сообщения, байндинг или подписки на изменения.
Случай текстового поля: юзер что-то вводит в текстовое поле, текстовое поле _уже_ изменилось и после этого View оповещает ViewModel об изменениях. Таким образом не кто-то сверху ( Презентер) запрашивает изменения ViewModel, а View запрашивает их, т.к. по факту эти изменения уже произошли.
Для меня это выглядит как строго обратный поток данных. Поправьте меня, если я не прав.
По ресурсу, если все так как вы говорие, то да — печаль. Но в таком случае, не более чем через 2 года мы увидим много недовольных обладателей.
Если о жизни, то к сожалению не обалдаю данными и буду благодарен, если расскажете.
Если по емкости, то я беру за расчет среднемесячное потребеление в ~ 500 кВт, что составляет порядка 17 кВт в день.
Usable Capacity: 13.5 kWh
Power: 7kW peak / 5kW continuous
Итого, для средней семьи двух wall-ов вполне достаточно.