I've found what appears to be a very severe memory leak in the DataChartView component. Something related to bitmap caching or something possibly related to synchronized scrolling. Sample project here:
https://dl.dropboxusercontent.com/u/56947838/MemoryLeak.zip
It manifests when you rotate the device, and with this sample it takes 4-5 rotations before the process runs out of memory.
This is with the public CTP builds, but other builds we're using also exhibit similar problems.
I've replicated on both a real device (Samsung 4.4) and a Genymotion Android 5.x emulator.
Thank you!
Great, we'll test and get back to you.
Caylan,
The potential leak that I'm seeing should be evaded if you call
setSyncChannel(null);
In addition to destroy() on the charts when the orientation change happens.
I gave this piece of advice to Andrew and he hasn't seen the exception after quite a few rotations so far. So hopefully that is a viable work around for you guys.
He's calling destroy on both charts and setting the sync channels to null during the Activity's onDestroy method. Let me know if that helps.
The root issue here is that the destroy() method should be doing a bit more than it does (namely cleaning up some sync channel stuff). Hopefully that work around can tide you over till we fix it in the product.
-Graham
It reminds me of that funny quote: What came first, the bugs or the users? :)
Good luck, and let us know how we can continue to help.
Just as a reminder, here, by the way. Infragistics Android is a pre-release product, specifically because we cannot yet assert RTM level stability. We, of course, hope that you don't run into any more issues, but there is a reason we aren't calling this RTM yet.
Hope this helps!
Hey,
Yeah, as I said, this could be a different scenario than what we have run into before. Everything I said still applies though.
Presumably the sync channel is left up and destroy doesn't take it down.
In the interim. For android you can achieve most of what sync channel gives you by alternatively listening for
setOnActualWindowRectChanged...
And then calling setWindowRect on the other chart, and vice versa. You would need an extra boolean, though, to make sure you aren't bouncing the value back and forth ad infinitum though. I'm sure Andrew could help you set that up if that doesn't make sense. Hopefully we can have this resolved soon though, and you could request an untested build if necessary.
Thanks for the additional info.