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.
> 
> However, my problem is a bit more complicated in that the abstract
>  class has multiple final fields of varying types.
> 
> 
> 

I'm not sure I understand the added complexity in your scenario, but I'm interpreting your issue as : I don't want to have a ton of arguments on my abstract constructor. One possible approach is to have a [Builder](http://en.wikipedia.org/wiki/Builder_pattern) for the abstract class that is used by the concrete sub classes. The builder is then 'passed up' to the abstract constructor for setting the final fields.