Вы не хотите привести сперва ваше описание MVVM, но продолжаете утверждать, что в статье про MVP. Не отвечаете на другие мои вопросы. Похоже, что вы просто хотите поспорить. Я этого делать не хочу. Давайте на этом закончим.
Назовите сколько вы знаете систем, где биндинг настраивается не в XML.
Назовите плюсы такого подхода.
В системах с биндингом через XML, как запустить анимацию на View или отобразить данные используя системный механизм отложенного выполнения типа handler.post()?
Как бы вы назвали то, что приходится и датабиндинг через xml писать и вызывать события иначе?
Где в статье я говорю про MVP кроме явных мест?
Просто иначе получается какой-то разговор ни о чем, уж простите.
Я рад обсуждать, но что мы обсуждаем мне не ясно.
Ниже я ответил Sterk. Прочтите, плиз.
В статье я не говорю, что проблемы эти только с андроидом связаны. Есть общие, а есть андроидные.
Databinding Library не дает всех тех инструментов, что WPF.
А то, что VM знает о View всего лишь одно из решений. Можно сделать шину данных. VM тогда не будет знать ничего о View. Но это не решит описанных проблем.
И еще раз, это проблемы не в том, что что-то невозможно реализовать. Это проблемы с тем, что это не красиво.
Во первых, спасибо Sterk за описание того, как устрокна работа на WPF. Я думаю это самая презентабельная система в плане MVVM.
Но для отдельных действий нам надо все же приходится писать code behind и вызывать его как-то. Не важно как, через eventAggregator (который как я понимаю представляет собой шину данных), либо напрямую через интерфейс вью (да, я понимаю это подход ближе MVP). Суть одна и та же.
А раз нам, помимо того, что мы биндим данные автоматом, надо как-то вызывать что-то руками (кидать события в шину данных, писать код их обработки во View), то возникает то, что я назвал "проблема двойственности". И я согласен, с этим можно жить. Но лично мне это не нравится.
… создаете список не отображенных ошибок. После события добавления View начинаете их выводить.
Согласен, так я и описал как можно это делать. Но это мне тоже не нравится. Так как приходится не просто сохранить VM как состояние View, а добавлять дополнительную логику (тот самый вызов списка ошибок) и поля (сам список ошибок).
И немного философии: Мне в MVVM как раз нравится то, что VM это набор полей отображающих состояние View. И когда надо добавлять в нее методы, тоже воссоздающие состояние, то красота и чистота VM пропадает.
Вы не хотите привести сперва ваше описание MVVM, но продолжаете утверждать, что в статье про MVP. Не отвечаете на другие мои вопросы. Похоже, что вы просто хотите поспорить. Я этого делать не хочу. Давайте на этом закончим.
Не хочу спорить в пустую.
Давайте так:
Просто иначе получается какой-то разговор ни о чем, уж простите.
Я рад обсуждать, но что мы обсуждаем мне не ясно.
Ниже я ответил Sterk. Прочтите, плиз.
В статье я не говорю, что проблемы эти только с андроидом связаны. Есть общие, а есть андроидные.
Databinding Library не дает всех тех инструментов, что WPF.
А то, что VM знает о View всего лишь одно из решений. Можно сделать шину данных. VM тогда не будет знать ничего о View. Но это не решит описанных проблем.
И еще раз, это проблемы не в том, что что-то невозможно реализовать. Это проблемы с тем, что это не красиво.
Во первых, спасибо Sterk за описание того, как устрокна работа на WPF. Я думаю это самая презентабельная система в плане MVVM.
Но для отдельных действий нам надо все же приходится писать code behind и вызывать его как-то. Не важно как, через eventAggregator (который как я понимаю представляет собой шину данных), либо напрямую через интерфейс вью (да, я понимаю это подход ближе MVP). Суть одна и та же.
А раз нам, помимо того, что мы биндим данные автоматом, надо как-то вызывать что-то руками (кидать события в шину данных, писать код их обработки во View), то возникает то, что я назвал "проблема двойственности". И я согласен, с этим можно жить. Но лично мне это не нравится.
Согласен, так я и описал как можно это делать. Но это мне тоже не нравится. Так как приходится не просто сохранить VM как состояние View, а добавлять дополнительную логику (тот самый вызов списка ошибок) и поля (сам список ошибок).
И немного философии: Мне в MVVM как раз нравится то, что VM это набор полей отображающих состояние View. И когда надо добавлять в нее методы, тоже воссоздающие состояние, то красота и чистота VM пропадает.