There was a bug where wrapperBinding.root.removeView(progressView) was always evaluating progressView as null, so the IndeterminateProgressView was never actually being removed from the ViewGroup.
This PR also mimics the smooth ease-in animation when the progress bar completes. If this was not added, the progress bar would smoothly reveal itself then abruptly disappear (see second video). Now, the progress bar smoothly reveals itself then smoothly disappears (see third video).
Current Behavior
Without Ease-Out
With Ease-Out
My Habitica User-ID: 99f20106-7060-4398-b565-26e56c4de2ad
There was a bug where
wrapperBinding.root.removeView(progressView)
was always evaluatingprogressView
asnull
, so the IndeterminateProgressView was never actually being removed from the ViewGroup.Even though the
progressView = null
assignment happens on line 84 and...removeView(progressView)
gets invoked on line 82,...removeView(progressView)
is invoked insideprogressView?.post { ... }
, meaning it gets scheduled on the UI thread and doesn't actually evaluateprogressView
until after theprogressView = null
reassignment. This PR moves theprogressView = null
assignment inside the UI runnable after the...removeView(progressView)
invocation.This PR also mimics the smooth ease-in animation when the progress bar completes. If this was not added, the progress bar would smoothly reveal itself then abruptly disappear (see second video). Now, the progress bar smoothly reveals itself then smoothly disappears (see third video).
My Habitica User-ID: 99f20106-7060-4398-b565-26e56c4de2ad