JTAppleCalendar: Things go crazy with "Hide Bottom Bar on Push" - Progress to Infinite Scrolling

So the latest commits fixed the problem with the infinite scrolling, but they created another problem:

If you have the calendar on a view controller embedded on a tab bar controller and you push a new view controller on top of it using the option “Hide Bottom Bar on Push”, when you go back to the calendar it’s all wrong. It was driving me crazy, took me forever to realize the problem was that option.

I added an example here: https://github.com/dbmrq/JTCalTest/tree/third-attempt

Check out the third-attempt branch, run the app, go to the second tab, tap the “Push VC” row and then go back to the previous VC. You’ll see the calendar flashes and ends up at the wrong section. Then if you disable the “Hide Bottom Bar on Push” option on the second VC and try again it all works fine. This wasn’t happening a month ago, so it was caused by something on the last few commits.

That happens because I set the calendar height to be half the height of the view controller. So when you push a view controller without the tab bar and then go back to the controller with the tab bar it thinks the size changed and the calendar reloads and messes things up. So for now I can work around this by setting an explicit height for the calendar view, but this wasn’t happening before, and I think it would be better if we could change the height without any problems. Whatever the calendar view does when its height changes, it should do it before it’s even visible, and it should come back to the same section it was at before, so the change wouldn’t be visible at all, instead of the flash we’re getting now.

Like I said, for now I can just set the height explicitly, so this isn’t such a big deal, but I thought you should know about it. Cheers. 😃

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 43 (19 by maintainers)

Most upvoted comments

@patchthecode Any updates on the infinite scrolling?

Alright, I think that’s the safest option anyway. Thanks!

Yeah, I have to stick to Xcode 8 to be able to update my app. 🤷‍♂️

I don’t know how much time you have and when you’re going to implement infinite scrolling out of the box, but if you plan on doing it soon maybe it’s not even worth it to take too much time looking into this problem right now, since it’s only that bad because of the workaround we came up with in #403. With a better infinite scrolling solution (like this) no one would have to keep reloading the calendar so much, so the memory growth wouldn’t be much of a problem. Still it shouldn’t be happening and reloading the calendar should free the previous memory, but it wouldn’t be that bad.

Thanks for looking into all this. 😃

I updated the sample app with a “Reload 100000 times” button: https://github.com/dbmrq/JTCalTest/tree/memory-example

Just tap the button and watch the memory go crazy.

No problem. Happy holidays. 😃

Reload data should be used sparingly only because it recreates the layout. But this should never happen. Will look in a bit.