Question: How can I reload a ListView from inside an AlertDialog? This AlertDialog is spawned by a ContectMenu.

```
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
    registerForContextMenu(getListView());
    ......
    MatrixCursor cursor;
    cursor = NameManager.getnameList();
    ........
    final SimpleCursorAdapter adapter = new SimpleCursorAdapter(this,
            R.layout.row, cursor, from, to);
    setListAdapter(adapter);
}
.......
.......
case R.id.delete:
            new AlertDialog.Builder(this)
            .setTitle("Delete " + cursor.getString(1))
            .setMessage("Are you sure?")
            .setPositiveButton("Ok",
                    new DialogInterface.OnClickListener() {
                @Override
                public void onClick(
                        DialogInterface dialogInterface, int i) {
                    try {
                        .......
                        // TODO reload listview

                    } catch (IOException e) {
                        e.printStackTrace();
                        return;
                    }
                }
            }).setNeutralButton("Cancel", null)
            .create().show();
            return true;

```

Answer: 
I would go with the second, "Have a really long superclass constructor." If we follow the approach detailed in the [question you referenced](https://stackoverflow.com/questions/2327509/abstract-class-with-final-uninitialized-field), the superclass constructor is `protected` and not meant to be called by anything external to the class hierarchy or package. My feeling always is, once something is not exposed beyond that boundary - i.e., is not part of the "API" as it were - then it doesn't matter what it looks like. Let it have eight different parameters of varying types, or even more. Yes, it's visible from within the package, but it's clear from the original solution that that constructor is not meant to be called by anything other than the subclasses. That's another motivation for non-`public` visibility. 

Of course, your instincts for doing something cleaner are correct when it comes to `public` stuff. The fact that you asked this question at all shows you have the right instincts.
Here's another alternative, assuming you have control of all the classes involved: abstract out the fields in the superclass and declare them in the subclasses, sort of like this...

```
abstract class SuperClass {
  abstract int[] getFooArray(); // not public!
  abstract int getBar();
}

```

and then just define the field in each of those subclasses, overriding the methods to return them.

Yes, it will involve some code duplication, but it could very well be cleaner in the end than an unreadably long constructor, and the code you're duplicating isn't very much -- a field, a one-line method to return that field.