Во-первых, фреймворк создан был 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, и компоненты сгенерить без сборки всего приложения
Т.к UI в коде, то можно написать стиль как метод, который получает Builder и проставляет нужные пропсы. Но также есть поддержка андроидных стилей, например, в Text.create() можно передать либо styleId, либо themeAttrId, и которых будут взяты значения TextAppearance и тд
Litho — это JVM. А вот Yoga кроссплатформенная. Т.е измерения элементов и учёт их layout_props идёт через Йогу и будет одинаково работать на разных платформах. Она под капотом у Litho, ComponentKit, ReactNative и во многих других браузерных решениях
Про internal речь конкретно о том, что в Bytecode Viewer'е можно узнать реальное синтетическое имя публичного метода, которое вам не подскажет среда, несмотря на то, что он public.
Присмотритесь, стрелки так и идут — от подтипа к надтипу.
ВКонтакте — это вообще кладезь. При выходе из той же переписки Up сработает как Back и покажет сперва каждый твой активный чат, прежде чем откроет-таки список чатов. Фантомные пропадания приложения из Recents тоже доставляют часто — нажал Back, приложение закрылось, в backstack'е нет — до свидания.
Действительно, куча вот таких вот особенностей может остаться за бортом, если изучаешь Python после C, Java или подобных. Как чуть было не получилось у меня.
Как мы можем это исправить? :)
Во-первых, фреймворк создан был 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, и компоненты сгенерить без сборки всего приложения
Text.create()можно передать либо styleId, либо themeAttrId, и которых будут взяты значения TextAppearance и тдПрисмотритесь, стрелки так и идут — от подтипа к надтипу.
Обязательно продолжайте.