从 DialogFragment 管理活动 [英] Managing activity from DialogFragment

查看:37
本文介绍了从 DialogFragment 管理活动的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如何从创建它的活动中的 DialogFragment 调用 finish() 和其他非静态方法?我曾尝试从 DialogFragment 中的 OnClickLisener 传递消息,但无济于事.

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.

我有一个非常简单的应用程序,由 MainActivity 和 DialogFragment 组成:

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();
}

}

推荐答案

有很多选择.其中之一是定义一个接口,内部只有一个方法.

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

  1. 让对话调用者实现该接口.
  2. 保持一个指向调用者的全局变量.
  3. onAttach(Activity activity)方法中设置变量.
  4. onDetach() 方法中将该变量置空.
  5. 调用onClick中的变量(接口成员)方法.
  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.

示例:

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

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

}

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();
}

然后在类中的任何位置调用 mListener.onChoose().

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).

除非你非常确定你只会使用它一次,为了一个目的(完成),你通常应该避免在你的对话框中硬连线(和简化)Activity 的实现细节班级.灵活性、抽象性和效率.需要维护的代码更少.

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.

是的,您可能需要一个告示:您正在使用的public关键字,特别是如果它在一个独立的类文件中,这也需要重用.否则,您应该将该类隐藏在您的主 Activity 中,因为实现细节(将)仅与那个相关.此外,您将删除 public 关键字.

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.

是的,您可以用于多个 Activity,但您只能使用 finish()ing.该界面将使您可以灵活地在每个 Activity 中执行任何您想做的事情.换句话说,由实现者来定义它本身应该如何针对该事件表现.您自包含实现细节.

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.

作为旁注,我所做的是创建一个包,其中包含我的应用程序可能需要的所有对话框.对于这样的确认对话框,我会重复使用不同的消息和按钮.我提供默认值,但也允许使用 setArguments 进行更改.而且我保持界面相关,所以我不需要为每个对话框创建一个界面.实现者根据哪个对话框触发了对话框回调"进行响应.灵活性、抽象性和效率,同时避免被幽默地称为 Hydra 和皇室的事情.所以.最后,就像我说的,有很多选择.不要过度设计,但不要过早简化太多(为优雅的扩展留出空间).

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.

这篇关于从 DialogFragment 管理活动的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆