Device.GetNamedSize obsolete. Alternative?

[hbraasch]

What is the alternative to [Device.GetNamedSize], which is now marked as obsolete?
Thanks

[Kapusch]

As per this comment from Gerald:

NamedSize should not be used nor needed anymore. All the fontsizes now automatically scale as per the OS settings. This improves accessibility overall.

[Ghostbird]

Yup, stuck with this as well. I understand perfectly well that I can now use device independent units as float, and that those are much better. But what value do I have to use? I have to migrate something from NamedSize.Medium to ???

UPDATE: I checked the Android specific implementation of the deprecated logic. If I understood it correctly:

// as decreed by the android docs, ALL HAIL THE ANDROID DOCS, ALL GLORY TO THE DOCS, PRAISE HYPNOTOAD

NamedSize.Medium is probably 14

[mdelgadov]

On this topic, a good replacement would be Fluent 2 table that has equivalencies for different environments:

https://fluent2.microsoft.design/typography

As you can see, one set of strings and bob's your uncle...

I have that in my project already but I don't know how to express it in Styles

[Ghostbird]

I think that when you take this approach, you're going to duplicate stuff that doesn't need duplication. When you create a new MAUI program, you already get such definitions in Styles.xaml, where e.g. it is defined that Buttons have FontSize 14. I think the crux of this discussion is that if I previously used the Xamarin definition NamedSize.Medium in a custom control, I need to know what value to choose for FontSize when I add my own style, to have it work well with the rest of the UI. Once I have a good value locked in, I'm migrated, and unless I overhaul the styles, I do not need to ever change it.

As I mentioned above, I found that in my migration using FontSize 14 where I previously used NamedSize.Medium gave a good result. However it would have been nice if MAUI had published a recommended mapping to ease this process. Of course the entire reason, the change was necessary, is that the old NamedSize mechanism was so terrible, that it was in fact impossible to publish a complete and correct mapping. The meaning of the NamedSizes varied wildly, between platforms, but even between different controls on the same screen.

[BlueRaja]

??? How is this an answer? The OS does not know whether I want the font to be "Large" or "Micro".

Is it supposed to read my mind? What is the actual alternative here?

[Ghostbird]

Well, it's clear that it wasn't a very clear answer.

My recommendation is that you define a Style for your custom control. Then in that style you set the FontSize for the control. The difficulty is figuring out what a proper FontSize is. But that's a one-time problem. Then once you've got a good FontSize chosen:

• The style will ensure it's always applied to all instances of that control.
• MAUI will guarantee that this size scales appropriately to all other sizes on all platforms.

The reason that the old named styles were deprecated was that they didn't do that last part.

The meaning of the NamedSizes varied wildly, between platforms, but even between different controls on the same screen.

That was a major problem on Xamarin. In MAUI if you give a Button a font size of 12 and your custom control a font size of 12, the letters are equally sized. In Xamarin if you gave both a NamedSize.Medium, there was no guarantee that the letters were equally sized.

In fact, on Xamarin it was a know issue that in some cases NamedSize.Large was smaller than NamedSize.Medium, but only in certain titles on Android.

So in summary:

• Use styles
• Use a well chosen numeric FontSize
• FontSize 14 is always a certain factor larger than 12.
• FontSize X is always the same size everywhere in the app on the same platform and screen size.
• Figuring out which FontSize value to use as a replacement for a NamedSize is a trial and error problem, but it's a one-time problem.
• Due to the problems with Xamarin NamedSize as explained above it was not possible to create a drop-in replacement, nor a migration, in MAUI.

[hbraasch]

Thanks.

[ouijahija]

[rant]
JFC... This is such a joke. Either make sure that basic functions that replace those of Xamarin are implemented or don't deprecate Xamarin Forms! How can you force the userbase to use the "new and improved" Maui when it's clearly still lacking in so many places?
[/rant]