Made changes to allow the axis label, popup and value text in the popup to scale down when there's not enough room. This means the labels and popups won't overlap when there are a bunch in a small space, or a very long label.
I added a new constant to determine the space between labels on the x-axis and chose the best value based on my eye. Value of one leaves way too much space and 2 leaves almost no room. 1.6 felt just right.
There is cache in the form of a map to store the proper sizes of popup labels and it can get used a lot since, in my case, it was only using either two different lengths, 2 or 3, for percentages. It's purpose is to cut down on measuretext calls. measuretext is cheap, but in my case with 12 bars it decreased measuretexts calls from 427 to 77 for valuetext labels. That was enough to make scrolling smooth in my listview, but I should put in another one for the axis labels. It would be a tad trickier to do the right way and not just a good way, but I'll get around to it. In any case, there isn't a real tradeoff here, because the extra code beyond the checks is only called when the text would have been overlapping and unreadable anyway.
Yes everything defaults to the current value. The label text only changes when the the width of the bar + padding*multiplier > text width.
The popup on top of the bar is squished only when it would have exceeded the (bar width + half of the padding), so now it won't paint on top of another popup or bar next to it.
The text in the popup is squished only to the bare minimum to fit inside the popup, with no padding.
So it defaults to the values already used, and only decreases them enough so the text and popups won't paint over each other. The sample, for example, is not affected at all by these changes.
I was trying to add a similar measure text cache to axis labels as I do here for the popup text when I realized that code I committed makes a bad assumption. It assumes that the text in the popup is monospace, when nearly all android typefaces are not.
So the effect is this:
BarGraph measures the popup values string 9.7 as , say, 10 units wide. It caches this measurement (size of string, paint.textsize needed to fit in the 10 units) as (3, x). 9.7 is painted to within the bounds of the popup.
Then, on another bar with value 1.1, where the characters 1 and 1 are not as wide as 9 and 7, it does not do a measurement, as it has already done a measurement on a length three popup string. It paints "1.1" with textsize x, but because 1.1 takes up less horizonatal space, "1.1" is left-justified and offcenter. There are a few pixels between 1.1 and the right side of the popup.
In short, the lines 27, 28, 134 ,185, 186, and 189-191 should be removed. The while loop between those lines should be kept.
This bug only arises in cases where, without this patch, the graph would be unreadable, so on balance it's not a huge deal, but these lines should still be removed.
From what I've read of android fonts, there is no great way to predict measurements and every approach is fickle. It is likely no cache solution will work.