I have a method that gets called when entering a chart page in my WP7 app. It generates a List of objects and populates a ListBox. The content of each ListBoxItem is a Grid with 10 columns of data. The List gets generated incredibly quickly, even with 1000-2000 items. But as soon as the method starts building Grids and adding them to the ListBox it gets relatively much slower. Now, by this I mean it only ties up the the device for half as long as a comparable app on my 2nd gen. iPod Touch. So performance is great – as long as the user wants the data chart.
If the user hits the Start button the app exits so that’s not a problem. My concern is when the user backs out to the previous page. The app just waits until the method has run. I notice similar behavior in more mainstream apps like the Kindle app. But I don’t have that kind of clout with MarketPlace store! I do have a progress bar that keeps running so the behavior is the same.
Out of concern for being rejected by MarketPlace I tried putting the method into a BackgroundWorker process but that fails because it’s in creating the UI elements that is where the bottleneck is and that is running on the UI thread so I get access errors. Is there a way to take a method that creates UI elements, such as a Grid, and make it cancelable?
Are you creating the UI elements within each
ListBoxItemmanually in code? If so, you will find increased performance by using databinding instead because theListBoxuses theVirtualizingStackPanelas the items container, so it will only actually create UI elements for enough elements to be seen and to scroll to immediately. Other elements are created when the user starts to scroll. The Silverlight for Windows Phone Performance Team have a great post on ListBox Performance.If the dataset is particularly large you may find further peerformance improvements by using data virtualization as well (or instead) as Peter Torr explains in his Virtualizing Data in Windows Phone 7 post.