Replace Shell sans-serif-medium magic string on Android

[jfversluis]

trafficstars

Description of Change

In 3 places which had to do with Shell and/or TabbedPage we had a reference to sans-serif-medium as a string. This was causing exceptions, from what I can tell, on all Android devices and throwing underwater exceptions that the font could not be loaded.

I've changed these references to the TypeFace.SansSerif which is built-in and assume that it resolves to the same. From a visual test I don't see any differences.

Thinking about it, there will probably be no differences, since the font couldn't be loaded earlier, it would not have shown as it was intended in the first place.

Unfortunately, I couldn't really find any definitive source on if this was removed on Android at some point or what the cause is that we are seeing this now.

Preferably I'd like @PureWeen to have a look being the one most likely to have implemented this

Issues Fixed

Fixes #13239

[mandel-macaque]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).

[jfversluis]

I'd have to check in the actual device/emulators I've seen this on.

I think I have an answer to the "why" though.

I replaced it with SansSerif and not medium (because it's not in there) and the magic string had medium. So somehow we need to replicate that better then? Or maybe try to pin down on which devices this is happening exactly and maybe make it so that it applies the current way to devices where it works and the "new" way to devices where it gives the exception?

[PureWeen]

I'd have to check in the actual device/emulators I've seen this on.

I think I have an answer to the "why" though.

I replaced it with SansSerif and not medium (because it's not in there) and the magic string had medium. So somehow we need to replicate that better then? Or maybe try to pin down on which devices this is happening exactly and maybe make it so that it applies the current way to devices where it works and the "new" way to devices where it gives the exception?

I think the main place this exception comes from is the label. The code inside the BottomNavigationUtils works fine and doesn't throw with the magic string. When Label first attempts to load the font it consults the Assets. If that fails, then it uses Typeface.Create which succeeds for the magic string.

This is really a problem for any font that a user uses that's not part of our assets but will load as part of the OS fonts.

Ideally, we could fix this for all magic strings. Maybe there's a way we can just fix this for the default Shell path though. Maybe we can add a controls level mapper just for this font type? Not too sure.... Maybe there's some set of magic strings we can create a magic string list for that don't consult the assets?

[jfversluis]

Converting to draft while we talk more about this one

[Rabosa616]

Hi @jfversluis @PureWeen Any news here?

[jfversluis]

@Rabosa616 not really unfortunately. We found that, despite the exception, this code actually does do something. So this PR isn't the right fix and I still need to get back to this to determine what is the right approach here.

[Rabosa616]

Hi @jfversluis I can see that this error only happend to me when I added the builder.Logging.AddDebug(); in MaiuProgram, removing it I do not get the error.

[janseris]

Hi @jfversluis I can see that this error only happend to me when I added the builder.Logging.AddDebug(); in MaiuProgram, removing it I do not get the error.

Same here. Confirming.

[jfversluis]

From what I can tell this is fixed by #15759, this isn't needed anymore