Android Question All views that display Text should auto-adjust font size?

JohnC

Expert
Licensed User
Longtime User
Am I missing something?

There is code in this forum that will check to see if a phrase of text will fit in a views size, and other code to resize (typically reducing) the font size so that the view's text can be fully visible/displayed and not get cut off.

Why doesn't every view that displays text have the built-in ability to resize it's text automatically?

With all the fragmentation with different screen sizes, density and different user-specified system font size, any view not having this built-in ability will waste us developer's time by having to manually implement this functionality. This ability is especially important when you start to do translations for your app and many translated phrases are longer/bigger then the English version.

I mean, B4X is for RAD development, so why does adding this essential functionality for virtually any app have to be a manual and time consuming task if we want our apps to appear properly on the broad range of devices out there?

I can't think of even one situation where it would be OK to display cut-off text to the user.

Is there a way to create a universal routine that would iterate through all the views of an activity and when it finds a view that displays text, automatically resize the text so it will fully display? This routine would obviously be called when a new layout/activity is loaded, but it should also have the ability to be manually called (or automatically detect) when text in a view has changed and perform a resize if needed. Can this routine/ability be built-into B4X so we don't have to manually insert the code in every activity and add the event hooks?
 
Last edited:

emexes

Expert
Licensed User
Am I missing something?
The easiest way to answer this question is: give it a go. In fact, you can do it right now in many instances by using a text size of "-2".

https://www.b4x.com/android/forum/t...pending-on-a-views-content.75533/#post-479335

The main problem is that you end up with something that looks like an early-desktop-publishing-era font explosion, where every text on the screen is a different (but perfectly-fitted ;-) size, usually with a grotesque outlier or two. Or if you set the font size and vary the container to suit, then you end up with eg: "randomly" sized buttons, and with the most-commonly-used "Ok" button being smaller than the "Cancel" button, which is usually the opposite of what you want from a usability perspective.

And then of course you have the annoying zooming-in-and-out out-of-focus sensation of text that varies, eg, if you are displaying names from a database, and you move from Jon's record to Jonathan's record.

I can't think of even one situation where it would be OK to display cut-off text to the user.
We've been cutting off text for display since the year dot, yet survived OK. We call it scrolling. But I can understand this example wouldn't have immediately sprung to mind, given its ubiquity.

Righto, having said all that: you can get pretty close, though. I've never been able to get the AutoScale+Anchors to do precisely what I need, and I'm too lazy to use the non-visual designer scripts, so I wrote a routine that I thought would solve all my problems, and it works pretty well, except... every new use of it seems to require a new special option to handle some new not-quite-right rendering. One thing that helped was applying the fits to groups of objects, eg, saying that "all these buttons should use the same size text" rather than fitting to each button individually and having different size text in each button.

Anyway, try the -2 trick, that's an easy way to dip your toe into the game.

:)
 
Upvote 0

JohnC

Expert
Licensed User
Longtime User
It looks like that -2 trick will resize the view's height or width size to accommodate the text, and not change the font size. If so, then depending on all the different text strings and the device's screen specs, you could surely end up with a mess of different view sizes then what the developer intended the layout to look like.

But, I'm thinking a better approach might be to let a view adjust its size automatically as it does now using the anchors. But then consider the font size that the programmer initially set for a particular view to be that views' "max" font size. Then ONLY allow the view to make the font size "smaller" if the text wont fit within it. This would hopefully at worse minimize the number of different font sizes on an activity, and at best actually have no different font sizes from what the developer initially designed the app with if no changes are needed.

My thought is that a user would rather see some text in a smaller size, then get text cut off.
 
Last edited:
Upvote 0

emexes

Expert
Licensed User
It looks like that -2 trick will resize the view, not necessarily the font size.
Hmm, you could be right. I was sure that the -2 was a trick you could use for TextSize too, but now I can't find the forum post.

I did find this during the search, though:

https://www.b4x.com/android/forum/t...adding-in-a-loop-for-all-views.43284/#content

so it looks like I've been doing some wheel reinventing myself anyway. Spewin!

My thought is that a user would rather see some text in a smaller size, then get text cut off.
Except for the outlier cases, where the text becomes smaller to the point of being unreadable. Sometimes truncation is the better option, although it helps to have some indication that it's been done, eg, the ellipsize option of Labels et al.

I saw an address once, to "Gembrook Launching Place Road", which seemed to have been shortened by removing presumed-redundant text "lace Ro" and thus became "Gembrook Launching Pad" which was funny because Gembrook is a idyllic small town with a daily steam train service, and the last place you'd expect to be launching rockets.
 
Upvote 0
Top