Module is not extensible

[iheart2code]

I do not have a suggested solution for this issue, but the Swift module is not nearly as extensible as the Java counterpart. In Java, you can create a subclass of a chart renderer and take advantage of internal/protected methods & properties to create a custom chart renderer. This does not appear to be the case with the Swift module.

I was trying to create a bar chart with rounded corners on the bars. I needed to subclass BarChartRenderer, but was unable to do so without moving the ios-charts source code into my app's module.

Is there a way to accomplish a similar level of API-parity with the Java counterpart while at the same time allowing for extensibility? Perhaps take advantage of protocols or something.

[danielgindi]

"protected" methods are not available in Swift. For some reason Apple think that it's not a use case... Maybe a post on the appropriate Swift forum will change something...

[pmairoldi]

I would suggest maybe writing an extension to BarChartRenderer and override the methods you want to change. Maybe worth a try.

[martinnormark]

You cannot override methods from extensions:

Extensions can add new functionality to a type, but they cannot override existing functionality.
Source: Docs, first note

[danielgindi]

@martinnormark it is not an extension but a module...

[martinnormark]

Yes, I was just replying to @petester42 's suggestion.

[pmairoldi]

There is a distinction though. If the property or function comes from the subclass then its fine.

extension UIViewController {
    /// doesn't work
    override var title: String? {
        get {
            return "Cool"
        } set(new) {

        }
    }
}

class VC: UIViewController { }

extension VC {
    /// works
    override var title: String? {
        get {
            return "Cool"
        } set {

        }
    }
}

I thought it might work since BarChartRenderer is a subclass of ChartDataRendererBase but I haven't tried it.

[pmairoldi]

@danielgindi I believe this kind of issue could be solved if the renderers were protocol oriented and not subclasses. Then the charts could then take any object that adheres to lets say RenderProtocol and make it easier for other to modify the rendering.

[martinnormark]

@petester42 Should work it seems. Then you only need to subclass the BarChartView class, since that instantiates the renderer and there's no way to configure from the outside which renderer class it will use.

[danielgindi]

I think, maybe, we should try turning into public the important methods that deserve to be protected or are protected in the android counterpart.

https://developer.apple.com/swift/blog/?id=11

[danielgindi]

I think that maybe things that are "protected" in the Java counterpart, should be public here, but prefixed with an underscore, so the developer/user can know whether he/she is supposed to access it or not.
I don't get why Apple has decided that there is no use case for "protected". I guess it just made their life easier to optimize to C-level performance, when they know that they can't expect "dynamic" subclassing of stuff that was supposed to be "sealed".

[broncha]

+1 I am working on a custom renderer but I cannot access the animator

[simonmcl]

+1 Trying to add a gradient to the Cubic Line chart, can't get at the drawCubicFill method. Means i'm going to have to throw anyway cocoapods and import manually so I can modify it.

[broncha]

Bumped again. I need to assign a custom highlighter to a custom chart, derived from bubble chart. And cant access _highlighter neither extend ChartHighlighter

[danielgindi]

Yes this will be address soon

On Thu, Nov 12, 2015 at 11:40 AM, Rajesh Sharma notifications@github.com
wrote:

Bumped again. I need to assign a custom highlighter to a custom chart,
derived from bubble chart. And cant access _highlighter neither extend
ChartHighlighter

—
Reply to this email directly or view it on GitHub
#357 (comment)
.

[broncha]

👍

[broncha]

how do you suggest I do it for now?

[iheart2code]

@broncha you're going to need to bring the source code into your project and modify the files directly.

[iheart2code]

@danielgindi perhaps take a loot at the Protocol-Oriented Programming video from WWDC 2015 for inspiration here.

https://developer.apple.com/videos/play/wwdc2015-408/

[iheart2code]

The more I look at this library from a Swift/extensibility perspective, the more I realize that what I am asking is probably out of the scope of what this library intends, since it is supposed to be a direct port of a Java counterpart.

[pmairoldi]

As long as the API for the library remains similar to the Java version then it would be fine. Changes also go both ways. If you add something good to iOS charts then there is is a good chance it makes its way to Java version and vice versa. Don't let it discourage you from implementing something cool for this library.

You can try to give protocol oriented programming for the ChartHighlighter a shot and see if it's feasible.

[broncha]

About the custom highlighter part, I had to copy the entire ChartHighlighter and modified getHighlight.
Then introduce new _highlight property in my custom chart initialize . Of course this new _highlight was not accessed by the chart library. So I also had to override getHighlightByTouchPoint in my custom chart to use the new _highlight.

[liuxuan30]

@broncha It seems you could replaced the _highlighter in initialize() with yours, then you don't have to override getHighlightByTouchPoint if no more actions to take? Subclass ChartHighlighter won't need you to copy the entire code.

[iheart2code]

@petester42 took your advice. Please let me know if I went in the right direction with that. The sample app just works without any modifications. Unit tests don't seem to cover that part, but they all passed.

[liuxuan30]

another quesiton, shall we make initialize() to public rather than internal? I saw some people want to replace the renderer, but they cannot override initialize() outside of the library:http://stackoverflow.com/questions/33994223/fetching-current-x-position-when-graph-is-set-to-scroll-in-ios-charts/34011274?noredirect=1#comment55831925_34011274

[martinnormark]

That's exactly what I intend to do. Subclass an existing renderer, and override methods. Then pass that renderer to the chart view.

Perhaps you could define your own renderer by setting a public property instead?

[liuxuan30]

I am using the source files, so have no trouble of override internal stuff. But seems lots of people are sub classing outside of the library.

[danielgindi]

Moving to protocol oriented - will cause problem with keeping cross-platform API. Instead, everything in the renderers is now completely public :-)

[martinnormark]

Excellent 👍

Any idea when you'll cut a new release?

[danielgindi]

Probably around a day.

Just checking for any incompatibilities that I can find with the Android API, as this is the time to fix them, along with the other structural changes that were done (and also for critical bugs that must be included in this version)

[jenjia]

@martinnormark how do you pass the your custom renderer to the chartView?