Have you checked the wiki? --> https://github.com/patchthecode/JTAppleCalendar/wiki/Common-Questions. I think question1 should have what you're looking for.

That was right in front of my eyes but I didn't see it. Thank you!

It's shaping up real nice. You'll notice that where the gray dates used to be there is a lot of white space. Is there a row spacing attribute or otherwise a way to reduce this spacing due to the missing row? Otherwise I'm basically done and problem solved.

Here are your options of what can be done about the space. They are listed in order of difficulty/time constraints. Pick one 😈

• Implement headers as shown in the sample app here on git hub. Headers will take away from the "empty look"
• Wait for the update over the weekend (HOPEFULLY if I don't get tied up with my work.. and i do get tied up quite often, so keep both your fingers and toes crossed). The update will allow you to have a smaller height thereby making the space look less noticeable.
• Wait for my later later upgrade. This will have the ability to not generate outdates. Therefore there wont be a space to worry about.
• Help me by taking a pull request and doing the code for me while I work on other features.

Hi @patchthecode, I'm also trying to change the number of rows to 5 and it's always displaying 6 rows. It's weird because if I try to change the number of rows to anything below 3 its works fine.

@victtavares check out the Wiki question 2. I just updated it.

I'm also looking forward to this feature.
Just one more thing to consider: I think in horizontal scroll mode the height of the calendar view should be adjusted, instead of just redistributing the visible rows in the available space (which I assume will be done for vertical scroll mode).
So we could do something like this out of the box:

To accomplish this now I'm resizing the bottom constraint, which works, but it's not the most elegant solution.

@dbmrq

I am currently working on this code. It is the final massive upgrade to this calendar. Then this library will be complete. I cannot foresee any other major updates that this library will need after it is complete.

Concerning how it will look, I will not let it auto adjust like the other calendar frameworks. I think this is bad design. By making it autoadjust, the library is assuming that the developer wants to do this. This is not how a control should be.

What I will do is add a parameter to the the following function. Currently this function informs the developer when a screen is scrolled.

func calendar(calendar: JTAppleCalendarView, didScrollToDateSegmentStartingWithdate startDate: NSDate, endingWithDate endDate: NSDate)

I will add a parameter which describes, the number of rows in the visible section, and the size of the frame. Now if the developer wants to resize the calendar, then he can do so if he chooses using what ever animation code he wants.

The upgrade I am working on is a huge change. Currently this calendar operates on the basis that the calendar is a 7 x 6 grid. i.e 42 items on screen. I have realized that this is not always the case in months that have 5 rows instead of 6 rows.

So the upgrade will also allow a dev to choose how he wants to generate the date cells. He can choose:

1. To turn pre-Dates on or off
2. To turn end-Dates either off, tillEndOfRow (which is what you currently want) or tillEndOfGrid (which is how it currently is right now)

I am not sure if I explained it clearly, but this will be a good idea right?

Sounds awesome. :)

You're right, I meant the resizing as an option, not something that should be imposed. The changes you mentioned would already be a huge help, and it fits with the library's philosophy of letting the user set things up himself.

That being said, I see you're trying to make JTAppleCalendar more popular, and I think it definitely deserves to be, so here are my two cents. A while ago I was looking for a calendar library to use in my app and I came by yours and also a few others. I ended up going with CVCalendar just because it seemed easier to set up. But boy, I was wrong. I ended up having to pretty much rewrite the whole library from scratch to make it work for me, and the code is really confusing. Now with swift 3 coming up I'd have to update all that awful code again and I decided to give JTAppleCalendar a try instead. I'm really glad I did, it was a lot easier to set things up and I got it exactly how I wanted in no time. It doesn't look that way, though. I think it would be a good idea to come up with a sort of a default implementation, something the user could drag and drop and start using while changing as little as possible. I don't think that would be very hard at all. The calendar could return a standard dayView and if users wanted to customize it they could just override it. And the same goes for animations and the resizing I mentioned and stuff like that. All that should definitely be customizable and up to the user, but I think the library would attract a lot more users if it came with that stuff already set up and if a user wanted to change it he'd just override a couple of methods and that's that.

Anyway, it won't make much of a difference to me, since I already set up the calendar the way I want, it's just a suggestion that I think would make your library more popular. "More popular" isn't necessarily best, though, so I totally get it if you prefer to stick with the current DIY philosophy.

Congratulations on your great work. It really is the best swift calendar on GitHub. 😉

@dbmrq wow. Thanks for your kind words! And your advice makes a lot of sense. I really like the DIY approach, but it seems programmers are lazy :/

So I will follow your advice.
I will still have it DIY, but I will have initial setup code in such a simple manner, that all the developer has to do is copy and paste it. From there, they can customize the library as they please.

Also, This library already has a swift 3 branch in case you were wondering. I will try to finish this massive update within the next 1.5 weeks.

Again thanks.
Btw, If you have any ideas that I have missed, do let me know. I want this library to be number#1
Cheers.

@dbmrq one last question though, was the screenshots of what users have created with calendar helpful in choosing this one? --> #2

I thought this page would encourage devs to use it, but it seemed you still passed it by.

@patchthecode

Well, the first time I looked here the screenshots weren't there yet I think. They do help with an idea of what you can do with the library, but at the same time they can make the users even less sure of what they will do, so I'm not sure it's the best headline. I think it would be better marketing to have a minimal readme with a couple of very simple screenshots and some text that says "do this, this and this and you'll get a calendar like that one in the screenshots". Then if a user comes here and he has a certain idea of what he wants he'll think "ok, I can use this and just change a couple of things and I'll get what I want". If there are 20 completely different screenshots, on the other hand, he'll think "well, I can do something great with this library, but I can also do something awful and it looks like it'll take a lot of work". I think the customization possibilities are really important, but only only at a second stage when the user is already sold on the library. After the initial setup there could be a couple of links… "Ok, you got your calendar running, now look at all you can do with it. Cool, right? Here's a tutorial."

With CVCalendar, for instance, I saw a screenshot of what it looks like straight away and I thought "ok, this is pretty close to what I need, I'll just change the font, the color and remove that ugly line". But then when I tried to actually do all that it was really hard to do it and I had to change the whole library to suit my needs. JTAppleCalendar is the opposite, I came here and I thought "ok, I'll have to do the whole thing from scratch", but then I realized how easy it was and got it running in no time. That's a lot better, of course, but I think it would be even better to join the best of both worlds. The user would see a simple calendar he can just drag and drop and think "ok, this is almost ready, I'll just change a couple of things"… and then when he tried to change them it would be really easy, like it already is. That's pretty much the whole Apple approach I guess, give users a single option and make it a very good option, instead of, say, the Arch Linux approach, which gives users every possible option and then they have no idea what to do unless it's their third attempt already.

This is just my opinion, of course, and I'm sure a lot of people think the exact opposite.

@dbmrq see why I wished you were here giving advice when I started this? Haha, you make a lot of sense man. I will update the readme and the code etc as soon as I finish this final code update.

@dbmrq How to resize the bottom constraint of the calendar view? I mean how do I know it the month will have 6 rows? I am facing the same issue.

@patchthecode The screenshots of what users have created with this calendar were very helpful in choosing this one over other calendars. Keep up the good work!

@Ashu

    func numberOfRows(forDate date: NSDate) -> Int {
        let weekday = date.startOfMonth().weekday
        let monthDays = date.startOfNextMonth().addDays(-1).day
        // These methods are declared in an NSDate extension,
        // it shouldn't be too hard to come up with your own

        if weekday == 1 && monthDays == 28 {
            return 4
        } else if weekday < 6 || (weekday == 6 && monthDays < 31) || (weekday == 7 && monthDays < 30) {
            return 5
        } else {
            return 6
        }
    }

@Ashu thanks.

@patchthecode

Hi I have an issue with calendar, if I change the Height of the calendar view dynamically. and try to scroll to previous or next month, It jumps to first month, which is set during configuring. How can we restrict this issue?

@vasant-indpro can you open a new issue for this?

and in the new issue, let me know how you are changing the height.
Because this is expected. The second you change anything which will cause the cell's height to change, the layout of the calendar needs to be reset. Let me know in the new issue, and we'll find a solution.

@patchthecode This issue is there in your demo project as well.

Steps as Below

• When I open calendar lands on current month(Ex: 21-Nov-2017)
• I scroll to next month(Any upcoming month) (Ex: Feb-2018)
• I tried to Resize the calendar, I could do it.
• Now if I try to scroll calendar, It lands on first month instead of staying there itself.

Can you get this fixed Please?

Because My requirement is that, I need to change the height of calendar based on the number of rows of the particular month. instead of Stretching my calendar cell height.

Thanks in Advance.

@vasant-indpro this is not an issue to be fixed.
This is what happens if you change the height of a UIcollectionView with cells that adjust height.

There are two ways to work with it:

1. You can reload with an anchor date so that it wont reset. I wont explain this one because i believe that number (2) below will work for you.
2. you can do what this guy did with JTApplecalendar to adjust height -> https://github.com/patchthecode/WLAppleCalendar

Let me know if the 2nd one works for you.

@patchthecode This works fine for me. I appreciate your help. Thanks.

Somehow @kristophM was able to completely eliminate the cells representing dates in the previous and next months, as he asked in Question 2 here.

You mention that the solution is in the wiki, but I don't see any questions relating to this behavior.

You mention here that you were adding a feature to disable pre-dates and end-dates. Was this ever implemented? How did @kristophM disable those dates?

Thanks for the library!

@mymikemiller

Yes, this was implemented long time ago.
What do you want to do with those cells?

Disable them? (make them unclickable)
Or make them invisible?

Best thing to do is, Show me a screenshot of the calendar you want, and i wil ltell you the configuration.

I'm looking to get a calendar essentially exactly like the picture @kristophM posted here, where the dates from the previous and next month don't show up (and aren't clickable).

If I turn generateInDates off, the first of the month appears as the first cell instead of under the proper day header, and if I set it to forFirstMonthOnly (as the video recommends), the cells are pushed to their correct location, but the in-dates then show up which is no good.

I want these cells to appear as blank, white unclickable cells, like here

I don't care if there is sometimes an extra blank row at the bottom like some comments in this thread are concerned with, though ideally that row would disappear like in @dbmrq's post:

Thanks for your help!

I don't care if there is sometimes an extra blank row at the bottom like some comments in this thread are concerned with, though ideally that row would disappear

I think youre finding older comments. The blank space can be there if you want. Or they can totally dissappear if you want. 😁

in regards to the dates, hiding them is easy.
just set their isHidden = true.

so in your cellForItemAtIndexPath function, you will do something like:

if cellState.dateBelongsTo == .thisMonth {
   cell.isHidden = false
} else {
   cell.isHidden = true
}

by the way, here is a guy who did a vertical calendar simplar to what to the one you showed (its vertical though, but same concept) --> https://github.com/patchthecode/WLAppleCalendar

That works perfectly. Thanks!

I was expecting to be able to toggle the display of those cells by changing generateInDates and generateOutDates.

Thanks for the help!

@mymikemiller nah.
You WANT the cells to be generated, but you just want them hidden.
cheers man 🍻