Repository navigation
Layout definitions
The library bases its measurements and layouts on regular hexagons, and like any
regular polygon, the size in one Cartesian dimension determines the size in the
other. To specify which dimension defines the hexagon's size, the library offers
the FitMode enum to choose whether it's calculated from the available width
and the number of columns, or the available height and the number of rows;
i.e., FitColumns or FitRows.
A hex grid in either framework must fit a bounded dimension. Due to Android's
affinity for portrait, the default value is FitColumns, and the width must
have a fixed or maximum value in that mode. In FitRows mode, the height must
have a fixed or maximum value.
The CrossMode enum specifies how to layout the cross lines if the component
has a fixed size in that direction: either aligned to the start, center, or end,
or scaled to fit. If the component does not have a fixed measure in the cross
direction, it will wrap to the grid's size.
The examples below are all FitColumns, so the CrossMode is being applied in
the vertical direction, along the rows.
The ScaleToFit option will cause the hexagons to be stretched or shrunk
irregularly in most cases, but it's hardly noticeable at small scales, so it's
handy to fill out grids that only need a tiny adjustment, or if regular hexagons
aren't a strict requirement anyway.
The next layout option is the custom enum HexOrientation, with values
Horizontal and Vertical, and it determines in which direction a major axis
is aligned.
The last setting which affects the grid's layout is the stroke width of the line that draws the hexagons. As the stroke width increases, the actual grid outline is inset to keep everything within the component's bounds, as illustrated in the first image here:
As you can see in the second and third images, large-ish stroke width and scale
values can cause noticeable visual discrepancies in the resultant width of the
angled lines compared to the straight ones, because it scales the draw as a
whole. The difference between the two is due to the middle one
being FitColumns and scaling the rows to fit, and the last one being FitRows
and scaling the columns. This could be remedied, if necessary, but you'd have to
rework the core method used to draw the individual hexagons.
It is important to note that, no matter the stroke width, the current implementation resolves cell hits with respect to an infinitesimal outline. That is, the stroke width doesn't shrink a cell's hit area at all.