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.

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 


Loader.
Up arrow icon