Why isn't Balloon open?

[nikclayton]

Why isn't Balloon an open class?

This question is prompted by an experiment I'm doing. I anticipate having many balloons in the app, and using the "Persistence" feature to only show each one once.

For that to work I need to give each balloon its own preference name.

Having to create and manage each preference name feels like very tedious work, so I thought I should be able to:

1. Create a Balloon subclass for my app that sets various defaults, and overrides preferenceName to return this::class.java.canonicalname. This ensures that each subclass of that gets a sensible preference name.
2. Create a singleton object for each balloon that inherits from the app subclass, sets the text.

Something like this:

package my.app

// actual package: com.skydoves.balloon
open class Balloon {
    open val preferenceName: String? = null
    
    // more code
}

// actual package: my.app
open class AppBalloon(val text: String) : Balloon() {
    override val preferenceName = this::class.java.canonicalName
    
}

object FooBalloon : AppBalloon("hello")

object BarBalloon : AppBalloon("world")

fun main() {
    val foo = FooBalloon
    val bar = BarBalloon
    
    println("foo: ${foo.text}, ${foo.preferenceName}") // "foo: hello, my.app.FooBalloon"
    println("bar: ${bar.text}, ${bar.preferenceName}") // "bar: world, my.app.BarBalloon"
}

This fails at the first hurdle, because Balloon is final, and can't be subclassed from. It also doesn't implement an interface, so I can't implement that interface in my AppBalloon, and delegate to an underlying implementation either.

[JohannesPtaszyk]

Because modern and clean code should always favor composition over inheritance.
Inheritance as a design-pattern especially on libraries, can make changing things unnecessarily hard in the future.
Inheritance limits reusability, makes coupling stronger and in generally makes the thing less flexible.

I would suggest looking into different creation patterns.
For example the factory pattern could be helpful for you, which then internally sets up everything reusable.

[faraz152]

As the previous commenter noted, final is intentional — but the goal you describe (unique preference names per balloon type, without boilerplate) is fully achievable with a factory function:

// A factory that auto-generates a preference name from the call-site class
fun balloonFor(owner: Any, context: Context, block: Balloon.Builder.() -> Unit): Balloon {
    return Balloon.Builder(context)
        .setPreferenceName(owner::class.java.canonicalName)
        .apply(block)
        .build()
}

Usage — as clean as subclassing:

object FooBalloon {
    fun build(context: Context) = balloonFor(this, context) {
        setText("Hello from Foo")
        setTextSize(14f)
        setWidthRatio(0.6f)
    }
}

object BarBalloon {
    fun build(context: Context) = balloonFor(this, context) {
        setText("Hello from Bar")
        setBackgroundColorResource(R.color.bar_color)
    }
}

Each object gets my.app.FooBalloon and my.app.BarBalloon as their preference name automatically — exactly the behaviour you wanted from subclassing, without needing open.

In Compose, the same pattern works with rememberBalloonBuilder:

@Composable
fun rememberFooBalloon(): BalloonWindow {
    return rememberBalloonBuilder {
        setPreferenceName("my.app.FooBalloon") // or a const
        setText("Hello from Foo")
    }
}

The final constraint on Balloon is specifically to protect the internal state machine and window lifecycle — bypassing it via inheritance would risk crashes on dismiss/show sequencing.

[Alox1d]

A factory can give you the same per-tooltip defaults, but I would make the persistence identity explicit rather than derive it from java.canonicalName. That name follows implementation details such as package/class renames and can also change under obfuscation; a durable “already shown” key should survive those changes.

For the 1.x View API, for example:

enum class AppTip(val preferenceKey: String) {
    EDIT_PROFILE("tip.edit_profile.v1"),
    EXPORT("tip.export.v1"),
}

fun createAppTip(
    context: Context,
    tip: AppTip,
    configure: Balloon.Builder.() -> Unit,
): Balloon = Balloon.Builder(context)
    .setPreferenceName(tip.preferenceKey)
    .setShowCounts(1)
    .apply(configure)
    .build()

You manage the IDs centrally, and callers only choose a tip and customize its content. Bumping the explicit version is also a deliberate way to show a substantially revised tip again. Create the actual balloon in the UI owner's lifecycle; the singleton can describe the tip, without holding a window or Activity context.

There is also a version caveat in the earlier Compose example: rememberBalloonBuilder does not return a BalloonWindow. In 2.x, styles and visibility state are separate (rememberBalloonBuilder plus rememberBalloonState), and setPreferenceName/setShowCounts are no longer supported. The migration guide explicitly says to gate showing with your own storage. So use the factory above for 1.x, or keep the same stable AppTip.preferenceKey in your own preference store for 2.x.