Open anuragd7 opened 5 years ago
anuragd7
commented
5 years ago Hi @NickIliev - Let me know if I can help progress this in any way. This is holding up the upgrade to nativescript-ui-listview v 5. The same template worked with version 3.x.
NickIliev
commented
5 years ago @anuragd7 in itemLoading you are calling the onGradeItemLoading method which is is triggering the itemSelected event via args.object.selectItemAt(element). This seems to cause the issue on your side as the itemSelected is in race condition iwht the itemLoading. Try to wrap the call for the selection in minor timeout
setTimeout(() => {
selectedGradeIndexes.forEach(element => {
args.object.selectItemAt(element);
});
}, 300);@NickIliev. Thanks for the response tried to modify the function by placing the itemSelected in another timeout as suggested. However am still getting the same crash.
onGradeItemLoading(args) {
const self = this;
self.gradeTimer = setTimeout(() => {
console.log("On item loading called of grade");
const selectedGradeIndexes = self.getSelectedGradeIndexes();
setTimeout(() => {
selectedGradeIndexes.forEach(element => {
args.object.selectItemAt(element);
});
}, 300);
clearTimeout(self.gradeTimer);
}, 100);
}
meysam-mahmoodi
commented
5 years ago I had the same error, I changed FlexboxLayout to StackLayout in my RadListView and everything is ok now.
Hope can help people who have this problem.
<GridLayout class="watches">
<RadListView [items]="watches">
<ListViewGridLayout tkListViewLayout scrollDirection="vertical" itemHeight="260" spanCount="2">
</ListViewGridLayout>
<ng-template tkListItemTemplate let-item="item">
<StackLayout class="watch-item">
<!-- I changed this element from FlexboxLayout to StackLayout -->
</StackLayout>
</ng-template>
</RadListView>
</GridLayout>
NathanWalker
commented
5 years ago @anuragd7 @VladimirAmiorkov I see this crash as well on latest of everything (core 6.0, ui-listview 6.4.0)... across pretty normal setups. I've found the TKListViewCell to be problematic and unstable in it's setup. I've found that doing the following, compiling on your own and packing seems to fix all the cases for me:
- (UICollectionViewLayoutAttributes *)preferredLayoutAttributesFittingAttributes:(UICollectionViewLayoutAttributes *)layoutAttributes
{
UICollectionViewLayoutAttributes *preferred = [super preferredLayoutAttributesFittingAttributes:layoutAttributes];
// NOTE: The following is unstable and causes app crashes
// if ((fabs(preferred.frame.size.height - layoutAttributes.frame.size.height) >= 0.5 || fabs(preferred.frame.size.width - layoutAttributes.frame.size.width) >= 0.5)) {
// UICollectionViewLayoutInvalidationContext *ctx = [self.ownerListView.layout invalidationContextForPreferredLayoutAttributes:preferred
// withOriginalAttributes:layoutAttributes];
// [self.ownerListView.layout invalidateLayoutWithContext:ctx];
// }
return preferred;
}
VladimirAmiorkov
commented
5 years ago Hi @NathanWalker ,
I am aware of this current state and I have been investigating it the last days. We will do our best to have a solution soon.
NathanWalker
commented
5 years ago No rush @VladimirAmiorkov, appreciate you all looking into it. Just wanted others to know a suitable workaround for now 👍
VladimirAmiorkov
commented
5 years ago That workaround unfortunately is inside the iOS custom framework that we create for the nativescript-ui-listview plugin and its source code is not open source so it is not possible to apply it outside of a official fix. But thank you for this update, if you notice anything else please let me know. Btw the code you commented out is there to add supported for ListViewGridLayoutand ListViewStaggeredLayoutspecifically in projects that use VueJS. In that scenario the initialization of template/context is backwards compared to Vanila NS and Angular NS which is causing some major problems but is the way VueJS handles template/context when parsing a View. Anyway we are on it and hope to release a fix for those problems related to orientation change and crashed on IOS soon.
NathanWalker
commented
5 years ago @VladimirAmiorkov can you just add a hook for Vue in that case. Anything added to any code to handle specific cases for a specific framework, just have a property, isVue = true would absolutely be fine. I think in general the addition of code which is intended to solve a specific issue with a specific framework should always be guarded appropriately as often doing so is likely what gives rises to bugs in general. Most simply via a boolean which is documented to set when you're using a particular framework would be acceptable. Would also allow you to more easily dial cases specifically for different frameworks without affecting others.
VladimirAmiorkov
commented
5 years ago Hi @NathanWalker ,
Adding a hook may seam like an easy option but this functionality is a core functionality which is also shared between all 3 different layouts of the RadListView component and having multiple "paths" in the code of the component would lead to unexpected behaviours between the same scenario but only on different framework (Vanila, Angular and Vue) leading to degradation in the quality of your future development of the plugin.
NathanWalker
commented
5 years ago There's been a crash in angular integrations due to this change since it was added on Jan. 9th: https://github.com/NativeScript/nativescript-ui-listview/commit/3f5275b10d8adb16f791c7c9c2aa4c6c69ccb650#diff-faa473571fbfbe571803ba422bffc77a
That means for 5 months there's been a degradation in quality. Not sure I'm following your reasoning but I trust you nonetheless. The commit states it was specifically modified for Vue integrations however was not guarded to help only Vue integrations. Therefore vanilla and angular have been degraded ever since meaning the future of degradation has long since past?
NathanWalker
commented
5 years ago To be clear this condition !self.ownerListView.isLayoutInProgress && was removed from the guard. My main concern is that when such changes are done for specific framework integrations that they should only be done for that specific integration as to not degrade others. This is why I suggest a boolean since it is clear that the framework integrations behave differently so a simple way to manage each would seem reasonable and acceptable no?
VladimirAmiorkov
commented
5 years ago The above change was indeed made when resolving issue for a specific framework and was not handled correctly. But that condition was never added for a specific framework in the first place so removing it was designed to work for all frameworks, unfortunately we were not able to catch that this breaks other frameworks and causes regression in a timely manner due to its being a very complicated scenario in which this causes issues.
We try to not add any "framework-specific" code to the native iOS and Android code of the library used by nativescript-ui-listview because it would lead to unmaintainable code base (iOS and Android should not be concerned about Angular, Vue etc. :) ).
NathanWalker
commented
5 years ago @VladimirAmiorkov curious to followup on this one. I see this is still an issue, any thoughts?
Please, provide the details below:
Did you verify this is a real problem by searching the NativeScript Forum?
Yes
Tell us about the problem
The itemLoading event on the radlistview triggers a crash.
Which platform(s) does your issue occur on?
IOS
Please provide the following version numbers that your issue occurs with:
nativescript-ui-listview version 5.1.1
CLI: TNS - 5.2
Cross-platform modules: 5.2.0
Runtime(s): 5.2
Please tell us how to recreate the issue in as much detail as possible.
npm ifollowed bytns run iosthe following error log is seen