66 decoration property

[daniel-v]

Motivation: offer a way to resolve #66

I noticed, that several properties of BoxDecoration are settable via constructor arguments. To preserve backwards compability, I didn't remove those but did deprecate them. With this deprecation comes a new property decoration.

If deprecated arguments are set, they act as overrides to Flushbar.defaultDecoration.

[AndreHaueisen]

Hi @daniel-v. First of all, thanks for the feedback and for the effort.
I have reviewed your code. I still don't support every BoxDecoration property. Until then, I don't intend to accept a BoxDecoration property.

About the issues, you opened. I will push an update tomorrow, maybe the day after supporting box border. (Uniform border since border radius can only be used with uniform borders).
I still have to take a closer look at the padding issue. Maybe allow custom padding with max value. Don't know yet.

[daniel-v]

Thank you for being super responsive and being so quick getting back at me!

Seems like, my "imagination" went a bit wild, didn't quite fit your vision for the library. (And that's fine, this is how OS dev happens). So now, I take a step back and ask first before proposing a change.

I still don't support every BoxDecoration property. Until then, I don't intend to accept a BoxDecoration property.

I'd like to argue, that from my API usage standpoint, encapsulating closely related configuration properties in a wrapper is a good idea. Reasoning being:

• encapsulation offers a way to do object composition
• via object composition one can formulate default values that best fit their design (eg. shadows, borders, etc) and reuse them
• excessive number of configuration arguments is less desirable than enclosing closely related properties in objects, in this case BoxDecoration.

A way to fully support BoxDecoration and all it's properties would be to accept BoxDecoration. This was one of the points in my changeset. Seems like you are going a different route, adding support for decoration one property at a time. Could you expand on why? (If I'm to submit further PRs, I'd like to understand the design principles)

Uniform border since border radius can only be used with uniform borders

That'd work for me!

Maybe allow custom padding with max value.

This change would also work, as long as I can say, "hey Flushbar, have 0 padding around your content"

[AndreHaueisen]

The principle here is to avoid boilerplate code and at the same time assure the user that what he made did not break the layout. It is a fine balance between customizability and usability.

What I encourage users to do is to create a base class with the basic configuration they want to. Shadows, background colors, text style don't usually change within the same app's notifications. Take FlushbarHelper class as an example and create your own. I do that on every different app.

Sorry about the delay on the new update. Someone filed a bug that seems impossible to solve.