Ну тоже не очень хорошо. Но вообще, когда идет плата явно за страховку конкретной организации - это круто. У нас же мы платим в какой-то "общий котел". При этом почти независимо от размера зарплаты. А потом они что-то куда-то отправляют. И за медицину все нормальные люди все равно платят по второму разу. Про пенсии молчу вообще

Я как бы не против страховых взносов. Я хочу знать, кому я их плачу и за что

Разве Call там не тянет на контекст?

Да, вполне. Но он не наследуется

А там и можно всегда использовать контекст активити (если в этой активити находишься). Там дерево контекстов со своими скоупами, если в контексте чего-то нет, поиск отправляется в родительский. Всё там нормально сделано в этом разрезе. И смерть контекста активити вполне соотносится с пересозданием этой самой активити.

Ну вот мне тоже казалось, что там так и работает. Но давно это было

Ну то есть не всё там нормально сделано, конечно, и ContextWrapper — это слегка жесть, но это про детали реализации, а не про саму концепцию.

Вот сама концепция мне в свое время очень понравилась и я ее и утащил, немного допилив под себя

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

Ну и в свете вышесказанного как раз очевидно, что разные типы под апп контекст и активити контекст — это не к месту. Контексты в общем случае равнозначны. У контекста есть свой скоуп, где он актуален, и родитель, куда надо обратиться, если данных нет у себя. Не нужны тут разные типы на разные уровни.

Его и не надо использовать для DI, так как в ведре контексты не пытаются покрыть всё приложение, лишь концепты самого андроида — аппликейшн и основные типы компонентов. Возможно, если б там легко было создавать свои контексты, это было иначе. Но оно и хорошо, что у нас всё именно так сделано — почти все андроидщики понимают, что любой контакт с платформой надо держать на внешнем слое приложения, дабы весь остальной код от платформы не зависел никак.

Ну и да, для DI контекст не нужен, контекст нужен для SL.

Если SL - это service location, то в моем понимании, это частный случай DI

А еще контекст нужен для получения локализации, цветов и пр. Поэтому держать его только во внешнем слое в 99% случаев невозможно без тонны лишних тяжелых абстракций -)

Ну вот давайте представим, что можно было бы делать свои легковесные контексты и делать им переключаемых родителей, то есть можно, чтобы родительским контекстом был активити, если он живой и приложение, если он не живой. Круто же? Все автоматом резолвится куда надо. Хочешь что-то подменить, делаешь дочерний контекст, где заменяешь резолвер на то, что надо

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

Пока эти контексты прибиты гвоздями к android.jar, они даром не нужны в тестах и в мультиплатформе.

Само собой. Я про идею говорю. Если это просто легковесное API, типа интерфейса. Это работает отлично

Ну дык условный Koin примерно такое и делает, только модулями называет, а не контекстами.

Врятли. Будет много багов из серии "я запросил основной цвет темы экрана, но экран в тот момент пересоздавался поэтому и получил цвет из темы приложения, другой и чего-то не видно, фиг задебажишь"