onViewChanged called when calendar is first displayed
According to the documentation, onViewChanged should only be called when the calendar is swiped to previous/next or switched to another view completely. Is this a bug?
In my case, I use this callback to trigger an API call to load data for the new dates displayed in the view. However, because this is called right away, it puts things into an endless loop of setting the new dates and rebuilding the widget. To prevent it, I had to check to see if the initial dates I loaded for are the same dates passed back in `onViewChanged` and if so, I skip updating the dates to load data for.
SIGN IN To post a reply.
5 Replies
IR
Indumathi Ravichandran
Syncfusion Team
April 22, 2020 08:30 AM UTC
Hi James,
Thank you for contacting Syncfusion support.
To avoid an endless loop and rebuilding the widget, please use the addPostFrameCallback to Schedule a callback for the end of this frame. Please find the following code snippet for resolving the issue in sample level,
Code snippet:
|
onViewChanged: (ViewChangedDetails viewChangedDetails) {
SchedulerBinding.instance.addPostFrameCallback((duration) {
setState(() {});
});
} |
Please find the more details about the addPostFrameCallback method from the following link,
We have used the addPostFrameCallback in the below KB,
We hope that this helps you. Please let us know if you need further assistance.
Regards,
Indumathi R
JA
James
April 22, 2020 03:16 PM UTC
Hi Indumathi,
Thank you for the reply.
Yes, I'm currently using that as a workaround. However, I believe the issue is two-fold:
1. The documentation is misleading as it says "The onViewChanged callback triggers when the current view of calendar changed, that is view swiped to previous /next view, calendar view switched to another calendar view." It indicates that this only occurs when the view has changed, not when it is initialized.
2. Is there a specific reason why this callback should be fired when the calendar is first displayed? I believe it would make sense that `onViewChanged` only fires when the view actually changes. That said, maybe there is another call back like `onInit` if you want to perform some sort of logic when the calendar is first created.
By only having the `onViewChanged` callback fire when changes are made, you avoid the workaround of having to use `addPostFrameCallback`
Thank you!
IR
Indumathi Ravichandran
Syncfusion Team
April 23, 2020 10:25 AM UTC
Hi James,
Thank you for the update.
Regarding Query 1:
We regret for not mentioning the notes previously. Now, we have documented the reason for initial triggering of the onViewChanged callback. Please find the following UG link for the same.
Regarding Query 2:
It is the current behavior of the Flutter event calendar. The purpose of the triggering onViewChanged initially is, to get the initial visible dates. Please find the following link for information about onViewChanged callback.
Regards,
Indumathi R
JA
James
April 23, 2020 06:20 PM UTC
Thanks for the reply.
Maybe it would be an improvement to the API to split these callbacks?
One for the initialization of the calendar -- ex: onInit or onLoad, and only runs once.
You said "The purpose of the triggering onViewChanged initially is, to get the initial visible dates. Please find the following link for information about onViewChanged callback. " It seems more natural to be able to hook into a callback that only fires once.
And then keep onViewChanged for actual changes of the view.
IR
Indumathi Ravichandran
Syncfusion Team
April 24, 2020 08:43 AM UTC
Hi James,
Thank you for the valuable feedback. We will consider splitting `onViewChanged` and `onloading` callbacks in the Flutter event calendar. As of now use the `onViewChanged` callback of the Flutter calendar for achieving your requirement.
Regards,
Indumathi R
SIGN IN To post a reply.
- 5 Replies
- 2 Participants
-
JA James
- Apr 21, 2020 09:54 PM UTC
- Apr 24, 2020 08:43 AM UTC