0

My problem might be related to this one:

Add footer to Android TouchListView

In the demo project of Commonware's touchlistview https://github.com/commonsguy/cwac-touchlist/blob/master/demo/src/com/commonsware/cwac/tlv/demo/TouchListViewDemo.java

A simple textview is added as footer which works OK. When I add my own instead, it breaks down when removing items. With 4 items initially, The footer stays at position 5 after removing any of the 4 items.

This is how I add the footer:

View footerView = ((LayoutInflater)getSystemService(Context.LAYOUT_INFLATER_SERVICE)).inflate(R.layout.footer_cloud, null, false);

This is the xml:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="64dip"
    android:gravity="center_vertical"
    >
    <ImageView android:id="@+id/add_icon"
        android:layout_centerInParent="true"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
                android:src="@drawable/ic_menu_add"
    />

    <ImageView android:id="@+id/cloudBG"
        android:layout_centerInParent="true"
        android:layout_width="230dp"
        android:layout_height="60dp"
        android:background="@drawable/cl"

    />


</RelativeLayout>

Adding debug to onRemove:

Log.d("tlv","count b4 remove "+adapter.getCount()+" aray: "+array.size());
            adapter.remove(adapter.getItem(which));

            //adapter.notifyDataSetChanged();
            Log.d("tlv","count after remove "+adapter.getCount()+" aray: "+array.size());

Shows that the adapter and array sizes are updated

I changed some code in the touchlistview.java to fix a crash when dragging an item below the lowest item:

Log.d("tlv","drag from "+mFirstDragPos+ " to "+mDragPos+" cnt "+ getCount());

                                                if(mDragPos < getCount()-this.getFooterViewsCount()){// Nino van Hooff: fix out of bounds
                                                    mDropListener.drop(mFirstDragPos, mDragPos);
                                                }else{
                                                    mDropListener.drop(mFirstDragPos, mDragPos-1);
                                                }
                                        }
                                        unExpandViews(false);

The getCount function always returns the same number (amount of items + 1 for footer), even after items are removed

Who know what the difference with my custom footer is?

Community
  • 1
  • 1
Nino van Hooff
  • 3,677
  • 1
  • 36
  • 52
  • Can you post a link to a full sample application that demonstrates the problems? You are probably encountering some limitations in `TouchListView` that I *may* be able to correct. – CommonsWare Sep 07 '11 at 15:41
  • Thanks for the quick reply! [link to full eclipse project](http://hooffzaken.nl/junk/baby_names.zip) – Nino van Hooff Sep 08 '11 at 00:36
  • Your project is very strange. It is as if you put your code in the `TouchListView` library project, which is certainly not the expected way of setting something up. I cannot get it to build in either Eclipse or via the command line. I will do some experimenting on this issue on my own as best I can. – CommonsWare Sep 08 '11 at 12:54

1 Answers1

0

While I cannot reproduce your problems, there are others. :-)

Even in the baseline code, if you remove a row from a TouchListView to which you applied a footer, you will get strange visual results. From a Hierarchy View standpoint, what appears to happen is that for each removed row, the footer is duplicated -- remove four rows, get four footers.

I have no idea why this is happening. TouchListView is oblivious to the ListAdapter that provides its contents. Perhaps that is the actual issue.

For the time being, I am going to have to officially not support having a footer and supporting remove modes at the same time. Either works individually, but not the combination. I will augment TouchListView to give a runtime exception if you try.

Eventually, TouchListView really needs a replacement. I might replace it in 2012 as part of my deeper exploration of touch events. Perhaps somebody else will come up with theirs. Since most of this code is just pulled from the Music app of the AOSP, I have limited ability to make repairs.

My apologies for not supporting this feature at the present time.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Sorry, edit restrictions, again:I feel this can still be fixed by forcing some update mechanism. Try this (your or my footer, doesn't matter): - start app - delete all rows by swiping --> the footer is at its initial position - suspend the app by pressing back button, returning to homescreen - resume app by selecting it from the apps list --> the footer is at its expected position ~So, somewhere in the suspending resuming, a part of an object is discarded and recalculated... but which, and can we enforce it? – Nino van Hooff Sep 08 '11 at 17:33
  • @Nino van Hooff: "I feel this can still be fixed by forcing some update mechanism." -- possibly. You are welcome to experiment and contribute a patch. Again, someday I can address this, but the fact that I'm working off of a largely foreign code base really hampers my ability to figure out what is going on. The code I pinched from the AOSP has "massive hack" written all over it, which is why I have simply focused on trying to provide a stable component, not necessarily with all possible features. Again, my apologies. – CommonsWare Sep 08 '11 at 17:37
  • I'll make some consessions. Thanks for your time. – Nino van Hooff Sep 08 '11 at 21:31