- Home
- Forum
- Xamarin.Forms
- CRASH: Null Reference Exception in MeasureSize.Convert
CRASH: Null Reference Exception in MeasureSize.Convert
We are using SfListView version 15.2.0.46.
iOS stack trace:
- Could you please check whether you have updated the binding context for the SfListView properly?
- Could you please share in which layout does the issue replicates and please share the replication procedure too?
- Could you please share the application scenario in which the reported issue occurs?
- Could you please share the Xamarin Forms version?. We have ensured in Xamarin Forms v2.3.3.180.?
Thank you Dinesh,
We have confirmed that we are initializing the renders correctly. This issue does not happen all the time, but is intermittent, as it will just seem to happen all of a sudden.
We are using a newer version of Xamarin forms: 2.3.5.256-pre6. Unfortunately, we are not able to downgrade as they fixed a major bug for us in these pre-releases.
One thing we are doing that might be of note is expanding and collapsing the listview cell on click (to show additional content), Occasionally we notice that the cell expands, but the content doesn't show up, I am wondering if this leads to the crash.
I have attached a text file with our layout. I pasted both the data template and how we use the listview into the same file.
We will work on finding 'reproducible steps' to share with you.
Regards,
-Jeff
Attachment: layoutexample_6fbc0eb0.zip
Hi Dinesh,
I was able to find a way to reproduce this:
- Open the page that has the listview, the listview ItemsSource is loaded via an API call to our web service.
- Before the API returns it's response, navigate away from the page
- Navigate back to the page
- Observe: When the API response returns, it crashes with the error reported.
As a note, I was able to find a workaround to this 'crash'. On the 'Disappearing' event of the content page. If I dispose of the list view. It will prevent the crash the next time the page loads. The problem with this, is that the next time I load the page, it can take ~5-6 seconds even after our API to response to display the data (even if it is only 1 item).
I hope this helps!
Regards,
-Jeff
- Could you please share that whether the issue replicates only in particular platform such as Android only or others too?.
- Have you loaded the same collection to the ItemsSource when navigate back to the Detail page or new collection?
- If possible, could you please reproduce the issue in a sample? which would help us to analyze the issue better and update you an appropriate solution.
I am having same problem when I use listview in a popuppage, if I dont dispose listview when the popup is popped and try to open the popup, it causes crashes using autofit mode.
@Jeff: could you figure out exact problem and found a workaround? I am using latest stable of XF, not pre release and it occurs with that also
Hi Emil,
By what I am seeing, there seems to be some issues around async loading of the ListView ItemsSource from our PageModels. I am not sure if this issue is specific to our MVVM framework (We are using FreshMvvm), but when we navigate away from the page the PageModel, the async commands in progress are not ended automatically (they will finish even if the page is no longer on the stack). So the next time the page loads, it seems as though the ListView is getting confused and tries to load the items from the previous time the PageModel was loaded (which most likely have since been cleaned up) and it crashes with the null reference in MeasureSize.Convert.
As far as a workaround, the 'Dispose' of the ListView on Disappearing seemed to help.. but of course when we would not navigate away from the page completely, but simply a modal popped up, when the modal went away, the app would crash due to the ListView no longer being there. So I got rid of the Dispose() on disappear. What I tried next was in my async Command (which I had attached to a TaskCompletionSource), I tried to cancel the Task on Dissappear. That seemed to help a bit.. but there seemed to be a race condition where occasionally we would see this issue come up still.. My latest attempt at trying to get rid of this race condition, I implemented cancellation token support from our Command to our API Client into the REST client framework (We use RestSharp). I can't say for sure if this helped completely yet as we haven't had any test time with this yet, but I couldn't crash the app in my development environment, but maybe some of the above may help you :).
In either case, I think this crash could easily be prevented by a Null check in this MeasureSize.Convert method (most likely on the view..).
Dinesh,
Sorry for the late reply!
To answer your questions:
- Could you please share that whether the issue replicates only in particular platform such as Android only or others too?. This happens at least on iOS and Android, our app doesn't support any other platforms at this time.
- Have you loaded the same collection to the ItemsSource when navigate back to the Detail page or new collection? I am not quite sure what you mean by this, but I believe we are trying to load a new collection, but perhaps due to our async calls (see my description above to Emil) its possible it is trying to load the old one.
- If possible, could you please reproduce the issue in a sample? which would help us to analyze the issue better and update you an appropriate solution. I will try to find the time to do this, but my schedule is incredibly tight right now. In our App, it was a ContentPage where this crash occurred, we went from Master Detail >> Content Page (page using ListView) >> Master Detail >> Content Page (page using ListView) >> CRASH. If the problem is what I think it might be, if you create a Content page with a PageModel, and asynchronously load the ItemsSource (which is bound to a property in the PageModel) when the Page loads (from the PageModel) and before the async call returns, navigate away from the Page. Then navigate back to the page, and wait for it to load. This is where we are seeing the crash.
- 8 Replies
- 3 Participants
-
JB Jeff Bowman
- Jul 27, 2017 06:12 PM UTC
- Aug 9, 2017 04:09 AM UTC