[Spec] Essentials Dependency

[hartez]

Description

Take a dependency on the Essentials library. This will eliminate some of the overlap between this SDK and Essentials.

Overlapping APIs

These are APIs which are currently provided by both Forms and Essentials. Any additional functionality which Forms has will be ported to Essentials, and the Essentials APIs will be used.

App Theme

Light and Dark theme info.

Color Converters

Methods for converting color data to and from cross-platform Color.

Device Display Metrics

Informations such as screen size, density, and rotation.

Device Info

This includes information such as the device's Platform and Idiom.

Preferences/Properties

A simple persistent key/value store.

UI Thread Invocation

The Essentials implementation of UI thread access relies on a static MainThead class which is incompatible with multi-window applications on some platforms. We will need to maintain the current Forms Dispatcher pattern or modify Essentials to follow that pattern.

Backward Compatibility

For folks relying on functionality currently provided by Forms which will be dropped in favor of the Essentials version, this will be a breaking change.

Difficulty : Low

This will mostly be a matter of removing the Forms code which is duplicated in Essentials.

[akamud]

I would like to understand and discuss the pros and cons of this.

I understand some features are overlapping, but I'm not a fan of the whole Essentials package becoming part of the SDK, specially because Essentials doesn't have interfaces by default, and would cause problems for unit-testing again (something that is being fixed in MAUI).

At the end of the day, what other benefits do we have in bringing Essentials in? People can always add Essentials when needed, is it worth considering removing the duplicated APIs from new versions of Essentials itself?

[hartez]

@akamud I realize that Essentials doesn't provide interfaces out of the box, but is there something about the API design which prevents you from creating your own interfaces for the parts of Essentials you're using?

[akamud]

Not really, indeed, I always install Essentials.Interfaces right after I install Essentials, I guess the discussion here is more about the philosophical stance that adding Essentials would cause... When people that are new to the platform see Essentials installed with no interfaces, they might be taken to a direction of writing coupled apps that are more difficult to test. (This is an assumption from my part, maybe you have some data that can bring more facts to this discussion?)

With that in my mind, I'm more interested in understanding what is the big gain from the SDK point of view, since everything is a "nuget-install" away. I might be underestimating the APIs overlapping problem here too, after all, I'm not a maintainer in any of those projects.

Do you see any other advantage with this approach other than fixing the overlapping problem?
Also, do you think removing the overlapping in the Essentials end has any negative impact?

[pictos]

Will the Xamarin.Essentials (XE) become System.Devices? (Maybe I missed something) If yes makes sense to remove this overlap right now, when Maui is in the early stages.
About XE and Interfaces, I think the right place to add this feature-request is on the XE repo, there is a good (at least for me) reason that XE doesn't have interfaces, but maybe this reason doesn't make sense when it becomes System.Devices.

[hartez]

The big gain in removing the overlap is that we'll only have to maintain one implementation for each thing which overlaps. Right now, the Forms team and the Essentials team (which themselves overlap a lot) are fixing bugs and improving code in multiple places to do the same things. It also reduces documentation maintenance.

Plus combining them reduces the confusion for developers who add Essentials to a Forms project and suddenly have multiple ways to get the screen size, convert colors, etc. Or folks who use the default templates, which already includes Essentials.

[akamud]

I think I get the whole picture now, thanks for taking the time discussing this :)

[PureWeen]

xamarin/Xamarin.Forms#13583

[Tommigun1980]

The big gain in removing the overlap is that we'll only have to maintain one implementation for each thing which overlaps. Right now, the Forms team and the Essentials team (which themselves overlap a lot) are fixing bugs and improving code in multiple places to do the same things. It also reduces documentation maintenance.

Plus combining them reduces the confusion for developers who add Essentials to a Forms project and suddenly have multiple ways to get the screen size, convert colors, etc. Or folks who use the default templates, which already includes Essentials.

Doesn’t this just mean that Essentials has overlapping features with Xamarin.Forms?
I mean what is the point in Essentials providing functionality that already exists in Forms, shouldn’t it be Essentials that is cleaned up?

And by extension, if Essentials removes the overlapping features, would it still make sense for Forms to add a dependency at that point?

[mattleibow]

Related to #1965