0

I have this constructor in a class that extends AlertDialog.Builder

public CustomDialogBuilder(/*Irrelvant args*/)
    {
        super(context, R.style.AppTheme_Theme_Dialog_Alert);

        //...irrelevant init stuff

        setTitle("Name");
        setPositiveButton("Ok", positiveClick);
        setNegativeButton("Not Okay", negativeClick);


        this.listView = new ListView();
        this.adapter = new CustomListAdapter(listView);

        soundsListView.setAdapter(soundsListAdapter);
        soundsListView.setItemsCanFocus(true);
        soundsListView.setChoiceMode(ListView.CHOICE_MODE_MULTIPLE);

        soundsListView.setLayoutParams(new ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.MATCH_PARENT));
        setView(soundsListView);
    }

Inexplicably, this causes the following output from my getView overriden in CustomListAdapter.

Getting view at: 0
Getting view at: 1
Getting view at: 2
Getting view at: 3
Getting view at: 4
Getting view at: 5
Getting view at: 6
Getting view at: 7
Getting view at: 8
Getting view at: 9
Getting view at: 10
Getting view at: 0
Getting view at: 1
Getting view at: 2
Getting view at: 3
Getting view at: 4
Getting view at: 5
Getting view at: 6
Getting view at: 7
Getting view at: 8
Getting view at: 9
Getting view at: 10
Getting view at: 0
Getting view at: 1
Getting view at: 2
Getting view at: 3
Getting view at: 4
Getting view at: 5
Getting view at: 6
Getting view at: 7
Getting view at: 8
Getting view at: 9
Getting view at: 10

20 or more times. This is a massive bottleneck. It causes a solid 5+ seconds of lag when my Dialog is constructed. I can not optimize my getView method anymore as I am using a ViewHolder and it is a light method aside from reading a database row to make get the values for the ViewHolder.

As you can see, I am already setting the width and height to MATCH_PARENT to no avail as this post suggests.

Is there anyway to stop this excessive calling? It is a fairly large bottleneck in my app.

Community
  • 1
  • 1
Andrew No
  • 535
  • 6
  • 20
  • You shouldn't be doing any database transactions in `getView()`. – Mike M. May 09 '16 at 02:51
  • @MikeM. May I ask why? CursorAdapter seems designed to do exactly that. – Andrew No May 09 '16 at 02:54
  • 1
    The only thing you should be doing in the `getView()` method is inflating `View`s as necessary, and setting their properties from predetermined data. Anything else is going to lead to bottlenecks. There is no guarantee as to how many times `getView()` is called for any given position, nor in what order it will be called. You need to keep it as tight as possible. – Mike M. May 09 '16 at 03:01
  • That's funny. I just changed my system so that it didn't preload anything. This felt like better design as it would only load what it need in the dialog as it was requested. If what you're saying is true, which I assume it is, why did Google even make CursorAdapter? Is it not designed to work with lost view? – Andrew No May 09 '16 at 03:08
  • Well, yeah, that's what a `CursorAdapter` is for, but normally you don't override `getView()` in a `CursorAdapter`. The `newView()` and `bindView()` methods are usually what you implement. Also, if you're not doing a query inside the `Adapter`, then you're not actually doing a transaction, so we might be having a little terminology confusion, here. – Mike M. May 09 '16 at 03:16
  • @MikeM. I understand you. This seems like poor design on Google's part, to have getView called so many times. I wonder what the logic is behind this. As the lag I am having does not continue after my dialog is created and I can scroll very smoothly, the lag is not really under my control. – Andrew No May 09 '16 at 13:52

0 Answers0