You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
More use-cases are popping up with specific effects in mind. I'd like to make Spark able to handle these specific effects for folks more easily than either adding special cases and attributes for them in SparkView itself, or having to request them to subclass SparkView and do manual drawing.
A pluggable solution with a way for folks to easily override just the drawing of the spark should be a great first step.
So if I understand correctly, similiar to how the Paint objects have getter, and more importantly, setters, you'd like the same accessibility for the Paths? I would think we'd want to keep these not mutable since everytime populatePath is called, the path is reset and drawn again using the data from the adapter.
If you mean setting the Paint objects like mentioned in #59, setSparkFillPaint is already exposed to the dev?
My super-rough idea so far is to have a class something like:
interface SparkDraw {
void draw(Canvas c, DrawArgs args);
}
class DrawArgs {
public Path sparkPath;
public Path sparkPaint;
public float[] scaledPointsY;
public float[] scaledPointsX;
public float scrubY;
public float scrubX;
...
}
Then users can override the draw there and mutate the paths/paints if they want crazier effects.
This isn't super well thought out yet, though, definitely open to ideas here!
DrawArgs sounds like it would clean up the SparkView significantly with all the getters and setters, we could even possibly throw in a createFromAttributes method which further shrinks the view class. I did something similar recently here.
Activity
cammace commentedon Apr 25, 2018
So if I understand correctly, similiar to how the
Paintobjects have getter, and more importantly, setters, you'd like the same accessibility for the Paths? I would think we'd want to keep these not mutable since everytimepopulatePathis called, the path is reset and drawn again using the data from the adapter.If you mean setting the Paint objects like mentioned in #59,
setSparkFillPaintis already exposed to the dev?danh32 commentedon Apr 25, 2018
My super-rough idea so far is to have a class something like:
Then users can override the draw there and mutate the paths/paints if they want crazier effects.
This isn't super well thought out yet, though, definitely open to ideas here!
cammace commentedon Apr 25, 2018
DrawArgssounds like it would clean up theSparkViewsignificantly with all the getters and setters, we could even possibly throw in acreateFromAttributesmethod which further shrinks the view class. I did something similar recently here.