Рано закапывать Java

    image

    Много было сказано про «красоту» кода на Java, но на мой взгляд, главное — не инструмент, а умение им пользоваться. Под катом попытка написать декларативный DSL для вёрстки под Android даже не изобретая новый язык программирования!

    Вёрстка на Java всегда ассоциировалась у меня с болью.

    float dp = getResources().getDisplayMetrics().density;
    
    FrameLayout root = new FrameLayout(this);
    root.setBackgroundColor(RED);
    
    root.setLayoutParams(
            new ViewGroup.LayoutParams(
                    MATCH_PARENT,
                    (int)(100f*dp)));
    
    FrameLayout child = new FrameLayout(this);
    child.setBackgroundColor(GREEN);
    
    FrameLayout.LayoutParams childParams =
            new FrameLayout.LayoutParams(
                    (int)(50f*dp),
                    (int)(50f*dp));
    
    childParams.gravity = CENTER;
    
    child.setLayoutParams(childParams);
    
    root.addView(child);

    Результат:



    И дело даже не в том, что код выглядит страшно (а он страшный как чёрт). Основная проблема в том, что в нём невозможно не ошибиться. Я 3 раза перезаливал сюда этот код, в первый и второй разы наивно полагая, что смогу всё правильно написать сразу, и тщательно перепроверив всё лишь в третий. Скажете, что дело в моей невнимательности и будете правы, но если даже в такой простой вёрстке можно накосячить, то что уж говорить про что-то более сложное?

    Но почему с вёрсткой на Java всё так грустно? На мой взгляд основная причина — возможность верстать в xml и отсутствие инструмента для вёрстки на Java.

    Минусы xml


    Для меня их 3.

    Первый — оверхед.
    Зачем тратить ресурсы и без того не очень мощных устройств на Android на такие операции, как inflate и findViewById? На оптимизацию этих операций было потрачено много времени и сил, но они от этого не стали бесплатными.

    Второй — громоздкость.

    <FrameLayout
        android:background="#f00"
        android:layout_width="match_parent"
        android:layout_height="100dp">
    
        <FrameLayout
            android:background="#0f0"
            android:layout_gravity="center"
            android:layout_width="50dp"
            android:layout_height="50dp"/>
    
    </FrameLayout>


    Удручает необходимость дублировать тэги, писать перед каждым атрибутом «android:», а после вырабатывать частиную слепоту чтобы читать этот код.

    Третий — ограниченность языка.
    Допустим, я хочу сделать подпись к автару больше самого аватара на 10dp.

    <ImageView
        android:layout_width="@dimen/avatarSide"
        android:layout_height="@dimen/avatarSide"/>
    
    <TextView
        android:layout_width="@dimen/avatarSide + 10dp"
        android:layout_height="wrap_content"/>


    Но этого сделать нельзя потому что xml не поддерживает выражения.

    Почему не Anko?


    Anko — это DSL, с помощью которого можно декларативно описывать разметку на Kotlin.

    frameLayout {
    
        backgroundColor = RED
    
        frameLayout {
            backgroundColor = GREEN
        }.lparams(dip(50), dip(50)) {
            gravity = CENTER
        }
    
    }.lparams(matchParent, dip(100))

    Получаем все возможности полноценного языка программирования, лучшую производительность и даже не мучаемся с вёрсткой интерфейса на Java!

    Всё прекрасно, но, на мой взгляд, неприлично тянуть за собой целый рантайм языка при разработке библиотек. 500 кб — не так много для конечного приложения, но для библиотеки — явно перебор.

    JAnko


    Как оказалось, возможностей Java хватает чтобы верстать декларативно.

    new frameLayout(this) {{
    
        new lparams(this) {{
            width  = MATCH_PARENT;
            height = dip(100);
        }}._();
    
        backgroundColor = RED;
    
        new frameLayout(this) {{
    
            new lparams(this) {{
                width  = dip(50);
                height = dip(50);
                gravity = CENTER;
            }}._();
    
            backgroundColor = GREEN;
    
        }}._();
    
    }}._();

    Язык поддерживает блоки кода без названия. Они выполняются перед конструктором класса сразу после конструктора класса-родителя.

    class A {
        // block
        {
            // some code
        }
    }

    Именно эту возможность Java я использовал чтобы не писать название переменной, в которой лежит виджет для изменения каждого его свойства.

    Пример с аватаркой и подписью.

    new imageView(this) {{
    
        new lparams(this) {{
            width = dimen(R.dimen.avatarSide);
            height = dimen(R.dimen.avatarSide);
        }}._();
    
    }}._();
    
    new textView(this) {{
    
        new lparams(this) {{
            width = dimen(R.dimen.avatarSide) + dip(10);
            height = WRAP_CONTENT;
        }}._();
    
    }}._();

    Выглядит немного странно.



    Похоже на человека в монокле и оператор на scala. Но для proof of concept — вполне достаточно.

    Итоги


    0). На Kotlin код выглядит вот так:

    object : frameLayout(this) {
        init {
    
            object : lparams(this) {
                init {
                    width = MATCH_PARENT
                    height = dip(100f)
                }
            }.`_`()
    
            backgroundColor = RED
    
            object : frameLayout(this) {
                init {
    
                    object : lparams(this) {
                        init {
                            width = dip(50f)
                            height = dip(50f)
                            gravity = CENTER
                        }
                    }.`_`()
    
                    backgroundColor = GREEN
    
                }
            }.`_`()
    
        }
    
    }.`_`()

    1) Вес aar составляет 12кб
    2) Idea не сбивает форматирование
    3) Коду на Java иногда можно придать неожиданный для Java вид

    Репозиторий с библиотекой и примерами
    Бенчмарк

    Обычно чуть быстрее Anko, что забавно.

    Я ожидал, что моя мини-библиотека станет последним пристанищем этого монстра, но даже оттуда её выпилил в пользу Litho, который выполняет measurment и layout в другом потоке. Спасибо eirnym за ссылку.
    Закопать обратно?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 27
    • +3
      Первый — оверхед.

      А он точно есть?


      Кмк, верстать лучше на языке для верстки.

      • 0

        Нужно или дублировать объявление каждого виджета, или каждый раз проходить по всей иерархии вьюх в поисках нужного. Плюс неудобно когда объявление части вью находится в одном месте, а другая часть — в другом. Имхо, хорошо верстать на языке для вёрстки, если на нём действительно можно описать всю вёрстку.

        • +1
          В каком-то видео (вроде про Anko) говорили, что есть как минимум оверхед на парсинг xml. Попробую изучить вопрос
          • 0
            Еще какой оверхед, особенно при использовании MVP:
            1) Мы пишем всю верстку на XML, прописывая тонны параметров, и еще и IDшники.
            2) Потом мы в активити еще цепляем все это (и лучше через butter knife, а то уж больно много писать)
            3) Потом мы пишем интерфейсы, которые будут управлять состоянием
            4) Оверрайдим интерфейс в активити, где в методах уже пишем логику, которая будет изменять состояние объектов (буквы, цифры, возможности нажатия кнопок)
            5) И, наконец, уже в презентаре мы будет вызывать методы интерфейса.

            В 5 разных местах мы по чуть чуть пишем логику 1(!) экрана. Я с радостью выброшу хотя бы 1 пункт из списка, и вообще откажусь от XML.
          • +1

            Никто не говорит, что на Java нельзя написать DSLи. Можно и нужно, и эти DSL могут быть вполне годные с точки зрения декларативности и компактности, если не нужны будут арифметические операции. Но все равно выглядит это как костыль. Двойные скобочки, ._(); оператор new и не следование конвенции что имя класса должно быть с большой буквы, передача this в параметры — это мусор, от которого не удалось избавиться.


            Конечно намного лучше, чем без DSL вообще. Но на anko это смотрится органично и изящно, там сам язык оптимизирован под такие DSL.

            • +3

              Вобщем-то на Java ввиду особенностей языка как раз нельзя написать нормальный DSL. Лямбды немного улучшают ситуацию, но не сильно. В частности, проблемы возникают с описанием иерархической структуры и со ссылками на проперти (которые всегда будут не type-safe). Стандартрый способ — клепать билдеры, но с ними получается очень гормоздко. Поэтому практически всегда для описания структур используют сторонний язык типа XML.


              P.S. В Java 8 идентификатор _ объявлен как deprecated, а Java 9 вообще запрещает его использовать.

            • +1
              Ну вообще стандартный подход — код на Java, а верстку — на языке соответствующего шаблонизатора — XML лэйауты для андроида, Thymeleaf или Velocity для спринга и прочих вэб-приложений и так далее. Это удобно тем, что можно разделить код и представление, которые могут делать разные разработчики. Формировать лэйауты или вэб-страницы на Java возможно, но намного неудобнее.

              Зачем тратить ресурсы и без того не очень мощных устройств на Android на такие операции, как inflate и findViewById

              Можно так делать, а можно использовать databinding: https://stfalcon.com/ru/blog/post/faster-android-apps-with-databinding. Ну а то, что сам шаблон на XML, я не вижу в этом ничего такого фатального: большая часть рутинных операций верстки делается в визуальном редакторе той же студии, а непосредственно в коде лэйаута правится только уже какие-то небольшие вещи.
              • 0
                Язык поддерживает блоки кода без названия. Они выполняются по очереди сразу после конструктора.

                Блок инициализации выполняется ДО каждого конструктора (а по факту копируется в него)


                Как оказалось, возможностей Java хватает чтобы верстать декларативно.
                Class {{
                //blah blah
                }}


                Только вот DSL в Anko != созданию инстанса анонимного класса каждый раз при объявлении элемента в верстке. В итоге вместо того, чтобы тратить ресурсы и без того не очень мощных устройств на Android на такие операции, как inflate и findViewById, тратим ресурсы на загрузку 1000 и 1 анонимного класса в память.
                • –1
                  Спасибо, поправил. После конструктора родителя и перед конструктором самого класса.
                  • +2
                    А по поводу производительности, хороший вопрос, что затратнее: загрузка анонимного класса или обращение к ресурсу, которое является I/O операцией. Я пробенчмаркаю, когда появится минутка.
                    • 0
                      А загрузка анонимных классов это не I/O операции?
                      • 0

                        Нет. Вся прогрузка подобных классов, связанная с IO, происходит при старте. Так что максимум возможных затрат — это jit компиляция.
                        Т.е. в случае XML у нас будет IO + парсинг + выполнение, в данном случае — у нас просто выполнение (ибо байткод изначально сделан для удобства работы JVM, а не для чтения человеком, как xml)

                        • 0
                          Я считаю что подгрузка кода и подгрузка разметки этим кодом происходит при первом обращении к этому классу.
                    • 0
                      Добавил бенчмарки. Дублирую ссылку. https://github.com/a-dminator/anko_benchmark
                    • +3
                      Громкий заголовок с бестолковым содержанием. Нет серьезно, неужели на хайпе котлина будут писаться и одобряться подобные статьи?
                      • +2
                        На тему декларативного фреймворка для описания Android-интерфейсов, посмотрите на Litho.
                        • 0
                          Спасибо, действительно лаконично выглядит
                        • 0

                          С инициализатором по-умолчанию есть очень большая проблема, связанная с контекстом. Дело в том, что полученный объект будет тянуть весь контекст класса, в котором он был вызван. Другими словами, в примере ниже если передать myvar куда-либо еще за пределы класса MyActivity, то он потащит всё активити с собой, что повлечёт неизбежную утечку памяти. При ревью я сразу делаю reject, видя такой код, поскольку дальнейшие часы на отлов утечек памяти, будет намного дороже.


                          class MyActivity extends Activity {
                            private Class myvar = new Class {{ /* code */ }}
                          • +1
                            View, в любом случае, держит в себе контекст и ссылка на него даже не weak. Поэтому если передать View за пределы Activity, то это Activity неизбежно утечёт.
                            • 0

                              Согласен, хотя я больше про то, что люди любят так часто писать, инициализируя и другие классы.

                          • +1
                            Возьмите groovy, это уже стандарт как писать DSL на Java. Как пример, gradle на чистом groovy написан. Да у groovy побольше библиотека, но на нем можно и другие DSL сделать и он не заточен под одну задачу.
                            • +1
                              Что мне нравится в написании UI кодом — это всегда работающие code completion and navigation. Лямбды сильно улучшают компактность, но xml всё равно легче читается, хотя может дело в привычке.
                              • 0
                                Два момента. Первый момент: Google с Android Studio, как я понимаю, в сторону визуального создания интерфейсов (ConstraintLayout привет!). И идет оно туда (мы переходим ко второму моменту) для того что бы каждый занимался своим делом, дизайнеры рисовали интерфейсы а программисты реализовывали логику работы с ним. Это имхо.
                                • 0
                                  писать перед каждым атрибутом «android:»


                                  попробуйте посмотреть спецификацию xml Namespaces
                                  • 0

                                    Поддержу.
                                    Вместо 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 — разницы никакой. Проблему с выражениями это, конечно же, не решает.

                                    • 0
                                      А еще в IDEA/Android Studio прекрасный автокомплит, и вместо android:layout_height можно просто написать lh и нажать Enter. Так что проблема очень-очень притянута за уши.
                                  • +1
                                    Хочется сахорка? Держи:
                                    ui.frameLayout()
                                      .width(mathParent)
                                      .height(dip(100))
                                      .backgroundColor(RED)
                                      
                                      .child(x-> 
                                          x.frameLayout()
                                           .width(dip(50))
                                           .height(dip(50))
                                           .backgroundColor(GREEN)
                                           .gravity(CENTER)
                                       );
                                    

                                    И пожалуйста, не делай кастомизацию класса при создании объекта для сахарка (это я про двойные фигурные скобки), особенно на андроиде.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.