Add entryIndex to PointProvider.getPoint

[Tyler-Lopez]

Background

Broadly speaking, I would love to get more information in the functions which provide CartesianLayerModel.Entry.

The information I am most interested in is:

• The index of the entry within its series.
• The x-value in pixels which corresponds to the CartesianLayerModel.Entry.x.
• The y-value in pixels which corresponds to the CartesianLayerModel.Entry.y.

I was a little surprised to find that seriesIndex was not the index of the CartesianLayerModel.Entry within its series but more broadly the whole series index among other series.

This commit adds entryIndex to PointProvider.getPoint which behaves as I had expected seriesIndex to.

I think this value may be beneficial to add to other surfaces, like the marker visibility listener.

Motivation

My implementation which brought the desire for these changes is a little particular.

I will first emphasize: the change of this commit isn't absolutely required for me, however, it is a nice optimization.

The other two things I am interested in which are not included in this commit: the x and y-value in pixels of the entry do feel like some change would be required.

In my implementation, I abstract the Vico implementation of a Cartesian chart behind a Composable which takes a generic T: Number. Of course, Vico uses simply Double, which is fine - however, I wanted my Composable to be able to use just any Number.

I use PointProvider.getPoint to associate the entry with a LineCartesianLayer.Point with what is effectively a Map<T, LineCartesianLayer.Point>. However, as the entry.x value is a Double, it cannot be used in this generic purpose without an unchecked cast. My implementation work-around here is to look at my series' x-values, and find the closest T to entry.x. However, if I had an integer entryIndex, I could use this to more efficiently look-up the correct T corresponding to the entry.

Key Changes

• forEachIn to forEachInIndexed.
• Add entryIndex to PointProvider.getPoint.

Alternatives

As previously mentioned, this change is not explicitly necessary for me - though it would make things easier.

I am also curious if it would be of interest to more broadly have something like an EntryMetadata object which could encapsulate, among other things, these 3 additions (entry index, x & y pixel coordinates of the entry) I have mentioned.