Request: More reliable speed dial animation handling

[sronbheannach]

I’ve run into a bug in our app where, due to how our app is structured and how we handle configuration changes, we can run into a race condition where when we get to animateSpeedDialMenuItems() In FloatingActionButton.kt when trying to close the menu after clearing out speedDialMenuViews (basically, the source of our menu items gets destroyed before we can close the menu). This means speedDialMenuViews.forEachInexed() iterates over no items and busyAnimatingSpeedDialMenuItems is never set to false. When this happens the menu won’t open again.

If you changed line 575 (on master as of today) from

busyAnimatingSpeedDialMenuItems = true

to

busyAnimatingSpeedDialMenuItems = speedDialMenuViews.count() != 0

that would prevent situations where busyAnimatingSpeedDialMenuItems gets stuck when you don’t have any items.

[markormesher]

Hey @sronbheannach, thanks for the feedback. I don't have a ton of time to give to this project at the moment, but if you want to PR that improvement I'd be happy to review and cut a release. If not, I'll be able to pick this up in a week or two. If you do decide to PR it, it'd be good to see something a little more verbose about why the count is checked.