patchthecode / JTAppleCalendar

The Unofficial Apple iOS Swift Calendar View. Swift calendar Library. iOS calendar Control. 100% Customizable
https://patchthecode.com
MIT License
7.56k stars 806 forks source link

Changing first day of the week brakes calendar layout #57

Closed kristof4ad closed 8 years ago

kristof4ad commented 8 years ago

Hi, When in viewDidLoad it's self.calendarView.firstDayOfWeek = .Sunday calendar looks good simulator screen shot 27 jun 2016 17 11 12 but when changed to: self.calendarView.firstDayOfWeek = .Monday Layout brakes and it looks like that: simulator screen shot 28 jun 2016 09 49 10

patchthecode commented 8 years ago

What version are you using? The issue is related to you iOS simulator orientation messing up

Do a clean. Switch orientation to horizontal, then back to vertical (potrait) should fix it. Or just use version 4.0.3. I put code in there that should fix it.

If youre already using 4.0.3., then let me know

kristof4ad commented 8 years ago
patchthecode commented 8 years ago

I have experienced this with one other user. The symptoms are just like you described. The thing is, it was some simulator error. After closing his calendar app. Then by switching the simulator from landscape to potrait, the error was resolved. The error is not experienced on my side.

Since you can consistently reproduce the error, can you check this out for me?

In JTAppleCalendarView.swift file, there is this function:

override public var frame: CGRect

Inside that function , I have a line of code that says this:

if orientation == .Unknown {
   return
}

If the orientation of the application is unknown, then i do a return there. The Bug happens here (if you are experiencing the same thing). Apparently, for some weird reason, the orientation of the app remains unknown. So it returns. And because it returns, it does no set the size etc for the calendar, therefore everything is squished together. After investigating with another user with the same problem, he toggled his orientation on his simulator. And without a single line of code, it started picking up the correct orientation again.

So

  1. Can you compare that .Sunday doesnt return but .Monday does? Note this method maybe called more than once, but on the last time the orientation should be known.
  2. Is this happening on the sample app?
patchthecode commented 8 years ago

Btw, In the latest update on master branch, I have an update for vertical users like you. You can now stretch you calendar to the length of you screen. Before, the cells would stretch to the size, but with the new update, you can specify your size to make it smaller or lager.

emcphersonburke commented 8 years ago

FWIW, this was happening for me because I was triggering JTAppleCalendarLayout's applyLayoutAttributes method (via an attempted scrollToDate within my VC's viewDidLoad, which was a silly idea in the first place) before the JTAppleCalendarView had a chance to fire off updateLayoutItemSize, so the zero width itemSize was cached.

patchthecode commented 8 years ago

@emcphersonburke you should be able to scroll to date in the viewDidLoad() section without problems. Can you paste me your viewDidLoad() setup code? This has never happened to me before in the sample app provided on github.

This seems to now have happened to 4 users. Any help in fixing this condition will be a HUGE plus for this project. If you are able to send me the some sample code that consistently causes this bug to appear, I will be grateful.

kristof4ad commented 8 years ago

Hi I tried to comment out: if orientation == .Unknown { return } but it didn't helped and orientation.rawValue = 1 my app has only Portrait device orientation Changing settings to calendarView.direction = .Vertical has no effect

emcphersonburke commented 8 years ago

@patchthecode My day is gonna be kinda nuts, but I'll try and get you a simple repro either tonight or tomorrow. There did seem to be some race condition in which applyLayoutAttributes would sometimes get hit before updateLayoutItemSize, thereby caching the zero size and subsequently always returning it in sizeForitemAtIndexPath. Checking for and disallowing a zero size in the cache seemed to fix it, but I had to roll back my changes before playing with it much more because I'm currently on a tight deadline.

Also, FWIW, my calendar doesn't have any headers registered with it if that information helps at all.

Sorry for the delay on further info!

patchthecode commented 8 years ago

@emcphersonburke thanks man. THis slow chat here is killing me. I wish i could get this resolved faster, but i'm not able to reproduce this.

patchthecode commented 8 years ago

@emcphersonburke @kristof4ad I believe I have fixed the issue. I have committed the latest code to the master branch. If someone can test this code and all is fine, then i will release the next version.

emcphersonburke commented 8 years ago

@patchthecode Nice! From what I can tell, that took care of that specific issue. I phrase it like that because recent commits have caused another UI glitch. I'm attaching this example project here since it would also demonstrate the above problem, but please let me know if I should open up a separate issue. I ripped this out of a project I'm working on, so apologies if it's a little sloppy. When I wasn't seeing the behavior described above, I was seeing this:

screenshot

It was seemingly random whether the calendar would display like this or like the bug described above (though it appeared to relate to how quickly after launch I hit the Show Calendar button), but FWIW, I'm now only seeing the empty cell behavior in this screenshot. If I revert to 4.0.2, this does not occur.

I'll be happy to help track down the source of this over the coming weekend if you don't find the culprit beforehand.

JTCalendarExample.zip

patchthecode commented 8 years ago

checking it out now.

patchthecode commented 8 years ago

@emcphersonburke I updated the code. Here is your code updated with the latest from the repository. I also updated your viewDidAppear() code to make is more concise. JTCalendarExample.zip

The latest code is on master branch

emcphersonburke commented 8 years ago

Awesome, I dropped the changes in my main project and it now works beautifully 100% of the time! Thanks so much

patchthecode commented 8 years ago

@emcphersonburke man, you should have told me you were having so many issues earlier. I need to know when there are bugs even in the slightest.

Anyway, youre welcome. I'll release next version as soon as I do more testing, or if you guys dont find more bugs.

emcphersonburke commented 8 years ago

@patchthecode Hah, sorry about that. I'd actually been running off my 4.0.2 fork until earlier this week, so I had just run into them trying out the latest and greatest. Will be sure to report anything else fishy I might run into, but it's been running great all day for me!

patchthecode commented 8 years ago

@kristof4ad your bugs are now fixed on master branch. Will release new version soon.

patchthecode commented 8 years ago

@emcphersonburke 4.0.3 has some performance enhancements over 4.0.2. It runs smoother on iPhone 4s old phones. So switch whenever youre ready.

patchthecode commented 8 years ago

Released version 4.1.0 closing this issue