О пока тут такое вот, то интересно, а как наиболее

правильно реализовать создание DialogFragment в методе?

В каком смысле?

В том смысле, что будет довольно излишней конструкция типа "public class getDialogFragment extend DialogFragment" в моей самопальной недо-фабрике недо-билдере AlertDialog.

В каком смысле наследование это излишнее? Что то я вообще не понимаю, что ты хочешь 🤔

У класса название как у функции.

Метода 😏

Ой, всё 😁

Вот теперь я точно завпутолся

Напиши, что ты хочешь. DialogFragment это по сути фрагмент и работаешь ты с ним как с фрагментом.

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

Обёрточный цех хатю. Что бы у меня в одном месте создавался AlertDialog, а потом он оборачивался в DialogFragment и показывался.

А это все зачем 🙄?

Что-то ты там конкретно говнокодишь

Как вариант - сделать функцию, возвращающую AlertDialog, готовый к употреблению. Его оборачивать в Dialogfragment. Дешёво, сердито и можно использовать по отдельности.

Ну DialogFragment же куда лучше чем голый и страшный AlertDialog

Мне интересно, зачем??

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

Чтобы не было монолитного кода. Если хочется внутри AlertDialog.

Используй просто DialogFragment

Мне кажется, он просто, что-то не понимает. Ну или я.

Отнюдь. DialogFragment - это фрагмент со всеми своими неудобствами коммуникации с окружающим миром. AlertDialog со своими листенерами прост, как 5 копеек.

То есть всё же лучше оставить как есть и не выдумывать велосипед?

Работает - не трогай 😁 Если реально понадобится DialogFragment, тогда и используйте.

Если в диалоге нет сложной логики, зачем диалог фрагмент делать

Ты до конца не понимаешь, что ты хочешь. По факту ты хочешь впихнуть alertDialog в диалог фрагмент зачем? Если можно использовать их по отдельности, они выполняют одинаковые функции.

Однако есть нюанс. DialogFragment is lifecycle-aware, а AlertDialog - нет. То есть, если показан AlertDialog, а его активити или фрагмент закрывается, то будет крэш. Это можно обойти, завернув AlertDialog в lifecycle-aware код, который закрывает диалог на onDestroy родителя. Я себе так сделал, теперь ем и нахваливаю 😜

О, неплохая идея добавить реакцию AlertDialog на убитого родителя. Думаю топорное решение на if activity.isDestroyed() будет вполне достаточно. Благодарю вас за идею:)

Неа... Проблема именно в том, что про диалог забыли, а сам он не в курсе, когда нужно закрыться. Ему надо либо в onDestroy вызывать hide (т.е. хранить ссылку на диалог, а это не всегда удобно и вообще лишние телодвижения) либо заворачивать в lifecycle родителя и там вызывать hide на ON_DESTROY.

Порой, читаешь и думаешь "ну и говнокодер же я". А ведь и не программист совсем. Просто надо и все )))

страшно, вырубайте

Главное это желание развивать себя и свой продукт. Остальное ерунда же.

Ты главное когда говнокод пишешь не оправдывай это "главное верить в себя и развиваться!"

Воу, а ты че злой такой?

Да и ни один чел не развивается, если не верит в себя. Так что нифига не пустые слова, зря ты так.

В функцию, которая создаёт диалог, лучше передавать коллбэки на кнопки, а не завязывать его напрямую на конкретную активити или фрагмент. А то понадобится тот же самый диалог в другом месте - и привет, используем copy paste driven development 😁