Два if/else, внутри одного из которых еще while, с if/else, внутри while...
Мне кажется на ревью такой код захотелось бы поделить на отдельные методы, уже сейчас крайне тяжело понять в какую из веток мы зайдем если выдадим какое то условие. Легко понять насколько высока сложность метода - попробуйте написать unit тест на нее без единого if
Также обязательно посмотрите на свое форматирование ошибок - оно плавает и в нем уже есть текстовые ошибки
Обычно делается тема приложения и она лежит на самом верхнем уровне (fragment/activity/composeview), а все контейнеры с конкретными compose экранами уже складываются внутрь неё В итоге получается что то вроде setContent { AppTheme() { ComposeScreen() } }
Где
setContent - выставление Compose контента
AppTheme с набором ресурсов приложения, привязанных к dark/light/fold
Compose screen - любой экран на Compose, тут в приложении будет скорее всего лежать NavHost
Когда меняется тема приложения - меняется AppTheme все Compose функции внутри неё, которые пользуются её dimens/colors/etc. получают сигнал о рекомпозии и перестраиваются. По идее то же самое должно происходить при изменении любой конфигурации устройства, включая складывание foldable устройства, но я пока не занимался поддержкой foldable на Compose и не могу дать точный ответ
Указано, что "Для сравнения, в Kotlin есть довольно быстрый фоновый KSP и его более современная замена kapt. В отличие от build_runner в Dart,с ними приятно работать" Но это KSP как раз более быстрый и свежии. Даже по указанным вами ссылкам можно прочитать, что kapt перешел в maintenance mode
romaan27 Спасибо большое за подробное объяснение. У меня к вам возник вопрос — может у вас есть красивое решение через паттерны или дженерики.
В данный момент бьюсь с собственной (пока не нашел готового решения) системой игровых событий, которая представляет из себя 'шину' EventBus, у которой есть очередь, в которую кладутся объекты, реализующие интерфейс IGameEvent, у которого есть всего пара методов вида getMessage, возвращающий строку и getHappened, возвращающий время создания события. Таймер в EventBus каждую секунду проверяет очередь и pop-ает оттуда события. При извлечении события используется шаблон Observer — любой класс может подписаться на событие извлечения эвента и получить экземляр этого IGameEvent от EventBus.
Вопрос в следующем. Поверх IGameEvent есть разные интерфейсы, расширяющие его. Например, существует IDayTimeEvent, имеющий (момимо message и time) информацию вида «Наступил день/ночь...» или IPaydayEvent, имеющий информацию вида «Получено 200 монет на счет». Приводит все к тому, что каждый подписавшийся на EventBus class получает все IGameEvent-ы и если он ждет какой то конкретный тип информации (ему не важно время дня или монеты, а важна другая информация) — ему приходится явно приводить пришедшие объекты к конкретным интерфейсам, что рушит весь смысл интерфейсовости очереди EventBus. Как думаете — может перенести этот кастинг в EventBus, чтобы она имела возможность разделять события по куче других Bus-ов, которые будут эммитить конкретный интерфейс или же вообще отказаться от этой концепции?
Немного пугает код
int main()Два if/else, внутри одного из которых еще while, с if/else, внутри while...
Мне кажется на ревью такой код захотелось бы поделить на отдельные методы, уже сейчас крайне тяжело понять в какую из веток мы зайдем если выдадим какое то условие. Легко понять насколько высока сложность метода - попробуйте написать unit тест на нее без единого if
Также обязательно посмотрите на свое форматирование ошибок - оно плавает и в нем уже есть текстовые ошибки
Обычно делается тема приложения и она лежит на самом верхнем уровне (fragment/activity/composeview), а все контейнеры с конкретными compose экранами уже складываются внутрь неё
В итоге получается что то вроде
setContent {AppTheme() {
ComposeScreen()
}
}
Где
setContent - выставление Compose контента
AppTheme с набором ресурсов приложения, привязанных к dark/light/fold
Compose screen - любой экран на Compose, тут в приложении будет скорее всего лежать NavHost
Когда меняется тема приложения - меняется AppTheme все Compose функции внутри неё, которые пользуются её dimens/colors/etc. получают сигнал о рекомпозии и перестраиваются. По идее то же самое должно происходить при изменении любой конфигурации устройства, включая складывание foldable устройства, но я пока не занимался поддержкой foldable на Compose и не могу дать точный ответ
Указано, что
"Для сравнения, в Kotlin есть довольно быстрый фоновый KSP и его более современная замена kapt. В отличие от build_runner в Dart, с ними приятно работать"
Но это KSP как раз более быстрый и свежии. Даже по указанным вами ссылкам можно прочитать, что kapt перешел в maintenance mode
В данный момент бьюсь с собственной (пока не нашел готового решения) системой игровых событий, которая представляет из себя 'шину' EventBus, у которой есть очередь, в которую кладутся объекты, реализующие интерфейс IGameEvent, у которого есть всего пара методов вида getMessage, возвращающий строку и getHappened, возвращающий время создания события. Таймер в EventBus каждую секунду проверяет очередь и pop-ает оттуда события. При извлечении события используется шаблон Observer — любой класс может подписаться на событие извлечения эвента и получить экземляр этого IGameEvent от EventBus.
Вопрос в следующем. Поверх IGameEvent есть разные интерфейсы, расширяющие его. Например, существует IDayTimeEvent, имеющий (момимо message и time) информацию вида «Наступил день/ночь...» или IPaydayEvent, имеющий информацию вида «Получено 200 монет на счет». Приводит все к тому, что каждый подписавшийся на EventBus class получает все IGameEvent-ы и если он ждет какой то конкретный тип информации (ему не важно время дня или монеты, а важна другая информация) — ему приходится явно приводить пришедшие объекты к конкретным интерфейсам, что рушит весь смысл интерфейсовости очереди EventBus. Как думаете — может перенести этот кастинг в EventBus, чтобы она имела возможность разделять события по куче других Bus-ов, которые будут эммитить конкретный интерфейс или же вообще отказаться от этой концепции?