Open PureWeen opened 1 year ago
We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process.
Is there a reason why we can't use V1
, V2
, V3
namespaces? I really don't like the SwipeView2
approach because it is ugly and it does not allow for a real type SwipeView2
to exists (let's say this one has a two way swipe, left right, up down). I also thing that users new to the platform or coming from not windows platforms might not understand, than it is an evolution, where as V2
is something that users from any platform will see as a Version 2 and therefor as an evolution.
Just imagine, what amount of effort could be saved for the Maui team, and also for developers using MAUI, if they switch to drawn controls. Not constantly needing to adjust to changed platform controls or incomplete/buggy handlers. Simply continuously improving/enhancing existing controls. If only there would be a person at MSFT who peruses this goal and created a prototype.
https://github.com/dotnet/Microsoft.Maui.Graphics.Controls
I also find it strange using 2, 3 etc for new handlers. Iirc, the pattern in windows is used for interfaces adding new features to a class, rather than adding new classes (so you have the same class X that implements ix1, ix2 etc in newer versions). I never seen anyone use ListView2 in a ui, for instance. Not sure if that's even a thing.
I do agree that having a custom renderer would fix so many of maui's issues. Who knows, maybe in maui2 or maui3...
I don't think users should be forced into opting in for the latest handlers. It should be the other way around.
I agree with @juwens, in my experience of developing in blazor, the browser is like one big collection of drawn UI I don't have to deal with a lot of the things I dealt with in xamarin
Drawn UI is great, but it is semi expensive but then there is the 50% of people who want native. No matter what we do, unless we have a drawn UI for each OS and keep up with os changes, 50% will be unhappy. We probably need both as always.
Maybe there is shouldn't be one way to code UI, some wants native some wants framework pretending to be native so there is greater abstractions and consistencies, I agree making MAUI work is more important on making every feature supported
Drawn UI is great, but it is semi expensive but then there is the 50% of people who want native. No matter what we do, unless we have a drawn UI for each OS and keep up with os changes, 50% will be unhappy. We probably need both as always.
I have the impression, that:
You probably need to think how to be able to "freeze" handler versions during the project creation. I.e. when I create a project, the latest recommended handlers should be used (not simply a V1). But when a new handler version is released, previously created project shouldn't migrate there automatically (therefore you can't simply use UseLatestFeatures in the project template).
How do users know what handler versions are available, and what versions should be used?
Description
A number of scenarios can occur that require us to move to new handlers. There are cases where the platform owners (iOS/Android/WinUI) will introduce new controls that users want to use. Sometimes we are forced to migrate to these new controls in order for
Apple
to continue letting users publish to the store. For example, inXamarin.Forms
we had to remove all references toUIWebView
and recently we modified all of ourAndroid
input fields to inherit from a specific base class otherwiseAndroid
would stop lettings us published to the store. We try not to break users in unexpected and undesirable ways but in order for the platform to evolve and for apps to continue functioning we have to deprecate and sometimes remove.General strategy
The current plan will be to follow a similar pattern as windows and just append an incrementing number to new handlers. If we migrate one platform to
Handler2
we will create aHandler2
version on all platforms. TheHandler
andHandler2
for the untouched platforms will retain the same behavior as one another. Example can be seen here.If we were to only migrate the
Windows
handler toHandler2
that would make the xplat APIs confusingvs
How do I opt in for these new handlers?
By default, users will need to opt-in to the new handlers. The mechanisms around this still need to be discussed, but it will almost definitely be some sort of builder extension method.
We can possibly break this out to specific handlers as well for discovery purposes. This also lets us document the extension method itself to indicate what opting into this handler includes.
Users can also manually opt into the new handlers through handler registration
If users only want to opt into the new handler on a single platform they can. If they have a lot of code written against
SwipeViewHandler.Mapper
onAndroid
and only care about updatingWindows
. Or maybe we've changedSwipeViewHandler
on two platforms but they only want to opt into theWindows
one.or
Additional Notes
ISwipeViewHandler
andISwipeViewHandler2
will have no overlap. We need to be able to deleteISwipeViewHandler
without breakingISwipeViewHandler2
Alternate suggestion to
Handler<Num>
Associate handlers with the .NET release they were implemented in. This gives a bit of clarity to where the handlers came into existence but could also lead to a number of confusions
Cons:
Obsoleting Handlers
These scenarios will be a bit case by case.
Platform forces us to deprecate delete
There are some cases where the platform (iOS, Android) forces our hand, and we have to delete/break code based on the requirements of those platforms.
Platform offers a new control
As the platforms themselves evolve new types of controls are created for existing UI concepts (i.e. datepickers, timepickers, entries, etc...). In order for us to stay current we need to provide users with the most modern experience. The timeline of deprecating/deleting older handlers here will depend on the requirements of the platform. If enough time has passed and the old version of a
DatePicker
is no longer recommended or used byApple
then we will stop actively maintaining and remove theHandler
We've implemented what we feel is a better version then what the platform offers
These cases will most likely be pretty rare as it's a lot of work to maintain custom built controls. One scenario that's currently active is the SwipeView control https://github.com/dotnet/maui/pull/11229. We have a custom implementation that enables mouse interactions. If we pull this PR in, we will most likely need to maintain both handlers for some time until we can confidently say that the new implementation is a 100 percent accurate stand in for the obsolete handler. There is a decent change that when this happens, we will be maintaining both handlers for a number of years.
Will you ever delete handlers?
If we've deemed that users need to move all new code to a new handler, then we will obsolete the old handler for a major release cycle to allow time to migrate and then remove the handler.
Current optimism indicates that we will move any obsolete handlers to
Compatibility
unless it's a scenario where the platform is no longer compatible with thatHandler
. For example, onAndroid
you're required to implementAppCompatEditText
so if we had any handlers that weren't usingAppCompatEditText
we would just delete these because our hand is forced by Google.Examples
Currently we have a PR to implement a new
SwipeViewHandler
https://github.com/dotnet/maui/pull/11229 that is custom built and enables more features than the WinUISwipeView
. Once/if the new handler reaches 100 percent feature parity withSwipeViewHandler
then we can obsoleteSwipeViewHandler