Support for match_parent tileWidth/tileHeight

When using attributes tileWidth or tileHeight, there should be the option to set one dimension and tell the other one to match parent’s. Right now, leaving one blank defaults to the default value (44dp), which I don’t think is what most of us want.

Reviewing https://github.com/prolificinteractive/material-calendarview/issues/132, I think it’s incorrectly closed, since the changes in 1.3 do not fix OPs original issue.

This is the part of the code that should be changed, in MaterialCalendarView.onMeasure

if (this.tileWidth > 0 || this.tileHeight > 0) {
            if (this.tileWidth > 0) {
                //We have a tileWidth set, we should use that
                measureTileWidth = this.tileWidth;
            }
            if (this.tileHeight > 0) {
                //We have a tileHeight set, we should use that
                measureTileHeight = this.tileHeight;
            }
} else ...

//if you specified width/height, measureTileSize is still -1 here
if (measureTileSize > 0) {
...
} else if (measureTileSize <= 0) {
   if (measureTileWidth <= 0) {
      //Set width to default if no value were set
      measureTileWidth = dpToPx(DEFAULT_TILE_SIZE_DP);
   }
   if (measureTileHeight <= 0) {
     //Set height to default if no value were set
     measureTileHeight = dpToPx(DEFAULT_TILE_SIZE_DP);
   }
}

I see 3 possible solutions

1. If the user has specified height or width and the other field is -1, use measureTileWidth = desiredWidth or measureTileHeight = desiredHeight, which will result in the calendar matching parent’s dimension. This is a breaking change that may alter someone’s layout.
2. Force the user to specify both dimensions, accepting LayoutParams.MATCH_PARENT as a valid value. As in solution 1, but we will only use desiredWidth if the user specified MATCH_PARENT
3. Combination of 1) and 2), use default value if dimension is left blank, and accept MATCH_PARENT as a valid value.

Solution 1 is the default behaviour I’d expect from a calendar, but I guess breaking changes are to be avoided. Solution 2 will fail to compile for some users, which is good for those that upgrade without looking at the Changelog. Solution 3 is the most complete of the 3.

Maybe there are more options, but these are the ones I came up with.

[quentin41500]

Fixed in v1.4.2

[Maragues]

@quentin41500 Yes, but giving a value to width/height forces the other dimension to 44dp