This is deliberate behavior of the FastScroller. When you call setAdapter on your ListView, the adapter is wrapped in a HeaderViewListAdapter if there are any headers set; this is why you must call addHeaderView before setAdapter. Then, in the FastScroller code, we see:

    if (adapter instanceof HeaderViewListAdapter) {
        mListOffset = ((HeaderViewListAdapter)adapter).getHeadersCount();
        adapter = ((HeaderViewListAdapter)adapter).getWrappedAdapter();
    }

That is, get an offset and use the underlying adapter. mListOffset is then used to set the top position to scroll to with the fast scroller. So where does this wrapping actually happen? Up to, as expected, ListView.addHeaderView, where we see:

    if (mHeaderViewInfos.size() > 0|| mFooterViewInfos.size() > 0) {
        mAdapter = new HeaderViewListAdapter(mHeaderViewInfos, mFooterViewInfos, adapter);
    } else {
        mAdapter = adapter;
    }

So we're definitely looking around the right place. Now, it sounds like your goal is to NOT have the offset behavior for list headers for your fast thumb, but otherwise have a normal list with header. To do this, it's sufficient (based on what we've seen of the code) to have FastScroller.mListOffset = 0. This is set only in getSectionsFromIndexer, which is called unconditionally in init, and conditionally in several other functions only when mListAdapter == null. mListAdapter is only null if onSectionsChanged gets called, so let's ignore that path for now.

After a lot of digging around, and playing with various reflection hooks, I can say that there's no way to do this that will be even slightly future-compatible. You can use reflection to swap out the HeaderViewListAdapter for one that lies about its header count, etc; but that's quite fragile. Similarly, you can subclass the (package visible) FastScroller with one with your own behavior; but mListOffset is referenced widely and not through a getter, so this is even uglier than usual. Basically, you're running up against the fact that the system doesn't work quite the way you want.

I hesitate to call this a bug, since it's so clear from the code that it's deliberate behavior. Have you considered making the first element of the list just a special first element (possibly using a custom WrapperListAdapter much like HeaderViewListAdapter if desired for book-keeping), rather than using the header mechanism?

Read More

1. Inflate any layout of your choice (this could be an XML of and ImageView with no drawable and with set height and width of your choice)
2. Measure the screen height and create new LayoutParams and set the height of it to 1/2 of the screen height
3. Set the new layout params on your inflated view
4. Use the ListView's addFooterView() method to add that view to the bottom of your list (there is also an addHeaderView())

Code to measure screen height

 WindowManager wm = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
 Display display = wm.getDefaultDisplay();
 int screenHeight = display.getHeight();

Code to set half screen height:

 View layout = inflater.inflate(R.layout.mylistviewfooter, container, false);
 ViewGroup.LayoutParams lp = layout.getLayoutParams();
 lp.height = screenHeight/2;
 layout.setLayoutParams(lp);
 myListView.addFooterView(layout);

An Aside: When you add a footer or header view to any listview, it has to be done before adding the adapter. Also, if you need to get your adapter class after doing this you will need to know calling the listview's adapter by getAdapter() will return an instance of HeaderViewListAdapter in which you will need to call its getWrappedAdapter method Something like this :

 MyAdapterClassInstance myAdapter = (MyAdapterClassInstance) ((HeaderViewListAdapter) myListView.getAdapter()).getWrappedAdapter();

Read More

Here's an implementation of ActionBarListActivity:

public abstract class ActionBarListActivity extends ActionBarActivity {

private ListView mListView;

protected ListView getListView() {
    if (mListView == null) {
        mListView = (ListView) findViewById(android.R.id.list);
    }
    return mListView;
}

protected void setListAdapter(ListAdapter adapter) {
    getListView().setAdapter(adapter);
}

protected ListAdapter getListAdapter() {
    ListAdapter adapter = getListView().getAdapter();
    if (adapter instanceof HeaderViewListAdapter) {
        return ((HeaderViewListAdapter)adapter).getWrappedAdapter();
    } else {
        return adapter;
    }
}
}

Just like regular ListActivity, you'll need a layout that contains a ListView with the ID android.R.id.list ("@android:id/list" in XML).

The spiel in getListAdapter() is to handle cases where header views have been added to the ListView. Seems like ListView sets its own adapter to a HeaderViewListAdapter, so we have to try and get the wrapped adapter to prevent casting errors.

Edit: Try adding this function to satisfy the need for onListItemClick:

protected void onListItemClick(ListView lv, View v, int position, long id) {
    getListView().getOnItemClickListener().onItemClick(lv, v, position, id);
}

Read More

Unfortunately you don't mention what Android version the error reports are coming from. However, looking at the source code, Android 2.1-update1 seems like a good candidate.

I'll just copy in the whole method to make things clear:

public boolean removeFooterView(View v) {
    if (mFooterViewInfos.size() > 0) {
        boolean result = false;
        if (((HeaderViewListAdapter) mAdapter).removeFooter(v)) { // <- line 274
            mDataSetObserver.onChanged();
            result = true;
        }
        removeFixedViewInfo(v, mFooterViewInfos);
        return result;
    }
    return false;
}

Now compare above removeFooterView(...) method with the implementation of a more recent platform:

public boolean removeFooterView(View v) {
    if (mFooterViewInfos.size() > 0) {
        boolean result = false;
        if (mAdapter != null && ((HeaderViewListAdapter) mAdapter).removeFooter(v)) {
            if (mDataSetObserver != null) {
                mDataSetObserver.onChanged();
            }
            result = true;
        }
        removeFixedViewInfo(v, mFooterViewInfos);
        return result;
    }
    return false;
}

As you can see, the've added in a couple of extra checks for certain members not being null. That would suggest that the first method will indeed fail on line 274 if mAdapter == null, whereas that wouldn't cause a crash with the newer implementation.

To work around it, all you probably need to do is add something like lv.getAdapter() != null before trying to remove the footer view.

Read More

Unfortunately you don't mention what Android version the error reports are coming from. However, looking at the source code, Android 2.1-update1 seems like a good candidate.

I'll just copy in the whole method to make things clear:

public boolean removeFooterView(View v) {
    if (mFooterViewInfos.size() > 0) {
        boolean result = false;
        if (((HeaderViewListAdapter) mAdapter).removeFooter(v)) { // <- line 274
            mDataSetObserver.onChanged();
            result = true;
        }
        removeFixedViewInfo(v, mFooterViewInfos);
        return result;
    }
    return false;
}

Now compare above removeFooterView(...) method with the implementation of a more recent platform:

public boolean removeFooterView(View v) {
    if (mFooterViewInfos.size() > 0) {
        boolean result = false;
        if (mAdapter != null && ((HeaderViewListAdapter) mAdapter).removeFooter(v)) {
            if (mDataSetObserver != null) {
                mDataSetObserver.onChanged();
            }
            result = true;
        }
        removeFixedViewInfo(v, mFooterViewInfos);
        return result;
    }
    return false;
}

As you can see, the've added in a couple of extra checks for certain members not being null. That would suggest that the first method will indeed fail on line 274 if mAdapter == null, whereas that wouldn't cause a crash with the newer implementation.

To work around it, all you probably need to do is add something like lv.getAdapter() != null before trying to remove the footer view.

Read More