Use Modifier Pattern

[sidsharma2002]

Current Problem: I want to set a balloon properties to a fragment's (say fragX) argument and show a balloon with that properties from fragX Fragment only (to make things dynamic). The problem is right now I can't do so because properties like widthRatio margin etc are only set to Balloon's Builder with requires a context Ballon.Builder(context).setMargin().setWidthRatio()

Suggested Solution: As this a common problem It would be really great if instead of me creating a data class to save the properties, the library itself uses a Modifier pattern to show the balloon, which should be seperated from any context/lifecycleowner. eg: Balloon.Builder(context).setModifier(balloonModifier).build() and this modifier comes from another source (very similar to jetpack compose).

Thanks. (let me know if this issue is being taken up so I can contribute the fix itself too)

[skydoves]

Hey @sidsharma2002, thanks for the nice suggestion!

At first glance, this encapsulating pattern is a massive overkill to achieve small things. Most of Balloon's properties can't be parceled such as lifecycle, drawable, lambda function relevant things. The reason Balloon requires Context is most of the resource properties (color, margin, paddings, shadows, drawable) can come from the Android resource but also instances, unlike Jetpack Compose.

I'm just wondering what about creating a small data class, which includes some required properties and extends Parcelable to put on the bundle?

[sidsharma2002]

Exactly, sounds just right! (yes we won't be able to parcel the click/dismiss listeners)

And as I'll just add one more setter method to the Builder this will maintain backwards compatibility too. Ballon.Builder(context).setColor().setBlahBlah...setModifier(balloonModifier).build() (this ballonModifier would be a data class)

Let me know if there's some potential issues that can come with this change else I'll start working on it.

[skydoves]

Hey @sidsharma2002, it's been a very long time since you've suggested this idea, and now I can clearly comment on this. The Modifier patterns sound very convenient and useful in many cases, but I think they can also harm the potential API designs of the builder class, which mostly can lead to misuse by overwriting previous methods when prioritizing the Modifier properties. Also, it must make it hard to maintain the overall APIs by duplicating from the builder classes methods/properties, which is also not a good idea. So I ended up not taking this idea, unfortunately, but anyway, this is a very impressive suggestion. Thank you for your suggestion and I will reopen this issue again if I change this decision one day.