Progress Bar Text format not consistent

[jaburton111]

Has your issue been reported?

• I have searched the existing issues and confirm it has not been reported.
• I give permission for members of the FlutterFlow team to access and test my project for the sole purpose of investigating this issue.

Current Behavior

This issue occurs in both TestFlight and FlutterFlow test mode though with slight variances. The issue is with the progress bar text and the number of decimal places. For the progress bar text, I am pulling variable data from my database that is a decimal number already rounded to 2 decimal places in my database. The purpose is to present that decimal number as a percentage with zero decimals in the progress bar text. I am using a code expression to accomplish this. The functionality works perfectly for all but just a couple list items which end up showing a long string of decimals.

Screen.Recording.2023-08-22.at.8.34.50.AM.mov

You can see in this clip Bob Dylan and Incubus are the only two that have a long string of decimals. All the others appear as they should.

To add further complication, it presents slightly differently in TestFlight:

RPReplay_Final1692707969.mov

As you can see here, the long string of decimals persists with Bob Dylan but there is also now 1 decimal added to every other artist. No idea why this is happening.

Expected Behavior

The expected behaviour would be a presentation of the decimal numbers as percentages with zero decimals, and consistency across all list items.

Steps to Reproduce

1. Add progress bar to list item
2. Set progress bar text to variable
3. set variable to data that is in decimal format rounded to 2 decimal places

4. set code expression to present as percentage and reinforce decimal places

5. view in FlutterFlow Test mode and Apple TestFlight.

Reproducible from Blank

• The steps to reproduce above start from a blank project.

Bug Report Code (Required)

ITEejvLluJZNpbxa7rrULMd4lQMzN0g2a+cZm9VxbwIoIpznBuw+Z8nBVElBZ7SgaVNcAEybozof0t77iIXAG+5eE02AfaU6wqliWgnee2i7VYyMBbqeSXd8M51YC3a/y6uzrwkmKrJZWGQY112UAe+tFy3DFOu/Zwh9f6PHaOI=

Context

I am looking for consistency of presentation and format within the list items of this screen. These anomalies create a messy look to the app which will affect user experience.

Visual documentation

I have added images and clips above. Should be everything you need to fully understand the issue.

Additional Info

na

Environment

- FlutterFlow version: v3.1 
- Platform: MacOS Desktop
- Browser name and version: Chrome Version 115.0.5790.170
- Operating system and version affected: Ventura 13.5

[wenkaifan0720]

Hi @jaburton111. You can use the number format option for numbers to convert them into percentages. You can also do it with code expressions, I would suggest using the toStringAsFixed() function.

[jaburton111]

Hi there... I'm not clear on how this is different to what I'm already doing. I am using the code expression clipped above to format the text, which actually works perfectly in every instance except two. Why those two is a mystery. And since all dynamic list items are subject to the same code expression it seems wrong that these anomalies would exist at all. No?

[hariprasadms]

Hi @jaburton111 - We appreciate you bringing this up. According to the progress bar widget, the behaviour you're seeing for those two numbers is expected. This is due to the accuracy of numbers to the degree. I would advise using custom code to format the number according to the degree of precision needed to round up or down. I'm hope it can help you. I can confirm that it is not a bug.

[jaburton111]

Hi @hariprasadms ... I can't help but feel there is a miscommunication here. Perhaps I wasn't clear, or I don't understand your explanation. First off, "I would advise using custom code to format the number according to the degree of precision needed to round up or down." Is this not what I have already done using the code expression cited above? If not, why not?

I would also like to restate that the data source for this variable has already been rounded to two decimals. Which means the decimals showing up on my front end somehow are being created by FlutterFlow.

You also say "the behaviour you're seeing for those two numbers is expected". On what basis is this behaviour expected? Those numbers are no different (as far as I can tell) than any of the other dynamic numbers in that list, for which the code expression is working just fine. So why is this behaviour "expected" with those two numbers and not all the others?

Please explain, as your previous response lacks clarity and specificity.

[wenkaifan0720]

Hi @jaburton111. The 2 digit precision you see in Supabase is not guaranteed in Flutter. There could be some rounding errors so its a good idea to always explicitly round the number to the precision you want. See some discussion here: https://stackoverflow.com/questions/57481767/dart-rounding-errors.

[jaburton111]

Thank you @wenkaifan0720. This is interesting. Though. I want to make sure I fully understand.

To be clear, I'm not using supabase as my backend, I'm actually using Xano. But I assume your point still stands. Which is that the 2 digit precision you see in the cell in the database is not necessarily what's being computed by Flutter.

However, I thought I was accommodating for that by applying the following code expression in FlutterFlow: (percentComplete * 100).toString() + '%'

Is code expression not adequate to "explicitly round the number to the precision" I want? Or is there a way in which you can suggest I change this code to achieve that?

[wenkaifan0720]

The code expression you used was not rounding the number to 2 digit precision. If your number is like 0.19999997, then multiplying it by 100 would just be 19.999997 and the final result is '19.999997%'. The operation you did here is just to convert a double value to a percentage.

As I have suggested above, you should use the toStringAsFixed(n) function where n is the number of digit of precision you want.

[jaburton111]

Thank you @wenkaifan0720 ! I thought I had the code expression right, but your small correction totally explained why I was getting an error when trying to update the expression. It was the 'n' I was missing. Thanks again!

[hariprasadms]

As per last comment. I presume solution is found for the issue. Hence i am closing the issue.