Лень писать тесты – это не проблема VIPER. У меня в кривой архитектуре с несоблюдением MVC даже Crash Free больше 99.5%. Проблема в поддержке такого кода.
На модули же разделяют не для того, чтобы потом сделать из них маленькие фреймворки и переиспользовать. А больше для того, чтобы легче было тестировать и отлаживать каждый слой в модуле. Проблема с UI? Значит ищем во View или презентере. И т.д. Знаем, в каком слое что искать.
По поводу «протоколы легко ломает бизнес логику и приводит к взаимоисключающим состояниям» не совсем понял. Довольно абстрактно без конкретного примера.
Проблему с роутером я решил в своей реализации. Она использует все родные механизмы. Но зато логику перехода смотрим в роутере. И не надо все это искать во вьюконтроллере.
По поводу дробления контроллера я абсолютно согласен. Про это и статья. Как разбить Massive View Controller.
Как понять, что контроллер, как был, так и остался? В VIPER ViewController это не контроллер, а View. В MVC от эппл это контроллер. Визуальное представление в VIPER разделяется на презентер с логикой отображения и самим отображением во View/ViewController. В VIPER больше слоев и ролей. Я в статье привел ссылку, где подробней сравниваются разные архитектуры.
Не совсем согласен, я больше года работал на проекте, который писали до меня больше 1,5 года 5 разных разных разработчиков и в разное время. 50+ экранов. Там не соблюдается даже элементарный MVC.
По-вашему, лучше так все и оставить? Или хотя бы пытаться перевести это на нормальную архитектуру, с разделением слоев? Я сам писал долгое время приложения, как попало. И они работают и приносят мне небольшой доход. Но сейчас понимаю, что их тяжело поддерживать из-за того, что криво написаны.
Спасибо за перевод.
Когда они там уже перестанут выкатывать каждый год новую версию, и можно будет хоть немного расслабиться? Неужели обязательно так часто выкатывать обновления на уровне языка? Не к вам вопрос, конечно. Просто мысли вслух.
А еще, когда ЭЦП выдают, то пароль ставят год рождения. Ну и еще куча уязвимостей при походе в наши ЦОНы (центр обслуживания населения) и при пользовании egov.kz
Вызовет ответные нарушения со стороны нападающих? Т.е. убивать нас простыми бомбами можно, а запрещенными нельзя? Может быть, проблема в том, что на нас нельзя нападать по этой женевской конвенции?
Моя мысль была в том, что если на меня нападают, то я могу использовать любые средства для своей защиты.
Допустим, вы маленькая страна, но у вас есть огнестрельное оружие. Вокруг вас много других стран, которые имеют средневековое оружие (копья, луки). По их женевским законам использовать в войне огнестрельное оружие нельзя. Все вокруг желают стереть вас и ваше население с лица Земли. Единственное, что вас защищает – это огнестрельное оружие. Сдаться без боя не вариант. Вас захватят и вырежут. Что вы будете делать?
Мне интересно другое. Допустим вы маленькая мирная страна, которая ни на кого не нападает. У вас есть кой-какое секретное оружие. На вас нападает другая сильная большая страна и воюет разрешенным женевской конвенцией оружием. Чтобы победить и защитить свою страну у вас есть это самое секретное оружие.
Но вот ведь беда. Оно запрещено женевской конвенцией. Т.е. мы дадим себя истребить и победить, но не будем использовать единственно возможный способ победить с помощью нашего секретного и эффективного, но запрещенного оружия. Я правильно все понял? Убивать других можно только разрешенным оружием, даже если на вас нападают?
background location mode вы имеет ввиду, что периодически у вас все же вызывается — (void)locationManager:(CLLocationManager *)manager didUpdateLocations:(NSArray *)locations {… }?
Я имею ввиду, что Вы просто описали каждую функцию и для чего она. Но начинающим не хватает какого-нибудь мало-мальски работающего приложения (небольшого), где уже НА ПРАКТИКЕ показали бы, как используется это unit-тестирование. Где был бы разобран каждый вид (Равенство базовых типов, Проверка на nil, Проверка на выбрасывание исключения и т.д.). Хотя, наверно, в рамках одной статьи такое тяжело написать. Надо маленькую книжку написать.
Никак не могу начать писать unit-тесты для своих приложений, потому что не могу понять вообще зачем оно мне и как, и для чего мне их писать. Именно на практике.
На модули же разделяют не для того, чтобы потом сделать из них маленькие фреймворки и переиспользовать. А больше для того, чтобы легче было тестировать и отлаживать каждый слой в модуле. Проблема с UI? Значит ищем во View или презентере. И т.д. Знаем, в каком слое что искать.
По поводу «протоколы легко ломает бизнес логику и приводит к взаимоисключающим состояниям» не совсем понял. Довольно абстрактно без конкретного примера.
Проблему с роутером я решил в своей реализации. Она использует все родные механизмы. Но зато логику перехода смотрим в роутере. И не надо все это искать во вьюконтроллере.
По поводу дробления контроллера я абсолютно согласен. Про это и статья. Как разбить Massive View Controller.
По-вашему, лучше так все и оставить? Или хотя бы пытаться перевести это на нормальную архитектуру, с разделением слоев? Я сам писал долгое время приложения, как попало. И они работают и приносят мне небольшой доход. Но сейчас понимаю, что их тяжело поддерживать из-за того, что криво написаны.
Когда они там уже перестанут выкатывать каждый год новую версию, и можно будет хоть немного расслабиться? Неужели обязательно так часто выкатывать обновления на уровне языка? Не к вам вопрос, конечно. Просто мысли вслух.
Моя мысль была в том, что если на меня нападают, то я могу использовать любые средства для своей защиты.
Допустим, вы маленькая страна, но у вас есть огнестрельное оружие. Вокруг вас много других стран, которые имеют средневековое оружие (копья, луки). По их женевским законам использовать в войне огнестрельное оружие нельзя. Все вокруг желают стереть вас и ваше население с лица Земли. Единственное, что вас защищает – это огнестрельное оружие. Сдаться без боя не вариант. Вас захватят и вырежут. Что вы будете делать?
Но вот ведь беда. Оно запрещено женевской конвенцией. Т.е. мы дадим себя истребить и победить, но не будем использовать единственно возможный способ победить с помощью нашего секретного и эффективного, но запрещенного оружия. Я правильно все понял? Убивать других можно только разрешенным оружием, даже если на вас нападают?
Глянул. Она еще в 2012 году была написана, в ней Xcode 4 и, вероятно, iOS 5 рассматривается.
Или это не помеха?
p.s. Скачал. На само приложение не делает ровным счетом ничего :-)
Я имею ввиду, что Вы просто описали каждую функцию и для чего она. Но начинающим не хватает какого-нибудь мало-мальски работающего приложения (небольшого), где уже НА ПРАКТИКЕ показали бы, как используется это unit-тестирование. Где был бы разобран каждый вид (Равенство базовых типов, Проверка на nil, Проверка на выбрасывание исключения и т.д.). Хотя, наверно, в рамках одной статьи такое тяжело написать. Надо маленькую книжку написать.
Никак не могу начать писать unit-тесты для своих приложений, потому что не могу понять вообще зачем оно мне и как, и для чего мне их писать. Именно на практике.