Hi @zachterrell57, I was able to get the behavior you want working in the example project by adding the following to SingleDaySelectionDemoViewController.swift

override func viewDidLoad() {
  // ...
  calendarView.insetsLayoutMarginsFromSafeArea = false
  // ...
}

override func viewWillLayoutSubviews() {
    super.viewWillLayoutSubviews()

    if case .horizontal(let monthWidth) = monthsLayout {
      let marginSize = (view.bounds.width - monthWidth) / 2
      calendarView.layoutMargins.left = marginSize
      calendarView.layoutMargins.right = marginSize

      calendarView.setContent(makeContent().withInterMonthSpacing(marginSize))
    }
  }

Hope this helps! Note that there isn't currently any snapping behavior for the horizontal layout, but this is something I'm looking into adding in the near future!

Hi @sethi-ishmeet - this is something that's definitely on our radar. My understanding is that support could be added by wrapping it with UIViewRepresentable. I'll be exploring this in the coming weeks!

Details

This fixes a crash than can occur if the content of the calendar is set while it's programmatically scrolling. In this scenario, the display link does not get invalidated even though our scrollToItemContext is set to nil. If the scrollToItemContext is nil the next time the display link fires, then we hit a precondition failure.

To simplify things, we should really just invalidate the display link whenever our scrollToItemContext is set. This PR makes that change.

Related Issue

N/A

Motivation and Context

Crash fix.

How Has This Been Tested

iOS simulator example app and Airbnb app (where the repro case was identified).

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [ ] Docs change / refactoring / dependency upgrade
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.

scrollToItemContext is set to nil just a few lines down, so no need to manually invalidate here anymore.

Details

This fixes a crash than can occur if the content of the calendar is set while it's programmatically scrolling. In this scenario, the display link does not get invalidated even though our scrollToItemContext is set to nil. If the scrollToItemContext is nil the next time the display link fires, then we hit a precondition failure.

To simplify things, we should really just invalidate the display link whenever our scrollToItemContext is set. This PR makes that change.

Related Issue

N/A

Motivation and Context

Crash fix.

How Has This Been Tested

iOS simulator example app and Airbnb app (where the repro case was identified).

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [ ] Docs change / refactoring / dependency upgrade
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.

Details

This adds the ability to configure a separator view below the days-of-the-week row - whether it's a pinned row or a row that appears separately in each month.

Pr-month Vertical	Per-month Horizontal	Pinned

Related Issue

N/A

Motivation and Context

This adds back a key piece of functionality that used to exist in pre-release versions but was removed from the public 1.0 release.

How Has This Been Tested

iOS simulator, unit tests.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [x] Docs change / refactoring / dependency upgrade
• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [x] I have added tests to cover my changes.

Details

I noticed an issue where month headers were getting clipped too soon when figuring out which items are visible / not visible in a horizontal layout calendar. The root issue is that my heuristic for figuring out what intersects the visible rect was wrong for horizontal layouts.

Before	After

Related Issue

N/A

Motivation and Context

Bug fix.

How Has This Been Tested

iOS sim, unit test.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [ ] Docs change / refactoring / dependency upgrade
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] I have read the CONTRIBUTING document.
• [x] I have added tests to cover my changes.

Yeah, it's only exposed internally but yes, it's a way to avoid an awkward case let in the VisibleItemsProvider.

not used anywhere besides this unit test

Details

This adds the ability to configure a separator view below the days-of-the-week row - whether it's a pinned row or a row that appears separately in each month.

Pr-month Vertical	Per-month Horizontal	Pinned

Related Issue

N/A

Motivation and Context

This adds back a key piece of functionality that used to exist in pre-release versions but was removed from the public 1.0 release.

How Has This Been Tested

iOS simulator, unit tests.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [x] Docs change / refactoring / dependency upgrade
• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [x] I have added tests to cover my changes.

Details

I noticed an issue where month headers were getting clipped too soon when figuring out which items are visible / not visible in a horizontal layout calendar. The root issue is that my heuristic for figuring out what intersects the visible rect was wrong for horizontal layouts.

Before	After

Related Issue

N/A

Motivation and Context

Bug fix.

How Has This Been Tested

iOS sim, unit test.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [ ] Docs change / refactoring / dependency upgrade
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] I have read the CONTRIBUTING document.
• [x] I have added tests to cover my changes.

Details

This PR fixes 2 bugs

• Pinned days of the week are not inset by the view's layout margins
• Pinned days of the week show content scrolling underneath them if there's a horizontalDayMargin >= 0 configured

Video demonstrating the second issue:

Related Issue

N/A

Motivation and Context

Bug fixes

How Has This Been Tested

iOS simulator

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [ ] Docs change / refactoring / dependency upgrade
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [x] I have added tests to cover my changes.

Details

This PR fixes a 2 bugs

• Pinned days of the week are not inset by the view's layout margins
• Pinned days of the week ill show content scrolling underneath them if there's a horizontalDayMargin configured

Video demonstrating the second issue:

Related Issue

N/A

Motivation and Context

Bug fixes

How Has This Been Tested

iOS simulator

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [ ] Docs change / refactoring / dependency upgrade
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.

thanks a bunch @RomanPodymov !

Hello, is it possible to add bottom contentInsets for scroll view?

@misha8414 @JulienLevallois @alex-sarkisov I've added the ability to set insets using UIView's layoutMargins and directionalLayoutMargins properties. The changes are included in v1.2.0. Thank you again for reporting this and for your patience as I investigated a good way to do this 🙂

Details

This removes some legacy behavior that overwrote the month header's layout margins with the left/right values from monthDateInsets.

Related Issue

N/A

Motivation and Context

API consumers should be free to set whatever layout margins they want on their month headers, without being overwritten by the calendar.

How Has This Been Tested

Tested in the Airbnb app and in the demo project. Confirmed that layout margins are not reset / overwritten.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [ ] Docs change / refactoring / dependency upgrade
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.

Details

This removes some legacy behavior that overwrote the month header's layout margins with the left/right values from monthDateInsets.

Related Issue

N/A

Motivation and Context

API consumers should be free to set whatever layout margins they want on their month headers, without being overwritten by the calendar.

How Has This Been Tested

Tested in the Airbnb app and in the demo project. Confirmed that layout margins are not reset / overwritten.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [ ] Docs change / refactoring / dependency upgrade
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.

Details

This adds support for insetting the content without affecting the scrollable / user-interact-able region using the layoutMargins and directionalLayoutMargins properties on CalendarView.swift

The approach of using layout margins seems to work pretty well - one nice thing we get for free is automatic safe area inset respecting (which can be turned off via the flag on UIView). The one quirk is that we don't support negative layout margins, since this causes really weird scrolling / layout logic. I can't really think of a valid reason to use negative values either, but hopefully I'm not missing something obvious.

One other caveat - For horizontal layout calendars, the current sizing logic doesn't take into account the vertical dimension of the frame. Instead, it's determined by the monthWidth that's passed into CalendarViewContent. In hindsight, this probably isn't how the horizontal layout should work - instead, the horizontal layout should determine its month width by looking at the available height. Because of this shortcoming with how the horizontal layout works, there's not a great way to make layout margins work perfectly in the vertical dimension, since the available space in the vertical dimension isn't taken into account. I don't think this is a showstopper, as the leading / trailing / top margins all work well. It's only when you use both a top and bottom margin that the latter is basically just ignored. As part of the 2.0 release of HorizonCalendar, I'll change this API / behavior so that it works in a more predictable way, which will have the consequence of making the layout margins work correctly for top / bottom when using a horizontal layout.

Vertical	Horizontal (just leading / trailing margins)

Related Issue

https://github.com/airbnb/HorizonCalendar/issues/19

Motivation and Context

It's common for people to want to inset their calendar's content without adjusting the frame or scrollable region. For example, this could be useful when displaying a vertically scrolling calendar on iPad, where the content would look way too big if it went edge-to-edge horizontally. By setting layout margins, the content of the calendar can be inset while still allowing scroll gestures all the way to the edge of the screen.

How Has This Been Tested

Tested on simulator and device.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [x] Docs change / refactoring / dependency upgrade
• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.

Details

This adds support for insetting the content without affecting the scrollable / user-interact-able region using the layoutMargins and directionalLayoutMargins properties on CalendarView.swift

The approach of using layout margins seems to work pretty well - one nice thing we get for free is automatic safe area inset respecting (which can be turned off via the flag on UIView). The one quirk is that we don't support negative layout margins, since this causes really weird scrolling / layout logic. I can't really think of a valid reason to use negative values either, but hopefully I'm not missing something obvious.

One other caveat - For horizontal layout calendars, the current sizing logic doesn't take into account the vertical dimension of the frame. Instead, it's determined by the monthWidth that's passed into CalendarViewContent. In hindsight, this probably isn't how the horizontal layout should work - instead, the horizontal layout should determine its month width by looking at the available height. Because of this shortcoming with how the horizontal layout works, there's not a great way to make layout margins work perfectly in the vertical dimension, since the available space in the vertical dimension isn't taken into account. I don't think this is a showstopper, as the leading / trailing / top margins all work well. It's only when you use both a top and bottom margin that the latter is basically just ignored. As part of the 2.0 release of HorizonCalendar, I'll change this API / behavior so that it works in a more predictable way, which will have the consequence of making the layout margins work correctly for top / bottom when using a horizontal layout.

Vertical	Horizontal (just leading / trailing margins)

Related Issue

https://github.com/airbnb/HorizonCalendar/issues/19

Motivation and Context

It's common for people to want to inset their calendar's content without adjusting the frame or scrollable region. For example, this could be useful when displaying a vertically scrolling calendar on iPad, where the content would look way too big if it went edge-to-edge horizontally. By setting layout margins, the content of the calendar can be inset while still allowing scroll gestures all the way to the edge of the screen.

How Has This Been Tested

Tested on simulator and device.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [x] Docs change / refactoring / dependency upgrade
• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.

@AntonBelousov sorry for the delay - I think making MagazineLayout open, marking most of the functions as final, and having an open function called makelayoutAttributes(forCellAtIndexPath indexPath: IndexPath) -> MagazineLayoutCollectionViewLayoutAttributes seems like a reasonable change. If this is something you still need / have already implemented, feel free to make a pull request with the changes!

Hi @markturnip - MagazineLayout should definitely support iOS 12. Can you post an example of the issues / crashes you're seeing?

Than ks @RomanPodymov ! If you can get the build working, then this seems like a good change! https://travis-ci.com/github/airbnb/MagazineLayout/builds/176573279

@markturnip does that fix it? I'll close out until I hear otherwise. I do think that in general, animating header size changes is something collection view does not handle well. Even the insert / delete animations are kind of glitchy.

I think the best workaround is to just use a cell, or if what you're doing by manually calling layoutIfNeeded works, then that seems reasonable!

What's the appropriate way to animate the resize of a header?

I'm currently trying using:

UIView.animate(withDuration: 0.3) {
  collectionView?.collectionViewLayout.invalidateLayout()
}

Will this library support a cascading style layout similar to pinterest? (see CHTCollectionViewWaterfallLayout(

Hi @halpz - at this time, something like that is out-of-scope for this project.

This is being worked on soon @shayan77 - stay tuned!

Details

Improves Voiceover behavior when navigating by month heading:

To fix navigating by heading, I had to add a proper visibleMonthRange implementation. The previous implementation just looked at the min / max of the visibleDayRange, which caused partially visible months that only had their month header visible (but no days) to be excluded from the visibleMonthRange. This resulted in a the infamous "Heading not found" voiceover bug since my one month lookahead/behind logic depended on the visibleMonthRange being accurate.

Reduces delay when a user selects a day using voiceover

I was unnecessarily triggering a layoutChanged voiceover notification whenever a user selected a day, which would cause the user's focus to be lost. That notification wasn't necessary, and was actually probably causing some minor confusion since the layoutChanged notification actually plays a short blip sound to indicate re-layout.

Related Issue

N/A

Motivation and Context

Get Voiceover working great!

How Has This Been Tested

Tested using Voiceover in the example app on a real device.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [ ] Docs change / refactoring / dependency upgrade
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.

Hey @seanperez29 ! This is a cool suggestion, I could see us using something like this in the Airbnb app one day.

This isn't something that's currently on the roadmap, but I think this would be a great API addition if it's something you'd be interested in tackling. I've tagged this as being a good issue for first-time contributors!

If anyone wants to look into implementing this, it would probably be a new item provider on CalendarViewContent (some kind of footer item type).

The more complicated parts are deciding how to lay something like this out. Does it have its own padding values? Does it self-size, or statically size? Is this a one-off item provider type, or part of a more general system for adding supplementary content to various parts of the calendar - a month footer being just one of several supported locations.

If we can think through a great API that will serve us well for this feature / potentially others in the future, that would be a great first step!

Details

Improves Voiceover behavior when navigating by month heading:

To fix navigating by heading, I had to add a proper visibleMonthRange implementation. The previous implementation just looked at the min / max of the visibleDayRange, which caused partially visible months that only had their month header visible (but no days) to be excluded from the visibleMonthRange. This resulted in a the infamous "Heading not found" voiceover bug since my one month lookahead/behind logic depended on the visibleMonthRange being accurate.

Reduces delay when a user selects a day using voiceover

I was unnecessarily triggering a layoutChanged voiceover notification whenever a user selected a day, which would cause the user's focus to be lost. That notification wasn't necessary, and was actually probably causing some minor confusion since the layoutChanged notification actually plays a short blip sound to indicate re-layout.

Related Issue

N/A

Motivation and Context

Get Voiceover working great!

How Has This Been Tested

Tested using Voiceover in the example app on a real device.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [ ] Docs change / refactoring / dependency upgrade
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.

I'd like to have a CalendarView and a UIDatePicker on the same screen, and be able to initialize the CalendarView with a selected day already provided. Without the user having to select a date.

When trying to create a new Day object I get the error: "'Day' initializer is inaccessible due to 'internal' protection level". So, I tried adding a public init() {} to the Day object with some initial values, but it still is giving the error. The same error happens with the Month object.

I would just make a public init on the Day and Month objects and it would fix my problem, but it's still giving the error.

Hi @thecoolwinter - I need an FAQ for this question since it gets asked quite a bit 😛

The short answer - those are intentionally internal to prevent you from making a Day using the wrong Calendar object (which would result in a Day that is incompatible with other Days).

If you want to make a certain day appear selected, you can do so in your dayItemProvider closure. You can convert the provided Day to a Date by doing let date = calendar.date(from: day.dateComponents)!. Then, you can use any of the standard Calendar functions to compare Dates. For example, you could check whether a particular date is "today" and return a different, highlighted calendar item if that condition is true.

More context here: https://github.com/airbnb/HorizonCalendar/pull/28

@brynbodayle here's the new protocol that all views in the calendar need to conform to. This, along with the changes in CalendarItem.swift, are a good starting place for understanding how this change works.

Details

This PR greatly simplifies the API for making CalendarItems. Once this change is merged, API consumers will no longer need to:

• figure out what styleIDs are / how to use them
• know that there's view recycling / reusing going on under the hood (related to styleID)
• understand what each of the CalendarItem closures does (there are no more closures 😄)

We're going from this:

.withDayItemProvider { day in
        let isSelected = day == selectedDay

        return CalendarItem<DayView, Day>(
          viewModel: day,
          styleID: isSelected ? "Selected" : "Default",
          buildView: { DayView(isSelectedStyle: isSelected) },
          updateViewModel: { [weak self] dayView, day in
            dayView.dayText = "\(day.day)"

            if let date = self?.calendar.date(from: day.components) {
              dayView.dayAccessibilityText = self?.dayDateFormatter.string(from: date)
            } else {
              dayView.dayAccessibilityText = nil
            }
          },
          updateHighlightState: { dayView, isHighlighted in
            dayView.isHighlighted = isHighlighted
          })
      }

to this:

.withDayItemProvider { [weak self] day in
        let dayAccessibilityText: String?
        if let date = self?.calendar.date(from: day.components) {
          dayAccessibilityText = self?.dayDateFormatter.string(from: date)
        } else {
          dayAccessibilityText = nil
        }

        return CalendarItem<DayView>(
          initialConfiguration: .init(isSelectedStyle: day == selectedDay),
          viewModel: .init(dayText: "\(day.day)", dayAccessibilityText: dayAccessibilityText))
      }

The core idea behind this change is that any view an API consumer wants to display in the calendar must conform to CalendarItemView. CalendarItemView has a required initializer for doing view setup, and a single function for updating the view model. I'm kicking myself for not looking into this before releasing 1.0 - it's really so much simpler 😅

Note that I won't merge this for some time. It's mostly complete, but I need to do more extensive testing to make sure this doesn't introduce any issues. Also, I can't merge this until version 2.0.0 since it has backwards-incompatible changes. There are a few things I'd like to merge into 1.X.X releases first, but then I'd love to push ahead on this in the new few weeks.

Related Issue

Inspired by this issue https://github.com/airbnb/HorizonCalendar/issues/29

Motivation and Context

Simplifying the API and making it way harder for for tricky bugs to happen.

How Has This Been Tested

Simulator. More to come.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [x] Docs change / refactoring / dependency upgrade
• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [x] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [x] I have added tests to cover my changes.

First of all, thanks for this amazing library.

I've noticed the following issue when using the library, the data is not being refreshed properly after fetching data from the server. I am attaching screenshots at the bottom.

example:

  var events: [String: Any] = [:]

  var presenter: CalendarPresenterDelegate!

  override func viewDidLoad() {
      super.viewDidLoad()
      /// some networking logic
      presenter.fetchEvents()
  }

  override func makeContext() -> CalendarViewContent {

        let startDate = Date()
        let endDate = calendar.date(from: DateComponents(year: 2021, month: 12, day: 31))!

        return CalendarViewContent(calendar: calendar,
                                   visibleDateRange: startDate...endDate,
                                   monthsLayout: .horizontal(monthWidth: min(view.frame.height, view.frame.width) - 40))
            .withDayItemProvider { day -> CalendarItem<EventLabel, Day> in
                let date = self.calendar.date(from: day.components)!
                let isSelectedDay = self.selectedDates.contains(date)
                return CalendarItem<EventLabel, Day>(
                    viewModel: day,
                    styleID: isSelectedDay ? "SelectedDayLabelStyle" : "DayLabelStyle",
                    buildView: {
                        return EventLabel()
                    },
                    updateViewModel: self.setupEvent)
            }
            .withInterMonthSpacing(16)
            .withVerticalDayMargin(8)
            .withHorizontalDayMargin(8)
    }

    func setEvents(events: [String: Any]) {
        self.events = events
        let newContent = makeContent()
        calendarView.setContent(newContent)
    }

    override func setupEvent(label: EventLabel, day: Day) {

        label.text = "\(day.day)"
        // clear the events
        label.hasNoEvents()

        if isSelectedDay {
            label.backgroundColor = Colors.colorAccent
        } else {
            label.backgroundColor = isToday ? Colors.colorPrimary : .clear
        }

        guard let object = getEvents(date: date) else {
            return
        }

        if (object["event1"] as? Bool) == true {
            label.hasEvent1()
            label.textColor = .lightGray
            return
        }

        if (object["event2"] as? [String])?.isEmpty == false {
            label.hasEvent2()
        }
    }

This is what we get after setEvents being called, however the result we need is in the second image: image 1 image 2

PS: if we scroll to September and back the UI refreshes and the UI updates properly. it seems as if the calendarView.setContent(newContent) is not setting the content properly.

Awesome, really glad that fixed the issue for you!

For what it's worth, I think having the color dots be part of your view model makes a lot of sense, particularly if that's data that might change a lot due to API response updates. If you want to speed up your rendering / repaint cost, you could implement those dot indicators using CoreGraphics in drawRect, or by just setting a dot view's isHidden / backgroundColor property if you want to keep using UIViews to represent the dots. I think either of those options will be cheaper than adding / removing subviews dynamically, which will cause auto layout constraints to churn a bit 🙂

Best of luck!

This has really got me thinking about ways to make this way simpler for developers... stay tuned 😄

@mustiikhalil ah, I see the problem! Thanks a bunch for the repro case... although I should have caught this from your original code snippet 😅

The problem is that you're using the updateViewModel closure to do configuration that is not captured by your view model. Internally, HorizonCalendar will only update views whose view model has changed - that's why the viewModel you pass in must be equatable - so that we know when a view has changed.

You'll need to refactor your code like this:

struct EventData: Equatable {
    let day: Day
    let hasEvent1: Bool
    let hasEvent2: Bool
}

...

 return CalendarItem<EventLabel, EventData>(
                    viewModel: EventData(day: day, hasEvent1: object.event1, hasEvent2: object.event2),
                    styleID: "Default",
                    buildView: {
                        return EventLabel()
                    },
                    updateViewModel: { label, eventData in
                        ...
                    }

This is a failure on my part for not making this clearer in the documentation. The key with these CalendarItem instances is that they try to force you to make your UIView a pure function of its view model, but there's no way to enforce this completely without rewriting UIKit.

One other side note - you only need to provide a custom styleID if you're using the same UIView subclass but with different initialization / setup properties. For example, if you used a UILabel with a red font for selected days, and a UILabel with a black font for unselected days, and this color was configured in the buildView closure, then you'd need to provide a different styleID for each variation. You can see this in the HorizonCalendar example code. If I had built the selection demo view controller by making the selected state part of the view model instead, then I would not need to use a styleID. Maybe that property needs a different name, or better documentation 🙂

Hi @Pattio - this is definitely a feature that we want to add support for! And I agree, manually messing with that internal scroll view is probably not a good idea.

I think we could probably support the programatic scrolling via buttons by having your code call:

public func scroll(
    toMonthContaining dateInTargetMonth: Date,
    scrollPosition: CalendarViewScrollPosition,
    animated: Bool)

But we'd still need the snapping behavior. I'll get around to working on this in the next few weeks!

As for RTL layout, I wonder what that would look like? Would the order of months change for the horizontal layout? I guess we don't support that right now, but that's a great callout. PRs are welcome if you'd like to tackle that one, but otherwise I'll leave this open so it's being tracked.

Hello! Love the library so far! Have a quick question.

Is it possible to have a fixed day header? Not sure what they are exactly called but here's a picture of it.

I haven't noticed there to be any item providers for them; or maybe I missed them??😅

Thanks a bunch and keep up the good work guys :)

Hi again @mosaic-engineering ! Glad you like the library 🙂

We support pinned days of the week for the vertical layout like this:

let layoutOptions = VerticalMonthsLayoutOptions(
  pinDaysOfWeekToTop: true, // this is the important line
  alwaysShowCompleteBoundaryMonths: false)
CalendarViewContent(
      calendar: calendar,
      visibleDateRange: startDate...endDate,
      monthsLayout: .vertical(options: layoutOptions))

We don't support this for horizontal layouts yet, but I will likely add support for this in the future!

Hi @rs658726 - do you mean something like this?

If so, my answer is: we don't have plans to support that right now, but if there's enough people asking for this, then maybe 🙂

Hi @mosaic-engineering , thanks for the proposed change. I think this is something that I could probably make clearer in the documentation. With that said...

These two structs are intentionally internal to the calendar, as only HorizonCalendar has the necessary pieces of information (a Date range and a Calendar instance) to be able to construct these. HorizonCalendar ensures that only valid Day / Month structs are created by always deriving them from the Calendar instance that you initialized CalendarViewContent with. If any consumer could construct these, then there could be programmer errors where invalid Days are created. For example, Day(year: 2020, month: 01, day: 500) makes no sense.

The basic philosophy is that consumers of the API always provide Dates and a Calendar instance to HorizonCalendar, and HorizonCalendar always passes Day and Month instances to you that are guaranteed to be valid for the current date range and calendar combination.

Having the right DayRangeItemProvider enum to apply the appropriate selection style for start/end dates

I think the key to solving your problem is knowing that you can always convert a Day to a Date. You can use let date = calendar.date(from: day.dateComponents)! to convert a selected day into a corresponding date. Make sure to use the same calendar instance that you used to initialize the CalendarViewContent otherwise you'll have some weird bugs due to calendar conversion issues!

I also think the example project code could be useful. I do a conversion from Day -> Date here for the purpose of using the withDayRangeItemProvider https://github.com/airbnb/HorizonCalendar/blob/master/Example/HorizonCalendarExample/HorizonCalendarExample/Demo%20View%20Controllers/DayRangeSelectionDemoViewController.swift#L121

Let me know if that solves your issue 🙂

@mustiikhalil glad you're finding the library useful 🙂

Some ideas:

• Is setEvents being called on the main thread? If not, that would definitely cause weird UI quirks. I should probably add an assert in setContent to prevent this / make it obvious what's wrong
• Have you set a breakpoint in setupEvent to make sure it gets called for each visible day after you call setContent? HorizonCalendar should invoke that function n times after you call setContent, where n is the number of currently visible days.

If neither of those suggestions lead you to an answer, if you could post some sample code (try to repro in the included example project if it's easy) I'd be happy to help investigate more!

Details

Improves the layout metric validation code used to determine if a horizontally-laid-out calendar has enough room to fit all of its calendar elements along the vertical axis.

Related Issue

N/A

Motivation and Context

This check wasn't quite right before.

How Has This Been Tested

Tested on simulator.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [ ] Docs change / refactoring / dependency upgrade
• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.

Details

This deprecates the public UIScrollViewDelegate functions on CalendarView - in v2.0, I'll hide this conformance in an internal type so that they won't even show up when users look at the autocomplete options after typing calendarView..

Related Issue

N/A

Motivation and Context

Prepping for 2.0 release which will make several API changes, including removing these functions from the public interface.

How Has This Been Tested

Tested using Xcode autocomplete.

Types of changes

<!--- What types of changes does your code introduce? Put an x in all the boxes that apply: -->

• [x] Docs change / refactoring / dependency upgrade
• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

<!--- Go over all the following points, and put an x in all the boxes that apply. --> <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.