private var mProgressBarController: ProgressBarController? = null

override fun onAttach(context: Context) {
     super.onAttach(context)

      if (context is ProgressBarController){
        mProgressBarController = context
       }
}


....

override fun onDetach() {

super.onDetach()

mProgressBarController = null
}

Чёт жоска, что мешает просто взять объявить публичный метод в Activity и во фрагменте написать
(activity as? YourActivity).showProgressBar()?

Ничего, можно и так)

А вдруг эта логика будет и в другой активти и один фрагмент может быть в 2х активити и тогда нужно менять код фрагмента на:
(activity as? YourActivity1).showProgressBar()
(activity as? YourActivity2).showProgressBar()

Утечка возникает тогда, когда дочерний элемент держит ссылку на родительский элемент, который живет должьше чем дочерний
То есть в твоем случае Activity может жить на протяжении всего приложения (например), а фрагмент может уничтожаться и создаваться в зависимости от перехода пользователя между экаранми или относительно твоей логики

Ну ёлки, эт чуть другой вопрос.

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

Хотя, зная себя, я бы бахнул общую абстрактную Activity и реализовал бы этот интерфейс там, и из фрагмента бы уже обращался как - нибудь типо (activity as BaseActivity).showProgressBar().

Или, имхо, чуть получше, пульнул бы в BaseActivity какую - нибудь progressBarliveData, и её бы из фрагментов мучил. Точнее, определил бы метод showProgress() в родительском абстрактном BaseFragment(да, люблю абстрактные классы, гоните меня, намехайтесь надо мной(( ), и его бы мучал ужо.

Я тоже люблю абстрактные классы.

Да, что то не подумал, что можно сделать:
(activity as? ProgressBarController).showProgressBar()

Тогда этот вариант по быстрее будет)

У viewpager2 уже можно ставить размеры в wrap content?

Пока все равно не понимаю, где утечка?)
Фрагмент уничтожится, активити уничтожилась, фрагмент пересоздался, новая ссылка на активити.
Фрагмент retain, отцепился от активити, активити пересоздалась - фрагмент держит ссылку на новую активити.

Мне нужно сделать что-то на подобии RecyclerView через ScrollView, при добавленни в начало новой View фокус переходит на него и ScrollView пролистывается вверх
Как сделать так, чтобы при добавлении новых View в начало списка scroll никуда не дергался?

Утечка возникает тогда, когда возникают циклические ссылки. Тут важно только это. Если объект ссылается на активити, но активити на него - нет, то все норм.
Пугают ссылками на активити в первую очередь по другим причинам: а) статические поля, тут вообще амба; б) если сменится контекст (например новая активити открылась, то она утечет, пока объект существует). Мне кажется, людям сложнее донести проблему взаимных ссылок, нежели просто напугать и сказть "низзя!" 😊

Не правда

GC умеет разрешать циклические ссылки
Например, если Вы будете хранить View внутри поля Activity (а View внутри держит ссылку на Activity), то утечки не произойдет

Обычные циклические ссылки GC вывозит так-то

Дело в достижимости от gc root

Если быть честным, то все дело в gc root

Я вообще не про фрагмент и вью. Ну да ладно

Но все же само утверждение было некорректное (как мне показалось)

Пойду вкурю, возможно GC в Андроиде для меня пока тайна 😊

Скажем так - стриггернуло. Работаю с несколькими языками. Больнее всего с языками с управлением памятью без сборщиков. strong, weak, unowned, shared и прочие указатели

В смысле блин, такой же как в обычной жабе

Да да, только надо уточнить что под дочерними классами имеются объекты анонимных классов и нестатических nested, так как и те и другие содержат неявно ссылку на родителя