Allow calendar traversal without impacting selected date.

[MosheBerman]

Per, @snadahalli, in my words:

If you tap on one of the arrows on the calendar, it shows another month, and changes the selected date to the first of the newly visible month.

This behavior should remain enabled by default, but an optional alternative is to allow users of the library to set a flag which would allow users of the calendar to traverse the months without changing the date.

[MosheBerman]

This feature request is essentially asking for the behavioral change implemented in iOS 7.

[tikamchandrakar18]

Same issue I am also getting, Did not understand your solution.

[MosheBerman]

There's no solution yet. It's a feature request. ;-)

[MosheBerman]

Related #120

[MosheBerman]

Related: #97

[MosheBerman]

Design Discussion

Behaviors

• Add a flag to the calendar view to turn this behavior on.
• Flag is off by default.
• If/when we implement scrolling gestures, enabling scrolling may also enable this flag.
• Assuming no drag-to-scroll for now.
• Setting selected date also sets visible date to the same value, always.
• Setting visible date also sets selected date, if the flag is disabled.
• A second date property selectedDate would be added to the calendar view model.

User Interaction

Defining the date property as "selected date" and the new date used for display of a different time range as "visible date," here's a chart of user interaction to change the two values:

	Legacy Behavior	New Behavior
Change Visible Date	Single Tap	Tap Arrows or Scrub
Change Selected Date	Single Tap	Tap Cell

There are three options for the new behavior:

1. Arrows in the header select change visible date, tapping cells change the selected date.
2. Tapping on either the arrows or the cells change the visible date, and double tapping a cell changes selected date.
3. Tapping the arrows or scrubbing changes the visible date, and tapping a cell changes the selected date.

The third is a more complete description of the third, and that's the behavior modeled in the chart. I'm going to give that a go.

Other Concerns

Some random thoughts:

• The UI is inherently designed for a single date to be both visible and selected, although scrubbing does behave similarly to scrubbing.
• Introducing a true scrolling or paging mode complicates this, because then we need to account for an entirely different set of user interactions. This would change the UICollectionViewLayout a little bit as well.
• Right now, "panning" is implemented with touchesBegan: and friends, but as a UIGestureRecognizer it would be easier to implement scrolling.

[MosheBerman]

Calendar Traversal Design, Part 2

Thinking about this some more, it looks like we also need to worry about minimum/maximum dates, and delegate callbacks.

Visible or Selected?

If the view model's current "date" property is treated as "visibleDate" and the new property is "selectedDate" we need to decide if we duplicate the delegate methods for "visibleDate" and "selectedDate", and if not, which one fires when?

Missing Features

I think for now it might make sense to treat the "date" as "selectedDate" and add a "visibleDate" property, so as to keep the delegate and minimum/maximum dates the same. This means that there's no way to tell when the user changes the visible date, and no way to clamp the visible months independently of clamping the selectable date range.

I think I need to think on this a little more.