Best practices: Layouts on Android (Programmatic vs XML)

Этот вопрос не дает мне покоя уже некоторое время. Я уже разработал пару приложений на платформе Android и почему-то всегда прибегаю к Java-коду для создания макетов. Приемлемо ли это в профессиональной среде разработки? Или XML-файлы должны быть обычным подходом? Обычно я нахожу XML более утомительным подходом, и часто эти макеты выглядят одинаково не на всех устройствах. Я просто не понимаю. С профессиональной точки зрения, кто-нибудь действительно мог разрабатывать приложения со сложными представлениями, используя только XML-файлы? Этот вопрос убивает меня, потому что Google рекомендует использовать XML, но пользовательский интерфейс никогда не выглядит одинаково на всех устройствах, если это не сделано программно. Или я делаю что-то не так?

Обратите внимание, что я имею в виду Android 2.2 и 2.3, которые использует большинство пользователей.

Я использую XML-макеты практически для каждого фрагмента и действия каждого приложения, которое я пишу. Я очень редко вижу необходимость создавать представления динамически, хотя настройку ListViews, отображение / скрытие представлений и т.д. Необходимо выполнять в коде. Для меня преимущества XML заключаются в следующем:

• Возможность использования редакторов макетов (Eclipse)


• Проще просматривать макеты


• Можно извлечь выгоду из автоматической локализации макетов


• Простое обслуживание различных параллельных макетов для разных устройств (экранов)


• Вы можете получить представление о макете, просмотрев его (проще, чем код)


• Легко разбивать макеты на части (фрагменты, включения и т.д.), Чтобы удалить дублирование


• Сохраняет разделение между визуальным дизайном и стоящей за ним функциональностью

Я не могу придумать никаких веских причин для помещения всех моих макетов в код - это звучит как ад.

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

OckhamsRazor,

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

... и почему-то всегда приходится прибегать к Java-коду для создания макетов. Приемлемо ли это в профессиональной среде разработки?

Да, это так. Android делает их доступными, так что вы можете делать именно это. Однако преимущества управления макетами с помощью XML включают стандартное разделение MVC, более простую отладку и более легкое изменение ресурса, если это необходимо. Кроме того, вы можете легко поддерживать несколько копий макетов в зависимости от конфигурации устройства.

... кто-нибудь действительно мог разрабатывать приложения со сложными представлениями, используя только XML-файлы?

Абсолютно! Есть несколько замечательных программ, которые полностью используют XML, а не программные представления. Ключом к ним является то, сколько информации (то есть нестандартных свойств представления) требуется от родительских представлений. Даже в таких случаях существуют способы передать эту информацию при условии, что вы знаете, где и как это сделать.

Или я делаю что-то не так?

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

• Нужна ли мне информация из родительских макетов, помимо свойств просмотра


• Нужно ли мне независимо от размера более чем одного элемента динамически изменять размер.


• Тип представления определен заранее или он тоже изменится?

Если ответом на 2 из 3 из них будет "да", я буду использовать некоторый уровень программной верстки. Если нет, я перейду на чистый XML. Как уже говорилось, программирование - это одна из тех профессий, которая поощряет изобретательность (при условии, что это безопасно), и практически все может быть достигнуто любым количеством способов. В конечном счете, я бы сказал, делайте все, что облегчает вашу работу по созданию качественных приложений.

Google дает свои рекомендации, основываясь на собственных знаниях программистов и их общих практиках. Они также создали платформу, поэтому знают, какие вещи и какими способами оптимизированы. Все зависит от опыта, и у каждого из нас он свой. Если у вас возникли проблемы с использованием XML, стоит потратить время на то, чтобы разобраться в причудах, просто чтобы использовать это как еще один инструмент. Кроме того, это даст вам информацию, необходимую для самостоятельного ответа на этот вопрос.

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

Надеюсь, это поможет,

FuzzicalLogic

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

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

Это действительно зависит от того, что это за проект или часть проекта, и к какому типу программистов вы относитесь. Некоторые люди просто предпочитают чистый код, в то время как другим нравится максимально использовать другие инструменты для проектирования.

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

Лично я предпочитаю делать все программно, и для меня это быстрее в разработке, чем написание XML с помощью созданных мной библиотек и классов. XML работает быстрее прямо из коробки.

Что касается производительности, то на самом деле нет никакой разницы, заслуживающей упоминания, если только вы не используете один и тот же вид так часто, в одно и то же время, что он больше не помещается на экране многократно. Я провел тест, сколько текстовых представлений Android может отображать на Moto X - Android 4.4, и он не смог превысить 5000, но для этого никогда не было цели. Если вы находитесь на этом этапе, вам либо нужно динамически загружать и выгружать данные, либо вы просто делаете что-то очень неправильное с самого начала.

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