Issues with ReactiveLists and Xamarin Forms ListView showing new items

[PureWeen]

I have a Xamarin Forms project with a ListView bound to a ReactiveList... After a web call I saturate the list with items... On Android it works great and the items show up but on iOS it doesn't work....

I'm pretty positive it has something to do with the thread the items are being added from because if I add an item in the constructor of the view it shows up but then no subsequent items show up...

I've tried a bunch of scenarios but here's one I thought was interesting:
If I create an ObservableCollection, bind that to the ListView, then subscribe to the CollectionChangedEvent on the ReactiveList, then add items to that ObservableCollection as items are added to the ReactiveList then items show up..... If I change that same ObservableCollection to a ReactiveList then the items no longer show up

Hopefully that makes sense...

It's actually kind of frustrating because I've been trying to create the problem in a smaller project to send you but for some reason in that project everything works super :-(

I've tried as many different permutations of awaits/tasks/ObserveOns that I can but each project doesn't want to budge with how it works/doesn't work on iOS

If that all doesn't trigger anything I can probably take the defunct project and strip things away until I hopefully have something reproduceable... But I was just curious if something in there sounded familiar...

[detroitpro]

👍 I am running into the same problem.

[chillbythewater]

The problem is with the ListView not refreshing the layout (at least in my case). The items are added to the ListView but they don't appear until you do something like rotate the device. See: http://forums.xamarin.com/discussion/18631/listview-binding-to-observablecollection-does-not-update-gui
I tested this using a ReactiveList instead of an ObservableCollection and sure enough there are the missing items.

[PureWeen]

Alright I think I was able to create an extremely contrived example that seems to demonstrate the behavior (I realize the clearing of the list makes no sense but it's needed to recreate the behavior in this App)

https://github.com/PureWeen/XamarinFormsiOSListViewReactiveList

--code behind adding to the Lists
https://github.com/PureWeen/XamarinFormsiOSListViewReactiveList/blob/master/TheApp/TheApp/Page.xaml.cs

So when I run this project on iOS the ListView bound to the ReactiveList stops displaying items that have been added after the 4th item .... When I run this same project on Android the ListView keeps displaying added items.

 //uncomment this to use an ObservableCollection instead and the items will show up in the list
            //without a problem
            //ObservableCollection<Monkey> Monkies = new ObservableCollection<Monkey>();
            ReactiveList<Monkey> Monkies = new ReactiveList<Monkey>();

If I replace the ReactiveList with a straight ObservableCollection then on iOS the ListView keeps displaying added items

If I remove the async/await from the subscribe

 await new SomeLibrary.Class1().SomeMethod();

Then it works fine on iOS as well

[chillbythewater]

Well re the
await new SomeLibrary.Class1().SomeMethod();
You are awaiting a non async method. Should be:

 public async Task<string> SomeMethod()
        {
            HttpClient client = new HttpClient();
            return await client.GetStringAsync("http://www.google.com");        
        }

[PureWeen]

At the risk of derailing the intent of this thread :-) That's not true you await TASKS not "async methods"... Marking a method async just indicates to the compiler that this method is going to awaiting something so it's telling the compiler to compile the method using a state machine.. So that it can suspend and resume etc....

http://blogs.msdn.com/b/pfxteam/archive/2012/04/12/async-await-faq.aspx
"You’re telling the compiler that you want to be able to use the “await” keyword inside the method (you can use the await keyword if and only if the method or lambda it’s in is marked as async). In doing so, you’re telling the compiler to compile the method using a state machine, such that the method will be able to suspend and then resume asynchronously at await points."

all await is is the developer indicating ok I've reached a point in the code where now I need the result from this Task... That task may have been running to completion this whole time or it might not even have started running until you call await..

So in your rewrite the only difference is that you are awaiting the state machine inside the method where as the original code is initiating the state machine outside of the method... Which in this case it's basically the same thing. AND actually some might argue it's not a good idea to await inside methods like that because then you aren't giving the implementer the choice of when to execute the task...

For example in the HttpClient library... None of the methods even start executing until you call await because none of them initiate the tasks when you call them... This allows the developer to decide when the actual tasks are going to be executing opposed to having them just execute right when you get the task back

[chillbythewater]

Yeah I didn't go too much into the semantics, just immediately applied the "async all the way" principle. Either way my rewrite worked fine for me. ListView updated and continued to do so.

[PureWeen]

I don't think "async all the way" means "await" all the way .... I'm pretty sure it applies to "Don’t mix blocking and async code"
https://msdn.microsoft.com/en-us/magazine/jj991977.aspx
So in SomeMethod if I did

client.GetStringAsync("http://www.google.com").Wait();
//or
client.GetStringAsync("http://www.google.com").Result;

Then I violated async all the way. Just returning the Task doesn't make it blocking.

Either way I removed it from the sample to simplify the contrived sample and just awaited the HttpClient call itself.

The main detail I find interesting is that if I use an ObservableCollection it works but with a ReactiveList it doesn't

And thanks for pulling down the sample and running it :-) Really appreciate that!!

[chillbythewater]

These debates have all been done to death in many forums. My interpretation of Stephen Cleary's suggestions re async all the way is to write the code using async/await where possible. And per Paul Bett's advice re using Observable.Start instead of Task.Run etc. It all seemed to work for me on IOS. Rather than try to work out the semantics I've just used a more "natural" style. I'll run again later to verify.

[chillbythewater]

ReactiveList has an optional parameter in the constructor for a scheduled. If you omit it will default to main thread so all the observables should fire on the UI thread.

[chillbythewater]

Apologies. Missed the point a little with your comment re removing the async/await and it working. Indeed the reactivelist ListView stops responding at some point. I added the threadId to see what was being used in the events. With the async in the subscribe the thread does change. Change the async execution to the following:

System.Reactive.Linq.Observable.Interval (TimeSpan.FromSeconds (5))
                .SelectMany (async _ => {
                return await new SomeLibrary.Class1 ().SomeMethod ();
            })
                .SubscribeOn (RxApp.MainThreadScheduler)
                .Subscribe (x => {


                //var there = Monkies.ToList();
                //Monkies.Clear();
                //there.ForEach(y => Monkies.Add(y));

                Monkey george = new Monkey () { Name = string.Format ("Jungle{0}", i) };

                Monkies.Add (george);
                Console.WriteLine ("MOnkey added {0} to ReactiveList threadid {1}", i, Thread.CurrentThread.ManagedThreadId);
                i++;
            });

I also commented out the Monkies.Clear as it causes an exception in IOS sometimes. Unfortunately you have to remove each item in a loop. The above seems to work fine.

[PureWeen]

Rabble!! Rabble!! Rabble!! Rabble!! Rabble!! Rabble!! :-)

So I just want to emphasize "contrived" ... My main application doesn't use Clear or really look like this.. in fact my main application no longer uses Xamarin Forms and I have all of this working swimmingly with a ReactiveTableViewController.... I had posted this issue and felt responsible for trying to provide something useful to recreate beyond an anecdote... So one day during a particularly riveting gotomeeting I came up with this.

So yea....

It's really less about how to make this sample work and more about demonstrating the difference in behavior between two collections that seem like they should have the same affect on a ListView control... Observable Collection works great and Reactive List stops working .... That's all I was really going for...

I haven't seen the exception though that you refer to... I thought maybe that's what was causing it to stop but for me that exception never really comes about...

[chillbythewater]

I get that the example is contrived but obviously we need to look at the specific case to get to the bottom of the difference. Using SelectMany and ObserveOn instead of SubscribeOn in the pattern above at least ensures that the adds and events are all on the main thread. My own testing seemed to show that the ListView for ObservableCollection updated regardless of which thread was doing the inserts. The ListView for the ReactiveList intermittently stopped updating HOWEVER when I rotated the device in EVERY case the items then appeared in the ReactiveList ListView. There are reports on the Xamarin forums about ListView not updating when used with ObservableCollection. In these cases the rotation revealed the "missing" items.

[PureWeen]

So two things I've noticed...

1. If I simplify down the template

  <ListView x:Name="theView" >

        </ListView>

Then it updates pretty far... After about the 14th or 16th item it stops. As I make the ItemTemplate more involved then it seems to work less and less...

2. If I go into ReactiveList and I remove the "#if NET_45" compiler directive and all the Weak Event Handling so that it just uses the strong event binding then the ReactiveList works exactly the same as the ObservableCollection... So I think there's something with how

@delegate.DynamicInvoke(sender, args);

works in iOS that the ListView just stops getting the messages

Which all might have to do with what you're looking at with what thread things are firing on

[PureWeen]

If I run this on Android you can see when the WeakEventHandler gets garbage collected...

02-26 13:32:33.261 D/dalvikvm( 2007): GC_EXPLICIT freed 82K, 4% free 3629K/3772K, paused 2ms+0ms, total 12ms
02-26 13:32:33.265 D/Mono    ( 2007): GC_OLD_BRIDGE num-objects 81 num_hash_entries 93 sccs size 93 init 0.00ms df1 0.45ms sort 0.23ms dfs2 1.37ms setup-cb 0.01ms free-data 0.14ms links 12/12/12/1 dfs passes 186/105
02-26 13:32:33.265 D/Mono    ( 2007): GC_MINOR: (Nursery full) pause 17.00ms, total 17.43ms, bridge 17.30ms promoted 960K major 1248K los 2003K

After that runs then the ReactiveList stops getting messages.. I tried moving the list declarations outside of the loops so they are properties on the view itself but same thing happens..

So I'm not sure at this point if that's just how life goes or if there's a way to ensure those don't get garbage collected... I know I've had this issue before with Weak Event Handlers in SL as well

[PureWeen]

I added a branched version where I removed ReactiveUI from the equation and just pulled out the WeakEventHandler and it does the same thing :-)

https://github.com/PureWeen/XamarinFormsiOSListViewReactiveList/tree/removedreactiveui

I'll post that one over at xamarin see if they have any thoughts