Office Hours — Today, September 24

← Tuesday, September 22

Sep 24
7:20 PM
Mark M.
has entered the room
Mark M.
turned on guest access
7:30 PM
Tad F.
has entered the room
Mark M.
hello, Tad!
Tad F.
hi Mark!
Mark M.
how can I help you today?
Tad F.
I have a question about best practice for adjusting font sizes in the UI at runtime.
View paste 
My app has two sets of users - one of which has needs fonts to be much larger than the other audience.
I am currently using a setting to differentiate the two ("Are you primarily an X user or Y user"), and then based on this setting I need to adjust some (not all) screens in the app to increase the font size of standard UI components.
What I'm doing now is for each use of a layout, I have the default font style for user X, and I test for the setting to see if this is actually a user "Y", and if so I change the font for each UI component used in that fragment appropriately.
I really wish there was some more universal way to "map" styles to apply to a subset of layouts appropriatey base on that setting. Is there any best practice for something like this?
Mark M.
I take it that simply using sp units, and relying on the user to have font scale set up in Settings, isn't an option?
Tad F.
Well, I considered that, but I was a bit concerned that this would be too confusing for that user.
These are typically elderly, or those with some dementia
And their device is a dedicated "digital frame" type (table)
Tablet
Mark M.
well, a table is just a tablet with legs :-)
Tad F.
But I can't guarantee that the tablet would ONLY be used for that
So I can't "take over the entire tablet"
Mark M.
sure, but they probably need the bigger fonts in the other stuff that they are using on the tablet
Tad F.
"probably" being the key word.
Mark M.
but, regardless, if you're not going that route, that's fine -- you know your audience better than I do
Tad F.
Let's just explore that a bit though
7:35 PM
Tad F.
So when you say "use SP", you mean in all the layouts use SP rather than DP?
Mark M.
for text size, yes
you might need it elsewhere as well, depending on how you size your widgets
Tad F.
The other issue for me (and probably the most important) is that not ALL the screens need to have this adjustment. This is because some of them wouldn't normally be accessed by this audience, but I also don't want to "turn off" that access either.
Mark M.
if you're mostly a wrap_content or 0dp-and-ConstraintLayout sort of person, then text size would be the big one
Tad F.
And large fonts on those screens simply won't work
(i.e. screens that do designer type layout for image editing, for example)
So I have maybe 8 - 10 screens that have typical TextView, EditText, RecyclerView, Spinners, etc.
Those are what I need to adjust
It's what that audience will spend 90% of their tiem
time
Mark M.
well, you need to bear in mind that whether *you* get the user to set up font scaling for their device is independent of whether *anyone else* got the user to set up font scaling
Tad F.
Of course.
That's one of the things that I'm concerned with.
for my internal settings, I have an initial onboarding wizard that asks questions, and sets things up accordingly.
Mark M.
that means for screens where you absolutely cannot support font scaling, you're stuck with dp... even if the specific user for that specific screen could benefit from large fonts (designer with poor eyesight, for example)
Tad F.
I don't want to pop out tothe Android Settings screens, unless it's absolutely necessary
So your suggestion in summary if I follow this route is:
Use SP in all areas where font adjustment is acceptable, rely on Android settings to adjust it
Other areas use DP
7:40 PM
Tad F.
Is that right?
Mark M.
that's the gist of it, yes
if you feel that is impractical for your audience, though, then you're stuck with in-app scaling
Tad F.
OK - so back to my original question, within my app is there another option other than what I'm currently doing, i.e. in code adjusting the size at runtime?
Mark M.
not really, though a single utility function would seem to be all you need
have it walk the view hierarchy, and for all nodes that extend TextView, adjust the font
Tad F.
Well, one to change the size, but I'd have to iterate through all the components.
Yeah, ok right.
Sense of a performance hit?
I suppose do this in onCreate(), right?
Mark M.
not really much different than what you would be doing now
presumably, for activities
Tad F.
or onCreateView
Mark M.
presumably, for fragments :-)
(actually, I'd probably do onViewCreated() for fragments, but either could work)
(well, no, take that back, for this specific scenario, probably onCreateView() *is* the right answer)
Tad F.
why?
Mark M.
well, it gets to something that I've had here in my clipboard trying to paste into the chat when I had a second... :-)
if the font sizes are not the same, but your adjustment is a scale factor, get the current text size, multiply by your scale factor, and set that text size on the widget
7:45 PM
Mark M.
the catch with that algorithm is that you only want to do that once
Tad F.
right
Mark M.
I forget the rules behind onViewCreated() and if that might get called more than once per onCreateView()
onCreateView(), you're guaranteed that you're getting fresh widgets that need the adjustment
I'm not 100% certain that is equally true of onViewCreated()
Tad F.
Ok
Mark M.
FWIW, in the future, your scenario becomes a *lot* simpler with Jetpack Compose
Tad F.
That's interesting. Why?
Mark M.
everything is set up in code -- there are no more layout resources, style resources, etc.
Tad F.
OMG! I'm very excited about that. I've never been all that comfortable with that split.
Mark M.
there are still objects for defining the theme, including typography settings, but you create those objects yourself
Tad F.
I just put it down to me being too old and not willing to get with the program :)
Mark M.
so adding a scale factor to the theme based on your SharedPreference (or whatever) should be fairly straightforward
and the rest of your code just inherits it from the theme
Tad F.
The whole styles thing in particular has seemed pretty messy to me, but again I thought I just didn't "get it" properly.
Mark M.
no, styles pretty much suck
Tad F.
I mean, I understand overriding specific items, etc. It just seemed cumbersome
7:50 PM
Mark M.
agreed
7:50 PM
Mark M.
Compose is aiming to simplify that, among other things
Compose is probably a year away from being stable, though
Tad F.
Maybe by then they will have fixed the persisted permissions 128 limitation ;)
Mark M.
nah
that's a framework thing
lots easier to innovate with libraries
Tad F.
I ended up having to do really silly things like copy data from within the same device to my private directory on the device.
Waste
7:55 PM
Tad F.
And for data where that isn't an option (user has 20 playlists using content from YouTube, etc.), I just have to say 'too bad for you, you have to lose one of these to define your next one').
Blech
Mark M.
¯\_(ツ)_/¯
Tad F.
It isn't that way 'ahem', on iOS, at least according to my colleagues who love to give me grief about Android :)
But oh well - I've thoroughly enjoyed doing this project.
Learned a lot, and its fun.
You and your content have been a big help
Mark M.
happy to be useful!
Tad F.
OK I'm going to sign of for today, thanks again as always!
Mark M.
you're welcome!
have a pleasant day!
8:10 PM
Tad F.
has left the room
8:25 PM
Mark M.
turned off guest access

← Tuesday, September 22

 

Office Hours

People in this transcript

  • Mark Murphy
  • Tad Frysinger