自定义类的对话框在Android O中崩溃

Question

I often need user interaction (dialogs) from custom classes that aren't subclasses of Activity or Fragment. Here's an example of how I'm currently doing this. I open the dialog from the fragment manager of the fragment that created the custom class, and I use a small inner class as the target so I can get the dialog result. This keeps all the related code in one place, as opposed to putting onActivityResult in the parent fragment:

public class DocumentViewer extends RelativeLayout {

    public void deleteAnnotations() {
        DialogFragment dialog = new DialogFragment();
        Bundle args = new Bundle();
        args.putString("title", this.app.getString(R.string.DELETE_ANNOTATIONS));
        args.putString("message", this.app.getString(R.string.CONFIRM_DELETE_ANNOTATIONS));
        args.putString("button1Text", this.app.getString(R.string.BUTTON_DELETE));
        args.putString("button2Text", this.app.getString(R.string.BUTTON_CANCEL));
        dialog.setArguments(args);
        DocumentViewerAlertListener listener = new DocumentViewerAlertListener();
        listener.canvas = this.canvas;
        dialog.setTargetFragment(listener, R.id.confirmDelete);
        dialog.show(this.fragment.getFragmentManager(), "confirmDelete");
    }

    public static class DocumentViewerAlertListener extends ALFragment {
        public ALCanvas canvas;

        @Override
        public void onActivityResult(int requestCode, int resultCode, Intent resultData) {
            if ((requestCode == R.id.confirmDelete)&&(resultCode == 1)) {
                this.canvas.clearItems();
            }
        }
    }

}

Unfortunately, in Android O, the dialog.show line crashes with this stack trace:

09-20 14:06:12.852 24301-24301/com.bizname.appname E/AndroidRuntime: FATAL EXCEPTION: main
  Process: com.bizname.appname, PID: 24301
  java.lang.IllegalStateException: Fragment ALAlert{1ace4cd #8 confirmDelete} declared target fragment DocumentViewerAlertListener{7e21182} that does not belong to this FragmentManager!
      at android.app.FragmentManagerImpl.moveToState(FragmentManager.java:1209)
      at android.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1549)
      at android.app.FragmentManagerImpl.moveToState(FragmentManager.java:1611)
      at android.app.BackStackRecord.executeOps(BackStackRecord.java:807)
      at android.app.FragmentManagerImpl.executeOps(FragmentManager.java:2394)
      at android.app.FragmentManagerImpl.executeOpsTogether(FragmentManager.java:2189)
      at android.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManager.java:2142)
      at android.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:2049)
      at android.app.FragmentManagerImpl$1.run(FragmentManager.java:718)
      at android.os.Handler.handleCallback(Handler.java:789)
      at android.os.Handler.dispatchMessage(Handler.java:98)
      at android.os.Looper.loop(Looper.java:164)
      at android.app.ActivityThread.main(ActivityThread.java:6541)
      at java.lang.reflect.Method.invoke(Native Method)
      at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
      at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:767)

It makes sense that the fragment manager I'm using doesn't know about this inner class, but what's the alternative? I tried using the inner class as the fragment manager...

dialog.show(listener.getFragmentManager(), "confirmDelete");

...and there was no crash, but the dialog didn't appear, perhaps because the listener fragment is never displayed.

I'm open to either a quick fix for my current approach, or a different approach that accomplishes the same thing (but would prefer a quick fix!).

Answer 1

While writing out the question, I had an idea based on "the listener fragment is never displayed." I added this line before showing the dialog:

this.fragment.getFragmentManager().beginTransaction().add(listener, "confirmDelete").commit();

I assume this lets the fragment manager know about my listener fragment, so it doesn't throw the exception.

This seems like an easy and logical fix, but I'm still open to other approaches.