Каковы плюсы и минусы привязки данных к андроиду?

Ответ 1

Сначала я прокомментирую ваши аргументы, а затем выскажу свое мнение:

1. Удалите шаблонный код - он удалит некоторые, просто переместит некоторые в xml или потребует дополнительных классов. Таким образом, вы должны быть осторожны и сбалансировать использование привязки данных.

2. Более высокая читабельность - зависит от того, являетесь ли вы новым разработчиком, вам может быть легко его освоить, но если вы ранее работали на Android, вам потребуется дополнительное время, чтобы изучить его.

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

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

5. Автоматически сгенерированный класс - это правда, он увеличит размер приложения, но опять же, только если у вас его будет много, это будет иметь значение. Это правда, что на веб-сайте android dev утверждается, что использование библиотек, создающих автоматически сгенерированный код, или annotations которые будут генерировать дополнительный код, является плохим.

6. Трудно отлаживать - зависит, как читаемость, от того, к чему вы привыкли, отладка чертовски трудна в любом случае для некоторых проблем, и вы поправитесь, отладив не используя другую библиотеку.

Так что это чисто мое мнение, я разработал много приложений с использованием разных библиотек и разных подходов, и у всех них были свои плюсы и минусы, но я усвоил то, что нужно: балансировать все, не использовать тонны библиотек, не тратить впустую время реализации вещей, которые уже реализованы и работают хорошо, не "разъединяйте все", не "соединяйте" все, не используйте только код, не пытайтесь "генерировать" все.

Я думаю, что это совершенно неправильно, и вы можете получить неверное представление, если спросите "за и против" в отношении какой-либо библиотеки/реализации, потому что обычно это не будет беспристрастным, вы получите много плюсов от того, кто использовал библиотека определенным образом, и она работала, и другие будут давать вам минусы, потому что они использовали разные, и это не сработало.

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

Обновление - 8 августа 2018 г.

Прежде всего, я все еще придерживаюсь своего первоначального заключения, баланс является ключом в подобных ситуациях, но в моем случае привязка данных немного ускорила процесс разработки, а также улучшила его. Вот несколько новых моментов, о которых вы все должны подумать.

1. Тестирование пользовательского интерфейса - с привязкой данных гораздо проще протестировать пользовательский интерфейс, но привязки данных недостаточно для этого, вам также нужна хорошая архитектура, и использование предложенной Google архитектуры покажет реальную силу привязки данных.

2. Наиболее заметные изменения были внесены в пункты 2 и 5 из моего первоначального ответа. После того, как мы решили использовать привязку к данным, читать код стало легче, и самое важное здесь: мы, как команда, решили, что будем использовать привязку к данным, и после этого мы ожидали получить большую часть тривиальная и базовая настройка пользовательского интерфейса в файле XML.

Что касается отладки, то здесь немного сложнее, Android Studio может значительно улучшить ошибки и автозаполнение для привязки данных, но наиболее распространенные ошибки вы получите после первых 2-3 случаев. Также я узнал, что "чистый проект" время от времени помогает ОЧЕНЬ МНОГО.

3. Еще один момент, который вы должны принять во внимание, это конфигурация проекта для использования привязки данных, сейчас AS (3.1) поддерживает привязку данных по умолчанию (просто установите флаг в graddle) для Java, но у меня были некоторые проблемы с Kotlin, после небольшого поиска здесь на SO, мне удалось все исправить.

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

Ответ 2

Даже если мне нравится ответ danypata, я хотел бы добавить/отредактировать некоторые его высказывания для привязки данных android.

1. Исключить код шаблона. Как написано в danypatas, он удаляет некоторый код и добавляет некоторый код где-то еще, как в макетах. Это не означает, что boilercode не уменьшается, потому что обычно он уменьшается.

Например, вы можете создать привязку для привязки, которая обрабатывает несколько пользовательских массивов для вашего spinner/recyclerview/listview/.. но для этого требуется только один простой адаптер. Вы можете использовать адаптер в своем макете, используя, например,

app:myCoolAdaptersData="@{model.mydata}"

Теперь вы можете создать свой общий адаптер и (повторно) использовать свой адаптер привязки во всех своих макетах вместо использования, например:

ListView lv = findViewById(...);
CoolGenericAdapter<MyModel> coolAdapter = new CoolGenericAdapter<>(...);
lv.setAdapter(coolAdapter);

Это всего лишь один простой пример, который отдает код в больших проектах. Еще один пример, чтобы передать код, заключается в том, что вы привязываете свою модель к вашему макету. Обновление значений полей вашей модели обычно также обновляет вашу модель (если это, по крайней мере, BaseObservable/ObservableField).

Это означает, что вам не нужно находить все ваши взгляды, обновлять свои взгляды, обновлять свои модели,...

2. Четкая читаемость. Дополнительное время, затрачиваемое на обучение привязке данных, действительно не имеет значения. Поскольку макеты не отличаются друг от друга, за исключением того, что вы вставляете их в тег макета и помещаете туда пространства имен, он действительно не отличается от "обычных" макетов. Использование bindadapters и доступ к модели в макете может занять некоторое время, но обычно вы можете начать с основ, которые легко и красиво использовать. Изучение нового материала всегда требует времени, но вы можете легко пересмотреть время использования привязки данных через некоторое время.

3.Powerful. Да, это очень мощный. Легче повторить использование существующего кода, повторно использовать существующие привязки и может привести к созданию более сгенерированного кода, но это не всегда верно. Например, вы можете создать несколько адаптеров в нескольких классах вместо создания одного адаптера привязки, его может быть сложно "оптимизировать" позже. Оптимизация Bindingadapter означает, что он обновляется повсюду. Оптимизация может уменьшить "строки кода", так как котельная все равно уменьшается.

Я согласен с 4. и 5.

6. Hard to Debug. Так как AS 3.0+ выводит полезные советы, такие как проблемы синтаксиса в вашем макете (номер строки и файл), его легко отлаживать сгенерированный код привязки данных. Если у вас возникли проблемы с поиском проблемы, вы также можете проверить наличие ошибок в сгенерированном коде. Некоторые библиотеки, такие как кинжал 2 или библиотека архитектуры Android, могут вас смутить, потому что строки ошибок не соответствуют реальной "ошибке". Это вызвано сгенерированным кодом другими обработчиками аннотаций. Если вы знаете, что эти обработчики аннотаций могут столкнуться с ошибками в выводах ошибок данных, вы можете легко исправить это.

7. Unit Testing. Это возможно, если вы не используете привязку данных с помощью executePendingBindings.

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

Еще одна очень большая проблема заключается в том, что bindingadapter может быть везде. Использование аннотации BindingAdapter генерирует код. Это означает, что использование этого в вашем макете может привести к проблемам, чтобы найти правильный код. Если вы хотите обновить привязывающий адаптер, вам нужно "найти" его.

Когда вы должны использовать что? Для больших проектов очень полезно использовать привязку данных вместе с шаблоном mvvm или mvp. Это действительно чистое решение и очень легко расширяется. Если вы просто хотите создать небольшое простое приложение, вы можете использовать шаблон MVC без привязки данных. Если у вас есть общие общие привязки, которые могут использоваться из других проектов, вы можете использовать привязку данных, потому что ее легко повторно использовать этот код.

Ответ 3

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

Ответ 4

Я работаю над огромным проектом Android, и команда решила отказаться от библиотеки привязки данных. Зачем? Основная причина заключается в том, что он увеличивает время сборки (10+ мин), генерируя большое количество классов в процессе сборки.