JZCalendarWeekView Versions Save

The goal of this v0.7.0 release is to redesign JZCalendarWeekView scroll pagination effect.

This issue is actually caused by using setContentOffset method to do pagination effect. The scenario is when users swiped view(willEndDragging called) then they swipe again or touch screen. The result might be

• Flickering view issue #40 #46 #51
• view stopped at the touch position(wrong position). For further touch screen description, you can refer to this StackOverflow question which is asked and answered by myself.

In order to redesign the pagination effect, I have to change setContentOffset method to settargetContentOffset and the property initialContentOffset set in willBeginDragging should be deleted because it shouldn't be considered. I don't care where it started, I only care where it should scroll to with the current state. Also, scrollSections for sectionScroll type has been deleted too.

In order to achieve this goal, some methods are refactored and fixed as well.

1. 3f976fb getDateForX, getDateForY and getDateForPoint are quite confused and misused in the past because the calculation method for gesture point x in UICollectionView is different from UICollectionView contentOffset x. As a result, those methods are refactored to 6 different methods, which are getDateForContentOffsetX, getDateForContentOffsetY, getDateForContentOffset (For contentOffset) getDateForPointX, getDateForPointY, getDateForPoint (For gesture point)

2. f027db9 ScrollDirection has been redesigned, the previous solution is actually implemented by WRCalendarView, which cannot get actual direction sometimes and it highly depends on the property initialContentOffset which we want to delete.

Unfortunately, two small issues are also introduced in this new pagination effect.

1. Even though I set the deceleratingRate to fast, the last few milliseconds of scrolling animation are still very slow, which is not as fast as setContentOffset.

2. Because of the first issue, it will take more time to scroll to the required targetContentOffset, if you scroll again at the same time, it won't work. It means you cannot scroll very fast to the third page only if the last animation finished and view reloaded.

If you have any good suggestions for the deceleratingRate issue, let me know.

One more issue fixed out of this goal is af9fc0a Fixed cell rendering issue #54 by replacing overlap calculation method

1. Replace the old, wrong and inefficient overlapping calculation method implemented by WRCalendarView to a correct and efficient way with complexity O(nlogn), which is from Maximum number of overlapping intervals.

2. Xcode 10.2 support

1. Fix JZLongPressWeekView scrollable range issue 56558f1a6cefa4c6b7e01b3ff8ceed71c0c2f96c
2. Fix vertical ScrollWeekView issue ed125ce2bd2b5527a842b0899f8a1131fe7846ce
3. Make JZColumnHeader dateFormatter public #43 a2dd6eadbffa918c3f10c312b8124998484456d9

1. Bugfix all-day scroll from bottom

Issue: When calendarView is scrolling at the bottom, and at the same time AllDayHeader height decreased, it will cause some view jumping and flickering issue. It is probably because the contentSize height become shorter, the view should scroll up automatically but it reaches the bottom currently, then it will cause that kind of issue.

Solution: Fixed this issue in quick swipe condition, but for slow swipe, I just keep the same height until the swipe ends.

2. Section grid width different in some cases #30

Issue: Because previous framework is using some nearbyint method to cast the CGFloat to int, which will cause the distance between different grid x might be different. As a result, when using sectionScroll, you will notice some events' sizes changed, actually they are the same, only because the grids distance is different.

Solution: Automatically increase the rowHeaderWidth if the sectionWidth cannot be Int. For sectionWidth decimal part, 0-0.25 -> 0, 0.25-0.75 -> 0.5, 0.75-0.99 -> +1 which means the rowHeaderWidth can only be changed within 0.25*numOfDays CGFloat, and it should be reasonable.

3. Fix AllDayHeader constraints issues & Improve AllDayHeader updateView logic For those iOS 9 devices, the Xcode console prints warnings when AllDayHeader height become 0 because the padding constraints being set to a value before. I added priority to the constraint to resolve this issue.

4. Update LongPressWeekView time label text access level #34

1. You can now set the horizontal scrollable range to control users' scrollable range.
2. Redo some reload methods, which will cause not reload issue when scrolling with sectionSection type

This release will change the visible time when weekView first time appears y offset, even if you don't change any code.

You can now set your own visible time in setupCalendar method with variable visibleTime, and the default value for it is current time. If you want something different, you can set this variable by yourself.

You can refer to the CustomViewController in example project. Also, a new open method can be used to vertically scroll the weekView.

open func scrollCollectionViewTo(time: Date)

1. Now you can customise your own current timeline as other supplementaryViews
2. Provided another type of timeline, but it is not 100% completed yet

1. Bug: For cross-day events, all cells in several sections cannot be hidden or translucent together

   • New variable id in JZBaseEvent is introduced to identify the same event in different cell

2. Bug: Once move the cell to another page, the previous cell contentView with alpha with be reused, and one random cell with another event will reuse that cell with translucent contentView.

   • New list allOpacityContentViews is utilised to store the translucent contentView, once cancel and end longPress, all the contentViews layer opacity will be reset back to 1
   • Change set alpha to layer opacity in case user set custom alpha value for contentView

3. Big issue: For both changing alpha or layer opacity for cell contentView, if user set cell background, then it will only work on view in contentView instead of background, which means the background color will not be transparent. However, if you set alpha or layer opacity for cell itself, when collectionView scrolling, the alpha will go back to 1 and will not call willDisplayCell.

   • The temporary solution is forcing users to set backgroundColor in contentView rather than cell itself

1. Improve the Move long press position relative to the long press view, for now, it will be the same as you originally press. (Same as Apple Calendar)

2. Fix a serious bug caused by CollectionView Reusability.

   • The CurrentMovingCell used before will be replaced when that reference is reused. Which could cause the editing reference totally wrong.
   • Also, with reusing, the editing cell will be refreshed if it has been reused, which means when you scroll back to that page, this event will be there instead of hidden or translucent.
   • In order to fix that problem, in Move longPress, the custom CollectionViewCell has to inherit from JZBaseEventCell in order to get the JZBaseEvent and find the original editing cell because of the reusability of UICollectionView