Microsoft-ui-xaml: Propuesta: la propiedad de envío automático cambió los eventos al subproceso de la interfaz de usuario

Creado en 17 may. 2019 · 3Comentarios · Fuente: microsoft/microsoft-ui-xaml

Resumen

Permita que los enlaces de la interfaz de usuario ocurran desde las propiedades que generan cambios de notificación desde cualquier subproceso que no sea de la interfaz de usuario

Razón fundamental

Cuando vincula propiedades, siempre debe generar una notificación de cambio de propiedad en el subproceso de la interfaz de usuario, o obtendrá una excepción de tiempo de ejecución. Esto hace que la interfaz de usuario se filtre en sus modelos de vista y modelos, para que pueda subir en el subproceso adecuado, lo que a su vez le impide usar INPC desde una biblioteca estándar de .NET (a menos que desee ingresar a bait'n'switch) .

Además, es posible que las propiedades cambien varias veces durante un cuadro, por lo que es posible que salte al subproceso de la interfaz de usuario muchas más veces de las que realmente se necesitan (todo lo que se necesita es marcar la propiedad como "sucia" y ser recogido en el siguiente pase de renderizado.

Todo esto provoca una complejidad de código significativamente mayor y es más propenso a errores.

También causa un problema en WinUI 3.0, porque ahora tenemos dos subprocesos de UI: UWP heredado y subprocesos de WinUI: ¿en cuál debo plantear?

Alcance

Debe poder generar INotifyPropertyChanged e INotifyCollectionChanged en cualquier subproceso
Debe poder hacerlo de forma económica varias veces en el marco, pero solo activando una única actualización (la última en victorias)
Debe poder manejar una propiedad que se establece mientras se lee para actualizar la interfaz de usuario.
Evita cambiar al subproceso de interfaz de usuario si ya está en él.

Notas importantes

Las preocupaciones sobre subprocesos son, por supuesto, válidas, pero no creo que esto sea realmente un problema al final. No importa que se activen varios eventos de INPC antes de que se actualice la interfaz de usuario, ya que solo importará el último. Esto no sería diferente al cambio de código existente al subproceso de interfaz de usuario varias veces. Una vez que el primero cambia al subproceso de interfaz de usuario, la propiedad ya podría haberse actualizado muchas veces y, por lo tanto, el último en ganar.
Naturalmente, tendría que haber un bloqueo breve cuando se lea el valor que evite que se establezca la bandera sucia, por lo que se produce una segunda ronda de actualizaciones de la interfaz de usuario en el siguiente cuadro, en caso de que la propiedad se actualice al mismo tiempo que se lee.
De hecho, si un valor, por ejemplo, cambia de falso a verdadero y luego a falso, la propiedad de dependencia ya es lo suficientemente inteligente como para detectar que el valor no cambió y puede optimizarse al no causar un nuevo pase de representación debido a la propiedad. no cambio

feature proposal team-Markup

Fuente

dotMorten

👍38

Comentario más útil

Esta es una preocupación muy válida, gracias por plantearla. El soporte de afinidad de subprocesos para DP en el marco puede no ser un gran problema, pero puede serlo para los implementadores de INPC.

Si algún código puede generar un cambio de propiedad desde un subproceso que no es de interfaz de usuario, también significa que el código de respaldo de la propiedad se puede cambiar desde un subproceso en segundo plano. Puede protegerse mediante bloqueos, pero los enlaces bidireccionales pueden convertirse en un problema, ya que pueden hacer que las cadenas de cambios de propiedad se bloqueen.

También está el mayor problema de INPC, que es la falta de valor "actual" cuando se planteó el evento. Puede haber situaciones en las que las propiedades no se sincronicen correctamente (p. ej., SelectedIndex y ItemsSource no se actualicen sincrónicamente y SelectedIndex pierda su valor), o con ping-pong de cambios causados por estados de propiedad (por ejemplo, cambios en el cuadro de texto y filtros de expresiones regulares).

Esto luego trae los problemas con INCC, donde toda la colección debe protegerse adecuadamente. Por ejemplo, puede generar un evento que haga referencia a un elemento que se ha movido o que ya no está.

No estoy diciendo que no haya una solución a este problema (definitivamente las hay), pero los cambios de afinidad de los hilos de escucha de IPNC no son suficientes para hacer que este problema sea fácil en ambos extremos de la interfaz.