поздравляю, у вас нпе

скорее лишняя строка

но спасибо за ревью. Сейчас уберу ее

а, да (увидел сеттер)

а почему оно тоже не в конструктор инжектится? можно неправильно этот объект использовать и словить нпе, такого не надо

ну я же для себя писал. Поэтому везде пользуюсь правильно. Но в проекте побольше есть метод safeCall()

это ж устаревший привет, вот же актуальный
https://github.com/android10/Android-CleanArchitecture-Kotlin/

норм пример, не сферический конь, а как-раз с привязкой к андроиду

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

отличная поправка,спасибо ! :)

так как тут только 2 фичи, не хотел завозить safeCall(), когда буду наращивать функционал придется добавить
в плане технических реализаций не претендую на идеальное выполнение. Я лишь сказал, что тут архитектура правильно выполнена

хотя можно еще идеальнее выполнить:
выделить модули
выделить api-модули

https://gitlab.com/terrakok/gitlab-client  из описания

😊благодарю! Буду разбираться

Привет. Сорри, если уже было, киньте в меня ссылками, если что. :)
Как бы по вашему мнению бы следовало решать навигацию между экранами?
Нынешняя архитектура - мввм со стэйтами, навигация на основании состояния запускается через вью модели.
У коллеги возникла идея передвинуть переходы (через интерфейс, разумеется) на бизнес уровень, прям в юз кейс. Аргументирует это тем, что переходы между экранами/окнами на всех платформах, мол, одинаковые, это часть бизнес логики, куда после чего идти, а вьюмодел только стэйт пусть помогает отображать.

Моя же идея, если так хочется упростить вью модель, сделать какой-то отдельный ивент-бас для переходов, и редьюсер (например, вью модель, но не обязательно) может посылать отдельные ивенты куда когда идти.

А бизнес логике разве важно на каком экране что отображается?

Я понимаю, что, наверное, я только что изобрела велосипед, но всё же. :D

В том-то и дело, что все привыкли считать, что нет. Я тоже так считаю, спорим вот. С другой стороны, вью модели в идеале не должны ничего знать о других экранах. Вот и спрашиваю, интересно, как другие это решают. :)

роутинг является бизнес логикой, и как раз таки роутеры могут быть вынесены.