Crash when switching numberOfRows to 1, then back to 6 and modifying the calendars height

[numen31337]

When I trying to switch calendar to the week mode and back by setting numberOfRows to 1 and then back to 6, simultaneously modifying the calendars height I have the crash:

Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'attempt to delete item 36 from section 0 which only contains 7 items before the update'

I've attached the sample project where this crash can be reproduced by clicking Jan 31 for 3 times

Sample project: https://www.dropbox.com/s/lle6kuf93n8ptbi/CrashTest.zip?dl=0

[patchthecode]

ok i'll have a look

[patchthecode]

It works fine.

What version of iOS and XCode are you using?
I have only tested this library in XCode 8.2 iOS 10.2

[numen31337]

I checked it on both regular and beta versions of Xcode and on the device also, I have this crash everywhere, it looks for me like some issue with threading because the only solution to avoid this crash that I found it to call this switch like so:

func calendar(_ calendar: JTAppleCalendarView, didSelectDate date: Date, cell: JTAppleDayCellView?, cellState: CellState) {
        //temp crash fix
        DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) {
            self.weekMode = !self.weekMode
        }
    }

[patchthecode]

ok. One thing, can you use the latest master branch code and let me know if you have the issue there? I just tested on master branch code and i cannot reproduce it.

If you have the error there as well, then I will have to debug this over the weekend.

[patchthecode]

Also, can you let me know if you are seeing this iOS 10.2 ?
I do not have 10.3 yet. I am downloading it to test it now.

[patchthecode]

In the code you gave me, i see this -->

    func calendar(_ calendar: JTAppleCalendarView, didSelectDate date: Date, cell: JTAppleDayCellView?, cellState: CellState) {
        weekMode = !weekMode
        self.calendarView.scrollToDate(date, triggerScrollToDateDelegate: false, animateScroll: false, preferredScrollPosition: nil, completionHandler: nil)
    }

can you comment out this line?

self.calendarView.scrollToDate(date, triggerScrollToDateDelegate: false, animateScroll: false, preferredScrollPosition: nil, completionHandler: nil)

I want to isolate which line of code is causing the threading issue.
Let me know if the crash still exists with that line of code commented.

[numen31337]

I checked it with the latest version from the master and issue still exist even with commented scroll on iOS 10.2 simulator

[patchthecode]

Alright. Thanks.
Looking more into it.

[patchthecode]

One last thing can be of help.
Can you paste me the entire crash log in text here?

[numen31337]

2017-02-15 18:15:44.272 CrashTest[67303:28667410] *** Assertion failure in -[UICollectionView _endItemAnimationsWithInvalidationContext:tentativelyForReordering:animator:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIKit_Sim/UIKit-3600.6.21/UICollectionView.m:5422
2017-02-15 18:15:44.280 CrashTest[67303:28667410] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'attempt to delete item 36 from section 0 which only contains 7 items before the update'
*** First throw call stack:
(
0 CoreFoundation 0x0000000105adad4b __exceptionPreprocess + 171
1 libobjc.A.dylib 0x00000001026da21e objc_exception_throw + 48
2 CoreFoundation 0x0000000105adee42 +[NSException raise:format:arguments:] + 98
3 Foundation 0x000000010226f66d -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 195
4 UIKit 0x0000000103c126a1 -[UICollectionView _endItemAnimationsWithInvalidationContext:tentativelyForReordering:animator:] + 6117
5 UIKit 0x0000000103c1de72 -[UICollectionView endUpdatesWithInvalidationContext:tentativelyForReordering:animator:] + 71
6 UIKit 0x0000000103c1e1b4 -[UICollectionView performBatchUpdates:completion:invalidationContext:tentativelyForReordering:animator:] + 432
7 UIKit 0x0000000103c1dfe1 -[UICollectionView performBatchUpdates:completion:invalidationContext:tentativelyForReordering:] + 91
8 UIKit 0x0000000103c1df63 -[UICollectionView performBatchUpdates:completion:invalidationContext:] + 74
9 UIKit 0x0000000103c1deb8 -[UICollectionView performBatchUpdates:completion:] + 53
10 CrashTest 0x0000000102051efc TFFC9CrashTest19JTAppleCalendarView21batchReloadIndexPathsFGSaV10Foundation9IndexPath_T_U_FT_T + 764
11 CrashTest 0x000000010200ceb7 TTRXFo___XFdCb + 39
12 UIKit 0x0000000103376239 +[UIView(Animation) performWithoutAnimation:] + 90
13 CrashTest 0x0000000102051bd0 TFC9CrashTest19JTAppleCalendarView21batchReloadIndexPathsfGSaV10Foundation9IndexPath_T + 304
14 CrashTest 0x00000001020520a9 TToFC9CrashTest19JTAppleCalendarView21batchReloadIndexPathsfGSaV10Foundation9IndexPath_T + 73
15 CrashTest 0x000000010205b7f6 TTSf2n_i___TFFC9CrashTest19JTAppleCalendarView22internalCollectionViewFTCSo16UICollectionView26didDeselectItemAtIndexPathV10Foundation9IndexPath18indexPathsToReloadGSaS3___T_U_FT_T + 86
16 CrashTest 0x000000010200ceb7 TTRXFo___XFdCb + 39
17 libdispatch.dylib 0x0000000106a14978 _dispatch_call_block_and_release + 12
18 libdispatch.dylib 0x0000000106a3e0cd _dispatch_client_callout + 8
19 libdispatch.dylib 0x0000000106a1e8a4 _dispatch_main_queue_callback_4CF + 406
20 CoreFoundation 0x0000000105a9ee49 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 9
21 CoreFoundation 0x0000000105a6437d __CFRunLoopRun + 2205
22 CoreFoundation 0x0000000105a63884 CFRunLoopRunSpecific + 420
23 GraphicsServices 0x00000001089eea6f GSEventRunModal + 161
24 UIKit 0x00000001032bcc68 UIApplicationMain + 159
25 CrashTest 0x000000010201b08f main + 111
26 libdyld.dylib 0x0000000106a8a68d start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)

[patchthecode]

Thanks. I have now replicated the issue

[patchthecode]

Thank you for the help.
Here is your fixed project.
CrashTest.zip

That zip file has the latest master branch code.
Let me know if it works for you.

[patchthecode]

The bug was caused by this --> f368553 which is now fixed.

I also made another change to the master code: Calendar reload should not be done automatically when a user changes the frameSize. This should be done by the developer.
This change is also reflected in the zip file i just gave you.

[numen31337]

In some reason, in this new version, it sometimes shows the wrong position in the week view and after clicking to get back to month view just silently crash

[patchthecode]

OK, you're using the same code i gave you?
Let me check by clicking on those 2 dates you showed in the image above.

[numen31337]

Yes, the code is unchanged, just clicking some same dates, I had this crash by clicking 1 and 31 also

[patchthecode]

Alright. Its something i probably missed. Let me look into it very closely.

[patchthecode]

Hey, here is an update code.
CrashTest.zip

Let me know if it is crashing for you.
I have updated the reload() logic and removed multithreading.

[numen31337]

The old crash is gone but I see the other issues here.

1. The InDates of Jan is not clickable at all, delegate is not being called for them
2. When you press 31 Jan and then click on the other day it will crash:
   
   It stops crashing if you scroll to the next week and then go back and click, looks like something wrong with the initial collection
3. When you click 31 Jan, for example, you will see wrong scroll position which shows the beginning of the Jan, not the Feb
   

[patchthecode]

Ok. Looking ino it.

By the way.

The InDates of Jan is not clickable at all, delegate is not being called for them

This is expected. The new code that will be released will have this logic. The indates for Jan is outside of your startDate and endDate boundary. Therefore they are unclickable. Do you have any good ideas on how I can make this logic better?

Let me now look into Error(2) and Error(3)

[numen31337]

As an end user I would really expect complete consistency across the app, so if an application has some behavior to do something when you click on a day then this should happen no matter what. The issue here is that developers don't have control over this behavior without making some calculation to specify this start date correctly, taking in count InDates. This is the actual question for the apps which is relying on the week view because just hiding unused days will look not really good. Of course, this is up to you to decide such things.

[patchthecode]

@numen31337 I see what you mean. Thanks for the input. I will remove this in next version then. What you said makes sense.

Will look into those 2 other errors in the morning. Have a goodnight man.

[patchthecode]

@numen31337 Your issue(3) is expected.
In your code, you have the scrollingMode set to default
But there are many scrollingModes you can choose from as shown in the Calendar Scrolling Section of the tutorials.

Here is your updated zip file. I have changed your scrollingMode to nonStopToCell as described in that link above. If this is not the scroll style that you want, then pick one that matches your needs.

Also, I have fixed some more threading issues. Can you let me know if you are still experiencing the crash? Because the crash is hard for me to reproduce, I have to fix this by looking at the logic. So I hope you don't mind if this is taking a while 😄

Edit [ Removed File ] fixing one last part

[numen31337]

Hi, looks like the crash is gone but I still have the issue with the scroll function. Probably I misunderstood something, I've tried few scroll positions but this is not solving the issue:

When I click 28 or 29 Jan or most of the other days it scrolls to the correct position but then I press 30 or 31 Jan it scrolls to the beginning of the calendar or just resets scroll position

[patchthecode]

Yes, that is the last part that i have to fix. I see why the issue is happening. Working on it now.

[patchthecode]

Try this new build.
Let me know if your issues are resolved.

CrashTest.zip

[patchthecode]

There is one more issue i need to fix with it. You will get an update in about 3-4 hours.

[patchthecode]

Because you changed the size of your calendar and reloaded at the same time, this caused your project to reveal many issues.

Here is the latest build. I have tested and could not find any other issue. If the build is good, I will include these changes to the master branch. Thanks for helping reveal these issues.
CrashTest.zip

If there is still an issue somewhere, then let me know. And I will fix.

[numen31337]

Looks like there is still inconsistent behavior with scroll:

It happens for at least stopAtEachSection and stopAtEachCalendarFrameWidth scrolling modes. I trying to scroll and stop on weeks in the week mode.

Also once there was some silent crash as it was before, can't reproduce it more for now, but it was for sure when I was clicking 30 and 31 Jan back and forward.

[patchthecode]

After investigating, it seems that scrollRectToVislible is not reliable.
I'm not sure the reason why that it.

I checked the math and every thing is correct.
A google search showed me that many other people are experiencing the same problem scrolling to rect.

I have now changed the scrollRectToVislible code to
self.calendarView.setContentOffset(point, animated: isAnimationEnabled)

This seems to work as expected.
If all is ok on this build I will re-work the code in Master branch.
CrashTest.zip

The only thing left to fix with this build is an existing scrolling issue. Let me know your findings.

[numen31337]

This version looks much better, I unable to reproduce the crash and even scrolling is working, at least I can't reproduce miss scroll for now.

[patchthecode]

Awesome. I'll begin moving the changes over to master branch.

[patchthecode]

Fixed on latest master branch.
closing issue.