Comments 27
Нужно или дублировать объявление каждого виджета, или каждый раз проходить по всей иерархии вьюх в поисках нужного. Плюс неудобно когда объявление части вью находится в одном месте, а другая часть — в другом. Имхо, хорошо верстать на языке для вёрстки, если на нём действительно можно описать всю вёрстку.
1) Мы пишем всю верстку на XML, прописывая тонны параметров, и еще и IDшники.
2) Потом мы в активити еще цепляем все это (и лучше через butter knife, а то уж больно много писать)
3) Потом мы пишем интерфейсы, которые будут управлять состоянием
4) Оверрайдим интерфейс в активити, где в методах уже пишем логику, которая будет изменять состояние объектов (буквы, цифры, возможности нажатия кнопок)
5) И, наконец, уже в презентаре мы будет вызывать методы интерфейса.
В 5 разных местах мы по чуть чуть пишем логику 1(!) экрана. Я с радостью выброшу хотя бы 1 пункт из списка, и вообще откажусь от XML.
Никто не говорит, что на Java нельзя написать DSLи. Можно и нужно, и эти DSL могут быть вполне годные с точки зрения декларативности и компактности, если не нужны будут арифметические операции. Но все равно выглядит это как костыль. Двойные скобочки, ._(); оператор new и не следование конвенции что имя класса должно быть с большой буквы, передача this в параметры — это мусор, от которого не удалось избавиться.
Конечно намного лучше, чем без DSL вообще. Но на anko это смотрится органично и изящно, там сам язык оптимизирован под такие DSL.
Вобщем-то на Java ввиду особенностей языка как раз нельзя написать нормальный DSL. Лямбды немного улучшают ситуацию, но не сильно. В частности, проблемы возникают с описанием иерархической структуры и со ссылками на проперти (которые всегда будут не type-safe). Стандартрый способ — клепать билдеры, но с ними получается очень гормоздко. Поэтому практически всегда для описания структур используют сторонний язык типа XML.
P.S. В Java 8 идентификатор _ объявлен как deprecated, а Java 9 вообще запрещает его использовать.
Зачем тратить ресурсы и без того не очень мощных устройств на Android на такие операции, как inflate и findViewById
Можно так делать, а можно использовать databinding: https://stfalcon.com/ru/blog/post/faster-android-apps-with-databinding. Ну а то, что сам шаблон на XML, я не вижу в этом ничего такого фатального: большая часть рутинных операций верстки делается в визуальном редакторе той же студии, а непосредственно в коде лэйаута правится только уже какие-то небольшие вещи.
Язык поддерживает блоки кода без названия. Они выполняются по очереди сразу после конструктора.
Блок инициализации выполняется ДО каждого конструктора (а по факту копируется в него)
Как оказалось, возможностей Java хватает чтобы верстать декларативно.
Class {{ //blah blah }}
Только вот DSL в Anko != созданию инстанса анонимного класса каждый раз при объявлении элемента в верстке. В итоге вместо того, чтобы тратить ресурсы и без того не очень мощных устройств на Android на такие операции, как inflate и findViewById, тратим ресурсы на загрузку 1000 и 1 анонимного класса в память.
Нет. Вся прогрузка подобных классов, связанная с IO, происходит при старте. Так что максимум возможных затрат — это jit компиляция.
Т.е. в случае XML у нас будет IO + парсинг + выполнение, в данном случае — у нас просто выполнение (ибо байткод изначально сделан для удобства работы JVM, а не для чтения человеком, как xml)
писать перед каждым атрибутом «android:»
попробуйте посмотреть спецификацию xml Namespaces
Поддержу.
Вместо android: можно выбрать префикс покороче (например, a:), либо вообще установить пространством имён по умолчанию (тогда префиксы не понадобятся):
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" ...>
<LinearLayout xmlns:a="http://schemas.android.com/apk/res/android" ...>
<LinearLayout xmlns="http://schemas.android.com/apk/res/android" ...>С точки зрения XML — разницы никакой. Проблему с выражениями это, конечно же, не решает.
ui.frameLayout()
.width(mathParent)
.height(dip(100))
.backgroundColor(RED)
.child(x->
x.frameLayout()
.width(dip(50))
.height(dip(50))
.backgroundColor(GREEN)
.gravity(CENTER)
);
И пожалуйста, не делай кастомизацию класса при создании объекта для сахарка (это я про двойные фигурные скобки), особенно на андроиде.
Рано закапывать Java