Open RareScrap opened 3 years ago
After many weeks of work and bug fixing, I am very happy to present this solution to you (seriously, I think I’m one step closer to alcoholism). I can't say that the feature is fully implemented, but I think that a significant part of the work is over. I would love to hear your comments and ask you to help me with testing. To be honest, it is very difficult for me to come up with such a set of tests that would cover ALL possible options for the behavior of the CalendarKit when changing the timezone, but I checked everything I could and everything works well.
I will update the example app a little later so that you can test this feature more easily. I will also fix conflicts a little later.
Hi, thanks for the update. I'll get back to you soon. I hope to check it this weekend.
Now I think, the best way to handle this is to simply propagate the Calendar change on a view-by-view basis (e. g. from DayView to Header and other sibling views) and not thru a common
DayViewState
.The reason for this is simple: some views may need to have the access to the Calendar property, but don't need to subscribe to the State notifications: DaySymbolsView is one of such views.
Of course, we could propagate
State
to theDaySymbolsView
also, but wouldn't that complicate the library?