Nativescript-ui-feedback: [BUG]: RadListView on iOS to does not respect loadMoreDataRequested returnValue

[sserdyuk]

Hello, I have a problem where I am reaching the end of the stream but the list keeps calling the event and spinning the wheel on the bottom of the view. I thought that data.returnValue = false; would prevent that, but it makes no difference. How do I do it properly?
As a side note, the documentation here doesn't cover that scenario at all.

    onLoadMoreItemsRequested(data: ListViewEventData) {
        if (appStore.apiState.canLoadMoreListings()) {
            data.returnValue = true;
            let listView = <RadListView>data.object;
            appStore.apiState.loadMoreListings().then((dataLoaded) => {
                listView.notifyLoadOnDemandFinished();
            }, () => {
                listView.notifyLoadOnDemandFinished();
            })   
        } else {
            data.returnValue = false;
        }
    }

[sserdyuk]

Actually, the code above works properly on Android, but not on iOS. Could it be a bug?

[sserdyuk]

This is still an issue for me. Could it be a bug?

[adouglas0363]

You should add the following to your else.

listView.loadOnDemandMode = ListViewLoadOnDemandMode[ListViewLoadOnDemandMode.None]; listView.notifyLoadOnDemandFinished();

The key is calling the notifyLoadOnDemandFinished method.

Setting the load on demand mode to none just prevents the possibility of being fired again when it has already been established that there is no more data to load.

[sserdyuk]

@adouglas0363 Thank you for the idea on a workaround. As I also use pull-to-refresh, I'd have to switch loadOnDemandMode back and forth each time. It seems to me that it still should be fixed in the iOS implementation.

[sserdyuk]

@tsonevn Please take a look at this. The workarounds suggested so far cause way to many issues with code style, and binding loadOnDemandMode to an observable property causes all sorts of glitches. This should just work as expected: if returnValue of the event is set to false, the spinner animation should not be shown. It does work properly on Android already.

[tsonevn]

Hi @sserdyuk,
Can you provide more info about your environment(NativeScript CLI, tns-core-modules, tns-android, tns-ios, nativescript-ui-listview versions)?
I will suggest checking if you will have the same problem while using the latest nativescript-ui-listview version 3.5.4.

If the problem persists, please send us a sample project, which will help us in debugging the issue.

[sserdyuk]

@tsonevn It's the latest 3.4 NS with the latest 3.5 UI.

    "nativescript-ui-listview": "^3.5.4",
    "nativescript-ui-sidedrawer": "^3.5.2",

$ tns info
All NativeScript components versions information
┌──────────────────┬─────────────────┬────────────────┬──────────────────┐
│ Component        │ Current version │ Latest version │ Information      │
│ nativescript     │ 3.4.3           │ 4.0.0          │ Update available │
│ tns-core-modules │ 3.4.1           │ 4.0.0          │ Update available │
│ tns-android      │ 3.4.2           │ 4.0.0          │ Update available │
│ tns-ios          │ 3.4.1           │ 4.0.1          │ Update available │

[sserdyuk]

@tsonevn I made a test project that illustrates the issue. The expected behavior is that it should reach the end of the source stream and stop spinning the wheel and stop calling for more data. Instead it just keep calling for more and eventually crashes. I've tried all sorts of permutations trying to get it to work, but couldn't find a working combination.

https://github.com/sserdyuk/ns-ui-bug-595

[tsonevn]

Hi @sserdyuk,
Thank you for the sample project.
I tested it on my side and have to confirm that this is a real problem in iOS. I marked the issue as a bug.
For further info, please keep track on the issue.

[nicoletteschreier]

how long until this is fixed?

[tsonevn]

Hi @nicoletteschreier,
We can not commit to the exact time when the fix for this issue will be available.
However, in the meantime, you can use the above-suggested workaround for using ListViewLoadOnDemandMode.None. Also, you can review the example here.

[VladimirAmiorkov]

Hi @sserdyuk ,

Could you clarify what is the expected behavior that you are talking about? After looking at the behavior on Android, what I observe is that once the returnValue is set to false, the "load on demand" functionality is disabled completely, meaning it will never automatically trigger again. In order to trigger you will have to explicitly again set the loadOnDemandMode to None and back to Auto as suggested in the "workaround". Can you confirm you are referring to this behavior as the expected one when working with the returnValue ?

If this is not the expected behavior could you describe what the one should be. For example what would you like the behavior to be after the "load on demand" is stopped, is it stopped for ever and if not when and how would you like to get the new "trigger"? Thank you.

[sserdyuk]

@VladimirAmiorkov The expected behavior is to stop calling for more data until data binding changes or pull to refresh executes.

[VladimirAmiorkov]

@sserdyuk

Thank you for clarifying this. Currently neither of the platforms behavior this way but I do see what you are saying and I also believe that such behavior would be beneficial. Due to this being something that is missing on both platforms in the current version I have added it in a separate report and tagged it as a feature, we will do our best to implement it as soon as possible. This also allows this report to be treated for the main issue "returnValue" not working as expected.

[sserdyuk]

@VladimirAmiorkov I think Android version already works like this. It's only the iOS version that needs a fix.

[VladimirAmiorkov]

I tested it and it doesn't which was why I wanted you to clarify the desired behavior.

[sserdyuk]

@VladimirAmiorkov My earlier tests indicated that it worked on Android, at least the "pull to refresh" part. Maybe something has changed since then. I'll retest on Friday when I get back to the office.

[VladimirAmiorkov]

Created PR, awaiting approval by team.