Jtapplecalendar: Rotating the screen does not place calendar at the same offset

[rp4rk]

Currently having an issue where rotating the screen sets the date back or forward depending on clockwise/anticlockwise rotation. Anyone experienced this? I think it may be related to having a calendarview with dynamic width.

[patchthecode]

What do you mean by rotating the screen sets the date?

Or maybe you can tell me this: What do you want happen when you rotate the screen?

[rp4rk]

For example, I create a calendar and have the month displayed set to the current date. When I rotate the screen, the month/year suddenly changes +- 8 years depending on a clockwise or counter-clockwise rotation.

[patchthecode]

Basically you're saying that the calendar scrolls to a new position when you rotate?

[rp4rk]

Yes.

[patchthecode]

OK I see the problem. Updates will be done there to fix this in the next release (which will be soon).
In the mean time, you might have to try fix the problem your self if you are up for it.

[patchthecode]

fixed.

[Ferannor]

I'm sorry to re-open this issue but I'm v7.0.6 from CocoaPods and I've the same issue. Each time I rotate my device, my calendar scroll to the first month.

[dbmrq]

I had this same problem and I solved it by doing this:

extension UICollectionViewFlowLayout {
    open override func shouldInvalidateLayout(forBoundsChange newBounds: CGRect) -> Bool {
        return true
    }
}

And adding reloadData(withanchor:) to viewWillTransition(to size:), viewDidLayoutSubviews() and viewWillAppear(). (You have to save the last selected date to use it as the anchor.)

It seems like overkill to reload the data on all those events, but if I don't I'll eventually run into some quirks. Just reloading on viewWillTransition(to size:) fixes it for when the user is looking at the calendar and rotates the device, but there's still a problem if the user goes to a different view controller, rotates the device there and then goes back to the calendar in a different orientation, so we need to do it at viewWillAppear() too. And then if I don't do it on viewDidLayoutSubviews() I'll get some random weirdness every now and then, I don't know why.

With all that things are working pretty well for me, though. I think shouldInvalidateLayout(forBoundsChange) should already default to true for the calendar's layout, and it would be great if I didn't have to keep calling reloadData(withanchor:) all the time, but it's not a huge problem.

---

Edit: I just checked my code and I also have to scroll the calendar after reloading the data. I have this function:

    var firstVisibleDate: Date? {
        return calendarView.visibleDates().monthDates.first?.date
    }

    func reloadCalendar(on date: Date, completion: (() -> Void)? = nil) {
        calendarView.reloadData(withanchor: date) {
            if self.firstVisibleDate?.startOfMonth != date.startOfMonth {
                self.calendarView.scrollToDate(date, animateScroll: false) {
                    self.calendarView.selectDates([date])
                    completion?()
                }
            } else {
                self.calendarView.selectDates([date])
                completion?()
            }
        }
    }

And I call it on viewWillTransition(to size:), viewDidLayoutSubviews() and viewWillAppear().

Pretty ugly, but it's the only thing that fixed my problems with the orientation.

[patchthecode]

@dbmrq man.. i had no idea it was this painful for you guys D:
I'll get on this right away

[dbmrq]

Haha, no problem. Thanks for looking into it. :)

[Ferannor]

@dbmrq Well done! This is a nice walkaround! I'll try it!

@patchthecode Thanks! Sound like a regression to me. But maybe I'm wrong.

[patchthecode]

@Ferannor @dbmrq

ok, in your ViewController implement your viewWillTransition function.

override func viewWillTransition(to size: CGSize, with coordinator: UIViewControllerTransitionCoordinator) {
  // First get the index path that you want to focus to
   let indexPath = calendarView.visibleDates().indates.first?.indexPath

   // Call the function with the path
   calendarView.viewWillTransition(to: size, with: coordinator, focusDateIndexPathAfterRotate: indexPath)
}

Try this by updating to master branch in your pod file.

pod 'JTAppleCalendar', :git => 'https://github.com/patchthecode/JTAppleCalendar.git', :branch => 'master'

Let me know if this works

[dbmrq]

I'll try it in a couple of days when I have the time. Thanks for looking into it. :)

Just one thing I don't know if you considered: can this be called in viewWillAppear() without any problems? Because like I said, the calendar also breaks if you go to a different tab, rotate the device there and then go back to the calendar's tab.

[patchthecode]

@dbmrq
hmm. ok, the function

override func viewWillTransition(to size: CGSize, with coordinator: UIViewControllerTransitionCoordinator)

is a ViewController delegate function (not a calendar function). It is called every time the ViewController changes orientation. You should not need to put any thing inside viewDidAppear (although you can if you want to).

override func viewWillTransition(to size: CGSize, with coordinator: UIViewControllerTransitionCoordinator) {
  // First get the index path that you want to focus to
   let indexPath = calendarView.visibleDates().indates.first?.indexPath

   // Call the function with the path
   calendarView.viewWillTransition(to: size, with: coordinator, focusDateIndexPathAfterRotate: indexPath)
}

In regards to If you are on another tab? One sec. Let me add one more tweak to the fix.

[dbmrq]

Yes, at first I know it's not necessary to call it on viewWillAppear(), but viewWillTransition() isn't called on the calendar's VC if the transition happens in another VC (like another tab). So the calendar has to be fixed somewhere else in that case.

I think ideally the user wouldn't even have to do anything to fix it… maybe calling that new calendarView.viewWillTransition() on the calendar's layoutSubviews() or something like that? I don't know.

Anyway, I couldn't test it yet, but just the existence of a calendarView.viewWillTransition() function already helps a lot, thanks. :)

[patchthecode]

@dbmrq ok i have updated the function. I think it should now work like you want.

override func viewWillTransition(to size: CGSize, with coordinator: UIViewControllerTransitionCoordinator) {
   calendarView.viewWillTransition(to: size, with: coordinator, focusDateAfterRotate: myDate)
}

[dbmrq]

Thanks, I'll check it out soon. :)

Em dom, 20 de ago de 2017 às 04:53, JTAppleCalendar <
[email protected]> escreveu:

@dbmrq https://github.com/dbmrq ok i have updated the function. I think
it should now work like you want.

override func viewWillTransition(to size: CGSize, with coordinator: UIViewControllerTransitionCoordinator) {
calendarView.viewWillTransition(to: size, with: coordinator, focusDateAfterRotate: myDate)
}

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/patchthecode/JTAppleCalendar/issues/142#issuecomment-323569918,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APFMKrf9zYQpki0j6oPtpB1zh1D2c_yAks5sZ-YPgaJpZM4J98fL
.

[patchthecode]

@dbmrq FYI, i changed the function signature again to something more consistent.

override func viewWillTransition(to size: CGSize, with coordinator: UIViewControllerTransitionCoordinator) {
    calendarView.viewWillTransition(to: size, with: coordinator, anchorDate: iii)
}

Will await your testing response. Cheers 🍻

[patchthecode]

@dbmrq i am facing some issues when i try it with your 3rd try branch. Looking into it.

[dbmrq]

No problem, for now it's all working fine for me by doing what I said
before, so there's no hurry. Sorry I couldn't look into it yet.

Em dom, 20 de ago de 2017 às 15:53, JTAppleCalendar <
[email protected]> escreveu:

@dbmrq https://github.com/dbmrq i am facing some issues when i try it
with your 3rd try branch. Looking into it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/patchthecode/JTAppleCalendar/issues/142#issuecomment-323604171,
or mute the thread
https://github.com/notifications/unsubscribe-auth/APFMKlDFRFaVZLjP1Vya5KXyTS_nkzPHks5saICWgaJpZM4J98fL
.

[dbmrq]

I just tried the latest code and it's a huge improvement on this regard. Thanks!

I'll test it more thoroughly on the next few weeks, but for now I think this is fixed. 🍾

[patchthecode]

So i guess this issue is now resolved?
If it is, I will now close this.
And i will look at the other issue, you have opened here -> https://github.com/patchthecode/JTAppleCalendar/issues/470

[dbmrq]

Yes, I only tested it briefly, but as far as I'm concerned this issue can be closed. :)

I just didn't close it myself because I can't speak for the orher users and use cases here.

[patchthecode]

I have tested it in side tabBar, outside tabbar, inside superviewCOntainer and outside container. It works. I'll close this issue now.