@MyDogTom8 июн 2015 в 13:33

Возврат результата выполнения из DialogFragment во Fragment минуя Activity

3 мин

33K

Android *

Из песочницы

Комментарии 15

@iamironz 8 июн 2015 в 15:14

А бывают ли реальные потребности отправлять события прямо во Activity? Может тогда и вызывать DialogFragment в самом Activity и имплементировать ему DialogFragment абстрактные методы?

@MyDogTom 8 июн 2015 в 17:08

А бывают ли реальные потребности отправлять события прямо во Activity?

К примеру, если UI реализован в Activity без использования Fragment.

Может тогда и вызывать DialogFragment в самом Activity и имплементировать ему DialogFragment абстрактные методы?

На сколько я понимаю, речь об анонимном классе. Я бы такой подход не использовал т.к я вижу всего один сомнительный плюс и два существенных минуса.
Сомнительный плюс: чуть меньше кода (не будет создания констант REQUEST_, не будет switch и не надо использовать intent).
Минусы:

Анонимный класс хранит ссылку на внешний класс. Как результат, усложняется задача по обработке пересоздания фрагментов т.к. помимо сохранения/восстановления собственных данных нам нужно будет еще и эту ссылку воостанавливать. Решаемо конечно, но уже усложнение и дополнительная возможность ошибиться.
Весь код будет в вызывающих activity/fragment, а значит повторно использовать DialogFragment уже нельзя.

@KamiSempai 8 июн 2015 в 19:02

На сколько я помню, при пересоздании анонимного диалог фрагмента выбрасывается исключение ClassNotFoundException. Так что это не просто сомнительно, а крайне не желательно.

@iamironz 9 июн 2015 в 06:03

На сколько я понимаю, речь об анонимном классе.

Нет, речь о абстрактном классе (не inner) DialogFragment, инстанс которого создается прямо в Activity по вызову такого же абстрактного метода во Fragment. Все эти абстрактные методы имплементируются на уровне инстанса, который нам надо слушать. По аналогии интерфейса.

@KamiSempai 9 июн 2015 в 08:55

Вы говорите, что это не анонимный класс, но то, что вы описываете и есть анонимный класс.
Если я правильно понял, вы имели ввиду вот такую реализацию:

DialogFragment dialog = new AbsDialogFragment() {
    @Override
    public void someAbstractMethod(String someString) {
        // Implementation ...
    }
};
dialog.show(getFragmentManager(), "ImplDialogFragment");

Это яркий пример анонимного класса.

@KamiSempai 8 июн 2015 в 16:28

Еще, для получения фрагмента, вызвавшего диалог, можно использовать метод getParentFragment(). Но для этого, при вызове диалога, нужно использовать ChildFragmentManager. Минус этого метода заключается в том, что для диалога нельзя будет установить setRetainInstance(true). Но как по мне так setRetainInstance(true) — это читерский прием, который может привести к кое-каким неприятностям в будущем, при уничтожении процесса.

@rude 8 июн 2015 в 17:57

Думаю этот подход лучше. Использую его везде.
Во все проекты добавляю что-то похожее на такой BaseDialogFragment

@MyDogTom 9 июн 2015 в 10:34

Считаю, что getParentFragment() хорош если у нас один вызывающий фрагмент и один вызываемый фрагмент (отношение один к одному). Если же у нас несколько вызываемых фрагментов (отношение один ко многим), то необходимо иметь возможность различить их с помощью getTargetRequestCode(), который устанавливается через setTargetFragment.

@KamiSempai 9 июн 2015 в 10:42

RequestCode можно и через аргументы передать. А еще в ответе можно возвращать Tag фрагмента. Так что путей идентификации масса.

@Ghedeon 8 июн 2015 в 20:34

Популярное решение для связей один-к-одному между фрагментами. К сожалению, не масштабируется на другие случаи вне фрагментов или когда нужно оповестить несколько компонентов системы. Как результат, чтобы не городить отдельную систему коллбэков для каждого отдельного случая, рано или поздно приходят к более универсальному event bus паттерну. Как бонус — объекты вместо intent.

@danikula 9 июн 2015 в 12:05

А я комбинирую вариант имплементации кастомного интерфейса и вариант с использованием методов setTargetFragment и getTargetFragment. Выглядит это так: хост-фрагмент (вызывающий диалог) имплементирует интерфейс-колбек, далее в диалоге он устанавливается как target-фрагмент, при возврате результата getTargetFragment кастится к интерфейсу и дергается колбек. Плюсы такого подхода перед описываемым — отсутствие необходимости упаковывать-распаковывать результаты в intent, более очевидный и чистый код.

@danikula 9 июн 2015 в 12:24

Полный код такого фрагмента тут
Он позволяет создавать как простые фрагменты-диалоги типа

new ConfirmDialogFragment.Builder(this)
    .title(R.string.menu_logout_confirm_dialog_title)
    .message(R.string.menu_logout_confirm_dialog_text)
    .show();

… так и более сложные с передачей диалог-тега (для идентификации конкретного диалога в колбеке), установкой стиля, передачи дополнительных данных (cookie), которые будут доступны в колбеке.

new ConfirmDialogFragment.Builder(this)
    .title(R.string.menu_logout_confirm_dialog_title)
    .message(R.string.menu_logout_confirm_dialog_text)
    .okButton(R.string.button_logout)
    .dialogTag("confirmLogout")
    .cookie("user", user)
    .destructive()
    .show();

Все это нормально переживает пересоздание активити.

@r_ii 9 июн 2015 в 12:30

Хорошее решение, но работает только, если оба фрагмента находятся в бек-стеке.
Если это не будет удовлетворено, то фрагмент менеджер упадет при изменении конфигурации (target not in fragment manager).

@kemsky 21 июл 2015 в 18:44

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

@Snakecatcher 10 янв 2016 в 21:51

Спасибо, тебе добрый человек, за статью.
Вчера пол-ночи возился с такой задачей.
Причем, раньше так делал — но напрочь забыл.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий