ListView refresh problems

agustingimenez.1966agustingimenez.1966 USMember ✭✭
edited November 2015 in Xamarin.Forms

Since last update I'm having some problems with listview refreshing.

In some parts I use observable collections, these work flawless, but in others I use lists because the data changes integrally and there is where I'm having problems.

Y have something like this:

List<DataObject> items = new List<DataObject>();

void UpdateData(DataObject[] NewItems)
{

    listView.ItemsSource = null;
    items.Clear();
    items.AddRange(Newitems);
    listView.ItemsSource = items;
}

This code just fails, if the list had no items and the NewItems only has one item it does not refresh at all. I semi-solved it refreshing the ItemTemplate like this:

var template = listView.ItemTemplate;
listView.ItemTemplate = null;
listView.ItemTemplate = template;

But this fails some times, nearly works, but not always.

Is someone having these problems? Any workaround known?

Cheers.

Posts

  • NMackayNMackay GBInsider, University mod

    You could just use a new ObservableCollection to update the binding based on your list changes perhaps

    void UpdateData(DataObject[] NewItems)
    {
    
        listView.ItemsSource = null;
        items.Clear();
        items.AddRange(Newitems);
        listView.ItemsSource = new ObservableCollection<DataObject>(items);
    }
    
  • The problem is that list is used for more things, I need to preserve the instance and use just a list, not an observable collection.

    If no workaround arises I will rewrite the code to use the observable collection, but that code was working fine before the last update, so I wanted to know if there where something I can do without rewrite.

  • NMackayNMackay GBInsider, University mod

    I've done that before and it worked in 1.4.x okay although I think I used IList.

  • As I said, that code was working before the last update of Xamarin forms, so that must be a change or a bug.

  • JulienRosenJulienRosen CAMember ✭✭✭✭
    edited November 2015

    You should only ever bind to ObservableCollections.

    Keep your objects in a master list that is unrelated to binding.
    Bind your listviews once and only once to their OC, and never reset the items source.

    Clear your bound ObservableCollections (never null them) and repopulate them from your master list.

    Essentially, you need to seperate what your views need to operate vs. what your app logic needs internally to function properly.

  • But, why?

    Any bindable object in .net always allowed to use as datasource any IEnumerable, if these controls must use only observablecollections then the ItemsSource property should not allow to use an Object, it should be set as ObservableCollection instead.

  • JulienRosenJulienRosen CAMember ✭✭✭✭

    The problem is that list is used for more things, I need to preserve the instance and use just a list, not an observable collection.

    This is why. You have a master list that you are trying to use for both view and code behind purposes. Organize your code by having a master list accessible to code only, and populate your view collections via the master list.

  • Sorry but that has nothing to do with the problem, that's just a design pattern which one can decide to follow or not, MVVM, if the control allows to use any type of object as datasource it must work, else it has a bug.

  • JulienRosenJulienRosen CAMember ✭✭✭✭
    edited November 2015

    You are trying to find a solution to a problem that is solved by a good design pattern. Why not just do it the better way...

    You could even make all your collections lists, not observable collections, the issue is still that you should have a master list, and then build new lists to bind to, that you clear and repopulate.

    Unsetting a ListView ItemsSource at run time just to rebind it to a new list is a bad approach you should move away from.

  • TektonTekton USMember ✭✭✭

    If I'm not mistaken, changing the ItemsSource after setting it is also an active bug: https://bugzilla.xamarin.com/show_bug.cgi?id=25257

Sign In or Register to comment.