How often can you update a textview without mess

Question

Suppose a textview

TextView tvSum = findViewById(R.id.sumTexviewId);

If I want to change the displayed text, I do this:

tvSum.setText("£0.00");

Now, supposing I do this regularly, say every time a button is pressed, perhaps showing the sum entered on a till. In this example, you press one, it says "1p", then you press two and it says "12p" and so on.

I find that if I do this, the text becomes distorted after a while. For the sequence 12345, to start with all is good:

• (nothing pressed yet)
• ("1" pressed)
• (then "2" pressed)
• (then "3" pressed)

However, after that things get messy:

• (then "4" pressed)
• (then "5" pressed)

It never gets any better thereafter. I haven't posted code because the code really is very simple: a bunch of buttons and only writing one short string to one textview - nothing in the code should cause this, honest. (Yes, I've checked the string being written is correct by putting it up on Toast.) Has anyone else come across this, and if so what resolved it?

Answer 1

It turned out that Mr.Me was looking in the right direction, and it had something to do with the way the background is rendered when the text is changed. I had set (intentionally) the button to have a transparent background inside the yellow outline (rather than leaving it unspecified), using colour 0x00000000.

For some reason, when applying non fully opaque fills, the new background is laid over the previous contents (a cycle of about 3 bitmaps, I think), rather than defining the contents. I guess that this is probably due to the default PorterDuff transfer mode used by Canvas.

Solutions I have come up with whilst working this out:

1. Leave the background unspecified. This is also transparent, but for some reason actively so.
2. Have any full alpha background. (Downside: doesn't work if you want some transparency)
3. Write a custom view which overrides onDraw to actively fill the canvas with 0x00 before calling the super.onDraw(). (Downside: this gets rid of any background in this view, but retains Views behind this View.

Apologies for the "not doing anything fancy" statement - I didn't realise that actively setting the background to transparent counted as fancy!