feat: variable front page height

[mockturtl]

Adds double frontLayerActiveFactor to BackdropScaffold. See #70.

Optional: use drawerScrimColor to disable the back layer when it is partially concealed.

• BREAKING: bumps min sdk to Dart 2.3 for "collection if"

Default values leave existing behavior unchanged

New behavior

• Using drawerScrimColor: Colors.black54, frontLayerActiveFactor: 0.2 (20% height)

• Using drawerScrimColor: Colors.black54, frontLayerActiveFactor: 0.5 (50% height)

[mockturtl]

@daadu Sorry for the delay! Let me know what you think of these changes and I can add the documentation changes discussed in the linked issue.

[WieFel]

@mockturtl what's the purpose of setting frontLayerActiveFactor to some percent value (like 0.5)?
I don't think that there is much necessity for setting percentual height of the front layer, at least in common use cases.

Wasn't your original issue #70 about the front layer that should fill exactly the height of its content?
In that case, a flag (something like adaptiveFrontLayerHeight: [ true | false ]) would suffice and could be internally used to adapt the front layer's height depending on its content, just as it is already done with the back layer and stickyFrontLayer property.

[mockturtl]

I don't think that there is much necessity for setting percentual height of the front layer, at least in common use cases.

I agree it would be nice if Material provided more guidance here. I can't cite any use cases of Backdrop outside the "Material studies" apps. (Mine is functionally equivalent to a drawer, as in Shrine.)

Side note, I do think a "fractional" parameter is more user-friendly than a pixel value.

a flag (something like adaptiveFrontLayerHeight: [ true | false ]) would suffice and could be internally used to adapt the front layer's height depending on its content, just as it is already done with the back layer and stickyFrontLayer property.

That's arguably a nicer API. Can we make it work? I get layout flicker when I naively wrap the front layer with _MeasureSize, and it never settles.

I would guess Column is the most typical front layer. There could be a solution where we insist front layer widgets have constraints, but it seems less intuitive.

[daadu]

@WieFel #70 as I see, is about having "extra" drop by-default if a user wants, instead of sticking to appbar by default.

I think frontLayerActiveFactor with percent value is the correct solution for it.

What you are suggesting adaptiveFrontLayerHeight can be added independently - the behaviour would be the same as, headerHeight and stickyFrontLayer that we have now for backLayerRevealed state but frontLayerActiveFactor and adaptiveFrontLayerHeight could be for backLayerConcealed state (only difference is headerHeight is in pixcel while frontLayerActiveFactor is in %).

[WieFel]

I think frontLayerActiveFactor with percent value is the correct solution for it.

Ok, so please go ahead with it @mockturtl @daadu

[daadu]

Some minor documentation changes and a minor refactor requested.

[daadu]

@WieFel Can you review it too?

[WieFel]

@mockturtl has the implementation been tested against common use-cases? It should not break any previously working functionality...

[daadu]

@mockturtl We have a "demo" app that show cases various use-cases of backdrop implemented with the package check live demo. Feel free to add a use-case using this feature if you want in future.

Apart from that this LGTM.

[daadu]

This has landed with v0.5.0 on pub.dev. @mockturtl Thanks for your contribution. Please check yourself in README!!