Разумно ли использовать Application класс как синглтон в пределах жизненного цикла приложения?

неплохо, я год 🙂

Круто, я 2,5)) но мне 20 только))) так а по поводу вопроса?)

потому что app context это контекст всего приложения, он используется для того, что юзается для всего приложения. например, для инициализации базы данных

Шанс схлопотать UB

спасибо вам огромное я сам в данное время учу с и хотелось бы под телефоны создавать приложухи просто вопрос такой был часть говорят котлин а другая чпсть джаву

ub?

Undefined behavior

ох уж эти сокращения

По умолчанию активности запускаются в спец контейнерах «в тасках». Одна таска отображается как один экран в разделе «недавние приложения» (где можно переключаться между ними). Чтобы знать в какой таске запуститься, нужно запускать от контекста, который уже связан с таской. Апп контекст не имеет такого инфо и ты словишь краш. Но можно явно указать флаг NEW_TASK и запустить с app context

Спасибо! На него как раз наткнулся ) годные туториалы

С Di ознакомьтесь

Смотря кого слушать.

Если тебе говорит человек что «так низяя!», и советует ди, то вероятно это не то что ты хочешь услышать

Но SOLID же)

И на нафиг! Классы утилитарные лежат как синглтончики)

Главное чтобы время жизни объекта контролировалось, и чтобы из-за этого не словить опять же UB

Если отдашь Application условному Hilt, проблем больших не будет, разве что с тестированием

А порождающий Application класс Context так вообще пример эталонного God-объекта, однако же пользуются и до сих пор есть
Activity myActivity = (MainActivity) getContext();

Ну в целом это и нормально, так сказать, делали бы по солиду, кодовая база разрослась в десятки раз)

Ну если модные di — койны всякие не используются — то этосамое удобное для добычи аппконтекста где угодно

Ну без, не так удобно, не зря придумали фреймворки внедрения зависимостей

главное чтобы человек понимал, как это самое di работает изнутри, а не тащил его «потому что сказали»

Свои наработки. Любые классы врапперы так называемые «ресурс провайдеры»

Это не так сложно, если уж честно, за тебя большинство обычно сделано

Так и происходит, многие даже его ни разу не настраивали), кто на работу уже пришел)

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

Ну, в новом проекте ещё модули настроить)

в том-то и дело, что за тебя все сделано) и потом говорят «как это ты не юзаешь нав компонент? ты что fragmentManager используешь? с коммитами этими?»

Нууу, нав компонент в маленьких проектах идеален
Без вложенности это прям шикарно

опять же, все это верно лишь в том случае, если ты понимаешь как он работает, читал доку и копался в сорцах

(но имхо концепция писать все в хмл и фрагменты соединять стрелочкой такое себе, чисто с эстетической точки зрения)

Наоборот это прекрасная концепция, и да, ты можешь писать навигацию и в коде, после того как стрелочки расставишь)

Мама я в телевизоре

Спасибо за ответ))

Потому что фрагмент не наследуется от контекста

Спс

зачем? почему именно requireActivity?

Ну или requerContext, у него я думаб все равно single activity