Managing activity from DialogFragment

Question

How can I call finish() and other non static methods from a DialogFragment in the activity that created it? I have tried passing messages from the OnClickLisener in the DialogFragment, to no avail.

I have a really simple app, conssting of a MainActivity and DialogFragment:

    public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle arg0) {
    super.onCreate(arg0);
    setContentView(R.layout.activity);
    showDialog();
}
public void showDialog() {
    DialogFragment newFragment = new ConfirmDialog();
    newFragment.show(getFragmentManager(), "dialog");
}

} And the Dialog is again very simple:

public class ConfirmDialog extends DialogFragment {
@Override
public AlertDialog onCreateDialog(Bundle savedInstanceState) {
    // Use the Builder class for convenient dialog construction
    AlertDialog.Builder builder = new AlertDialog.Builder(getActivity());
    builder.setMessage("Confirm you want to continue?")
           .setPositiveButton("Yes.", new DialogInterface.OnClickListener() {
               public void onClick(DialogInterface dialog, int id) {
                   //finish() MainActvity
                  }
               })
           .setNegativeButton("No.", new DialogInterface.OnClickListener() {
               public void onClick(DialogInterface dialog, int id) {
                 //Do nothing in MainActity
               }
           });
    // Create the AlertDialog object and return it
    return builder.create();
}

}

Answer 1

There are many options. One of them is define an interface with a single method inside.

1. Have the dialog caller implement that interface.
2. Keep a global variable pointing to the caller.
3. Set the variable in the onAttach(Activity activity) method.
4. Null that variable in the onDetach() method.
5. Call the variable (interface member) method in the onClick.

Example:

public class MainActivity extends Activity implements MyInterface { 
    // ...

    @Override
    public void onChoose() { finish(); }

}

And inside ConfirmDialog:

public static interface MyInterface {
    public void onChoose();
}

private MyInterface mListener;

@Override
public void onAttach(Activity activity) {
    mListener = (MyInterface) activity;
    super.onAttach(activity);
}

@Override
public void onDetach() {
    mListener = null;
    super.onDetach();
}

And then call mListener.onChoose() anywhere inside your class.

---

I know this has been marked as accepted, but I figured I could provide more feedback to the discussion.

A note about using or not interfaces. Andy's answer works just as right as mine, hence why I said "There are many options. One of them is...".

However, the reason why I prefer interfaces for this particular problem is because most of the times you're going to extend and reuse simple/common confirmation dialogs like that. hey are too generic to be "wasted" (or worse: duplicated if different event actions arise).

Unless you are deadly sure that you are going to use that only once, for one purpose (finishing), you generally should avoid hardwiring (and simplifying) the implementation details of the Activity in your dialog class. Flexibility, abstraction and efficiency. Less code to maintain.

And yes, there is a telltale that you may need that: the public keyword that you're using, especially if it's in a self-contained class file, which begs for reuse (too). Otherwise, you should be hiding that class inside your main Activity, since the implementation details (would) relate only to that one. Also, you would be removing the public keyword.

Yes, you could use for more than one Activity, but you'd be limited to finish()ing. The interface will give you flexibility to do whatever you want in each Activity. In other words, it's up to the implementer to define how it should itself behave for that event. You self-contain implementation details.

As a sidenote, what I do is create a package with all dialogs I may need for my application. For confirmation dialogs like that, I reuse for different messages and buttons. I provide defaults, but also allow for change using setArguments. And I keep the interfaces related so I don't need to create one interface for each dialog. The implementer responds according to which dialog triggered the "dialogs callback". Flexibility, abstraction and efficiency, all while avoiding things humorously called Hydra and Royal Family. So. In the end, like I said, many options. Don't over-engineer, but don't simplify too much too early (leave room for graceful expansion).

It's more important to understand advantages and pitfalls than choosing this or the other answer.