[Update] v2 now in pre-release ✨

[pstromberg98]

✨ The new version (v2) is technically functional and available as a pre-release on pub.dev! ✨

Hello everyone 👋!

I thought I'd give an update to anybody interested of the current state of the project as I have been making decent progress with a rework of flutter_bouncy. The reason for doing a rework is that the previous implementation was more or less hacked together and had various issues with performance, maintainability, and weird edge cases. One of the most reported issues is the lack of null safety support. But instead of just converting the current codebase to NNBD and duct-taping the other issues, I've decided to focus my efforts on an entirely new and better implementation which includes supporting NNBD.

➡️ Without getting too much in the details, here's a quick overview of finished changes:

• The spring positioning is now handled during layout which allows for precise renderbox garbage collection among other things.
• Pointer handling is now sourced above the Scrollable which fixes any dropped events or other input weirdness.
• Spring simulation is now implemented internally versus relying on Flutter's SpringSimulation.
• Being intentional with what units/scales the spring simulation uses.

➡️ There's still work that needs to be done such as:

• Handle reordering of children.
• Writing tests.
• Support for a parallel to Flutter's AnimatedList widget.

☝️ I'll be updating the pre-release frequently so make sure to keep an eye out! If you see any problems/bugs/have ideas then feel free to open up an issue.

Side Note: I want to be clear that the pre-release status means that it is still under construction and is not production ready. I anticipate that a finished and releasable version will be coming shortly but please have patience as I am only able to work on this for a small amount of time during my week.

[simplenotezy]

That's super cool news! We couldn't use it in our project, because of the missing null-safety.

Also, any plans to support the 'reverse' property?

[pstromberg98]

@simplenotezy Yup! The plan is to support everything the ListView widget supports.

Also, check out the latest pre-release and I think you'll be happy 😉

[Manguelo]

Awesome! Looking forward to adding this back to my project 🎉

[pstromberg98]

Update: Reordering children is now handled in the latest pre-release 🤘

[omnitrogen]

Hello @pstromberg98! Thanks for that lib, it looks really cool :heart_eyes:

Would it be possible to expose BouncySliverList to public? I'm just wondering if it's intentional to keep it private or if it's meant to be exposed but just not ready yet?

Have a good day :sunflower:

[pstromberg98]

@omnitrogen

👋 Hey Felix!

I can expose BouncySliverList but I haven't done any testing with it alongside other slivers. It should work fine -- it just may look a bit weird as the bouncy effect would only apply to the BouncySliverList and not the surrounding slivers.

Also, the BouncySliverList is a bit harder to setup due to requiring a simulator (this may change) and a pointerPosition. I recommend using the BouncyScrollView (in place of CustomScrollView) in conjunction with BouncySliverList as it will provide a pointerPosition for you.

return BouncyScrollView(
  ...
  simulator: simulator,
  sliversBuilder: (pointerPosition) => [
    BouncySliverList(
      pointerPosition: pointerPosition,
      delegate: widget.delegate,
      simulator: simulator,
    ),
  ],
);

Regardless, I can get an update out soon to make the BouncySliverList public.

[pstromberg98]

Hey all! Just wanted to drop a quick update. The package is nearly there but I am changing how the spring offset/lengths are tracked and updated.

Previous Approach

In the previous approach the offsets were all calculated based off of a single simulated spring. The offsets were diminished or augmented depending on the distance to the pointer. This worked great for most scenarios except for when you would quickly fling through a list. The dramatic change in the pointer position would cause a jarring and immediate adjustment of the scroll items. There wasn't a great way I found to work around this without changing the core of the simulation.

New Approach

Each item RenderBox maintains its own spring object. When the scroll changes the spring velocity of each visible RenderBox is adjusted according to delta of their position and pointer position. An external ticker will update the springs length per tick and then cause a relayout. Because spring length is stored and not calculated on the fly, flinging and rapid pointer deltas do not cause an immediate change but instead update the velocity causing a gradual/natural change in spring length.