Как стать автором
Обновить
3
0

Пользователь

Отправить сообщение

Как мы можем это исправить? :)

Во-первых, фреймворк создан был 5 лет назад, а заопенсоршен 3. Гораздо раньше, чем о Компоузе начали думать. Т.е это уже production-proven решение. Да, это проблема, что в маркетинг вкладывалось недостаточно усилий, и, например, на территории СНГ мало кто о нём слышал. Но предположение, что его никто больше не использует ошибочно – взгляните сюда для контекста: https://www.appbrain.com/stats/libraries/details/litho/litho


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


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

С кодогенерацией действительно возникают сложности удовлетворения контрактам – вместо фич языка (т.е прямо во время написания кода в IDE) вас будет ограничивать компилятор. Но это явные правила, ошибки с ними легко отлавливаются, т.к компилятор явно ругается (не нужно никаких линт-правил, Litho-процессор покрывает эти ситуации), однако за счёт этих контрактов и статических методов можно явно запретить пользователям ввести Состояние (поля класса, например) там, где не надо. Что при неправильном использовании, вызвало бы очень хитрые и трудноотлавливаемые ошибки при многопоточной обработке UI. Так что это меньшее из зол.


А для того, чтобы раньше отлавливать ошибки, не дожидаясь компиляции мы и работаем над плагином к IDE – он и методы правильно поможет описать, и ошибки подсветить прямо в IDE, и компоненты сгенерить без сборки всего приложения

  1. Т.к UI в коде, то можно написать стиль как метод, который получает Builder и проставляет нужные пропсы. Но также есть поддержка андроидных стилей, например, в Text.create() можно передать либо styleId, либо themeAttrId, и которых будут взяты значения TextAppearance и тд
  2. Litho — это JVM. А вот Yoga кроссплатформенная. Т.е измерения элементов и учёт их layout_props идёт через Йогу и будет одинаково работать на разных платформах. Она под капотом у Litho, ComponentKit, ReactNative и во многих других браузерных решениях
Поправка: не «все», а «принесённые из Java». А замечание верное — спасибо, поправим.
Про internal речь конкретно о том, что в Bytecode Viewer'е можно узнать реальное синтетическое имя публичного метода, которое вам не подскажет среда, несмотря на то, что он public.

Присмотритесь, стрелки так и идут — от подтипа к надтипу.
Планируем выкладывать все
Только он и был, но хотелось бы больше
ВКонтакте — это вообще кладезь. При выходе из той же переписки Up сработает как Back и покажет сперва каждый твой активный чат, прежде чем откроет-таки список чатов. Фантомные пропадания приложения из Recents тоже доставляют часто — нажал Back, приложение закрылось, в backstack'е нет — до свидания.
Google Play – отличный пример антипаттерна номер 6.
Действительно, куча вот таких вот особенностей может остаться за бортом, если изучаешь Python после C, Java или подобных. Как чуть было не получилось у меня.

Обязательно продолжайте.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Зарегистрирован
Активность