[RadListView] iOS Swiping reused cell to crash
Yes
Swiping reused cell to crash
iOS
Progress NativeScript UI version: 2.0.1
CLI: 3.0.0
Cross-platform modules: 3.0.0
Runtime(s): 3.0.0
-> Crash (at listview.ios.js:var viewAtIndex = owner._realizedCells.get(cell.tag).view in function TKListViewDelegateImpl.prototype.listViewShouldSwipeCellAtIndexPath)
I found that the cause is cell.tag is missing in owner._realizedCells.
Because _realizedCells.set(cell.tag, cell) won鈥檛 be called when the cell is from listView.dequeueLoadOnDemandCellForIndexPath(indexPath).
For your information, I am using following workaround to add reused cell into _realizedCells and working fine.
in RadListView.prototype.prepareCell
if (cell.view === undefined) {
cell.view = this.getItemTemplateContent();
this.prepareCellTag(cell);
.
.
+ } else {
+ this.prepareCellTag(cell);
+ }
Hello @kssfilo,
This was a regression from {N} 3.0 migration that we've already fixed. The fix will be included in the next update due to around mid June.
We will start publishing daily builds under the @next tag in a day and you will be able to verify the fix.
Note that these builds are the Trial version of the Pro plugin but they are not any different in functionality compared to the paid plugin.
The @next version of the Free plugin will be without a Trial watermark as expected.
Sorry for commenting a closed thread, but I'm still having this issue on NativeScript-Vue.
I am populating a RadListView with async items through auto load on demand. Swiping an element below the ones loaded first causes a crash:
JS ERROR TypeError: undefined is not an object (evaluating 'owner._realizedCells.get(cell.tag).view')
NativeScript caught signal 11.
Versions:
nativescript-vue: ^2.0.0
nativescript-ui-listview: 6.3.2 (same problem with 5.1.1)
Cross-platform modules: ^5.4.2
CLI: 5.4.0
iOS runtime: 5.4.1
For now, using kssfilo's workaround is solving the problem.
Hi @tommag21 ,
Can you share with as more details on the observed behavior. It would be best to open a new issue where you can described the issue with steps to reproduce it and a sample project showcasing it.
Most helpful comment
Hello @kssfilo,
This was a regression from {N} 3.0 migration that we've already fixed. The fix will be included in the next update due to around mid June.
We will start publishing daily builds under the @next tag in a day and you will be able to verify the fix.
Note that these builds are the Trial version of the Pro plugin but they are not any different in functionality compared to the paid plugin.
The @next version of the Free plugin will be without a Trial watermark as expected.