Clarify usage of protocols and classes in implementation about swiftcharts

[ivnsch]

Using protocol extensions would be great, I didn't do this because at the time I wrote the library it was not possible to use them for this. ChartLayerBase is there only to not make layer subclasses implement both methods (similar to adapter class in Java) as in most cases they'll implement either one or the other... I could have also declared the protocol method as optional (with objc annotation) but ended deciding for adapter class. Using a protocol extension to provide empty implementations is a good idea.

Concerning behaviour, it may be worth considering if for the methods in ChartLayer 2 protocols are needed instead of 1, since they correspond to use cases that are usually mutually exclusive (don't have to though). chartViewDrawing is used to render to the context of the chart view, and chartInitialized to add subviews to it. Everything that is drawn using chartViewDrawing, will of course appear behind added subviews, independently of layer. Thus it's unlikely someone would want to combine them in the same layer, if it's needed to render to view context there's always the possibility to do this in the added subviews also. Maybe having 2 different protocols can help making this separation clearer, on the other side this would mean we would have to pass 2 different layer arrays to Chart which makes the interface a bit more complex. Nevertheless it would be a more realistic realistic representation of the drawing stack, where basically all core graphics layers are at the bottom then all the views on top of it. I'd probably just let them in one protocol, but you can think about it. There's certainly a need for improvement here. "DrawableLayer" in any case emphasises the "rendering" aspect and makes adding subviews in chartInitialized look a bit like an unplanned side effect.

The reasoning behind ChartAxisLayer and ChartAxisLayerDefault was different, here the default class does some decisions about how to render the axis, like rendering the line and labels using core graphics. Maybe someone wants to use subviews instead, e.g. to add animations or effects, in which case they'd create a new implementation of the protocol.

About ChartContextDrawer, the reason I did this separate to the layers is that this is conceptually not a layer, just a helper component that can be used by layers, to draw using core graphics. This connects with what I said about the ChartLayer methods, we could have a generic "ChartDrawable", which would be implemented by some layers as well as these components. The question would be how this would be integrated this with the existing layer system.

[interstateone]

Thanks for the info @i-schuetz! I think this clears things up. Separating drawing and "subview-hosting" like you mentioned could be a good solution here. As an example, if there was a Drawable protocol exclusively for drawing (LineDrawer, LabelDrawer, etc.) then a Layer protocol would inherit from Drawable. I'm mostly repeating what you already said back to you 😄. I'll poke around and see how this works out and report back.

As for the axis layer case, this makes more sense now too, but perhaps the name of the default class could be "ChartAxisDrawerLayer" (or something else) to distinguish it as a possible default implementation that handles the common use case as opposed to the default implementation that someone should use if they're going to subclass. Documentation of the class may help make this clear too.

[ivnsch]

I know classes meant to be subclassed rather prefixed with "Base", but yeah, "Default" is not really definitive of the class itself, rather how it's used and you're right that this should not be in the class name. "ChartAxisDrawerLayer" or similar is good :)