Crash when measuredWidth becomes 0

[ubuntudroid]

Due to the following check an exception is thrown when the measured width becomes 0 (which can happen quite easily e.g. if the view's visibility is set to GONE or if the view size is dynamic).

MultiProgressBar/multiprogressbar/src/main/java/com/genius/multiprogressbar/MultiProgressBar.kt

Line 294 in fc9f084

check(!(measuredWidth != 0 && singleProgressWidth < 0)) { "There is not enough space to draw a MultiProgressBar" }

I find this overly aggressive, a simple warning (or even complete swallowing) would be better here IMHO.

[GeniusRUS]

@ubuntudroid thanks for the comment, I will correct it in the next version

[GeniusRUS]

@ubuntudroid can you please provide a MVP of this issue? This would greatly speed up the understanding of the problem and the timing of its solution

[ubuntudroid]

@GeniusRUS I'll try to reproduce with your sample app today.

[ubuntudroid]

Okay, I read the condition that leads to the crash wrong. Luckily it doesn't crash when the width is 0 (actually quite the opposite) - so all good from that view point. It does however crash if the MultiProgressBar is dynamically sized and changes size (e.g. due to some other view next to it increasing its size) or if used on small displays. I could reproduce that by simply decreasing the width of the MultiProgressBar to a small value like 50dp instead of match_parent in your sample app.

In that case it might be better to just convert the MultiProgressBar to a regular (single) ProgressBar UI-wise while still keeping the step capabilities (listeners and setters). Looking at the current implementation of MultiProgressBar I recognise that this might not be straightforward, so take your time. If you like my proposals, but can't come up with an implementation I can also take a stab at it in the next weeks when I have a bit more time.

[GeniusRUS]

@ubuntudroid yes, thanks for the clarification, I was able to reproduce this error in myself by setting the width to 50dp

I will definitely definitely remove throwing an exception in this case, and also add compression of the progress display to a minimum size so that it can be quite understandable

If you agree to help, I could upload video demonstrations of the new version of the work of progress, so that you also give an opinion on the implementation

[ubuntudroid]

Sounds great, I'm always happy to help! 🚀

[GeniusRUS]

@ubuntudroid did you mean this behavior?

Installed dimensions at 50dp

Collapsed state

screen-20210219-164312.2.mp4

Regular state

screen-20210219-161927.2.mp4

[GeniusRUS]

@ubuntudroid i look forward to your feedback
If the implementation fits your description, I will prepare a release

[ubuntudroid]

@GeniusRUS That looks exactly how I envisioned, neat! 🥇 Many thanks!