wpf - metrowindow - ¿Cuáles son los beneficios reales de los lenguajes declarativos de IU como XAML y QML?

tab mahapps

Question

Actualmente estoy evaluando QtQuick (kit de creación de interfaz de usuario Qt) que se lanzará como parte de Qt 4.7. QML es el lenguaje declarativo basado en JavaScript detrás de QtQuick.

Parece ser un concepto muy poderoso, pero me pregunto si alguien que haya hecho un uso extensivo de otros lenguajes de interfaz de usuario declarativos más maduros como XAML en WPF o Silverlight puede dar una idea de los beneficios reales que se pueden obtener de Este estilo de programación. A menudo se citan varias ventajas:

• Velocidad de desarrollo
• Fuerzas de separación entre presentación y lógica.
• Mejor integración entre codificadores y diseñadores.
• Los cambios en la interfaz de usuario no requieren la re-compilación

Además, ¿hay desventajas? Algunas posibles áreas de preocupación vienen a la mente:

• Velocidad de ejecución
• Uso de memoria
• Complejidad añadida

¿Hay alguna otra consideración que deba tenerse en cuenta?

Answer 1

El punto de la codificación declarativa, es decir, WPF o QTQuick es proporcionar una separación entre el desarrollador y, presumiblemente, el artista que está implementando los aspectos visuales de su aplicación. Con respecto a WPF, encuentro que la depuración se vuelve un poco más difícil. Mientras hablamos, estoy compilando el último QT para ver QTQuick. (Lleva mucho tiempo y tengo tiempo para ver :-)) Por lo tanto, todavía no tengo una opinión al respecto.

Answer 2

QML / XAML son:

• Ideal para el patrón MVVM
• Hardware acelerado (QML con el uso de OpenGL para Windows, MAC, Linux y sistemas operativos de teléfono ... XAML con el uso de DirectX para Windows y su versión de teléfono)
• Más cerca de los artistas
• Puede crear una interfaz de usuario GRANDE y AGRADABLE utilizando XAML / QML
• Implementación de UI más fácil
• Buena animación es posible
• En XAML, normalmente puedes crear una versión Silverlight de tu aplicación solo con unos pequeños cambios.
• En XAML hay algunas funciones geniales como Plantilla, Disparador (Disparador de datos, Disparador, Disparador de eventos), Enlace (en cualquier lado y también ambos lados juntos), Recursos, Comandos, DependencyProperty y Propiedades notificables.

Pero tenga en cuenta en XAML: (Soy un programador de XAML, por lo tanto no tengo puntos para QML)

• La depuración XAML no es posible
• Para cualquier cambio en XAML, todos los programas deben ser recompilados

• Ten más cuidado con el rendimiento. Por ejemplo, si usa muchos RoutedCommands en XAML, su aplicación será inutilizable.

• En XAML, alguna característica no funciona como se esperaba. Lamentablemente hay algunos trucos. (Debe quedar claro ... debería funcionar como se espera ... ¿no?)

• Tenga cuidado con algunos espacios de nombres similares como BitmapEffect y Effect. Hay diferentes características y costos. (por ejemplo, BitmapEffect tiene algunos efectos con la representación del software y Effect tiene algún efecto con la representación del hardware)

• En el mundo real, los artistas no podían usar WPF como Flash (al menos con un buen rendimiento).

• Algunas características funcionan en lugares especiales. Por ejemplo, DataTrigger funciona solo en la etiqueta de estilo y no en la sección de recursos.

• Hay algunas debilidades en XAML. Algunos ejemplos: no hay ninguna animación secuencial ... ¡no puede hacer ningún cálculo en XAML (debe escribir un convertidor en C # incluso para un trabajo de liiiittle! JavaSript es un excelente reemplazo en QML) ... algunos atributos están duplicados. por ejemplo, x: Nombre y Nombre ... El control de la vista desde ViewModel no está claro. Ej. cerrar View from ViewModel (necesitas algo de CodeBehind)

• Tooooooo mucho errores en tiempo de ejecución. Si usa algunas etiquetas en un lugar inadecuado, se dará cuenta de un error de sintaxis, pero muchos de los errores se producen solo en el tiempo de ejecución. por ejemplo, si me dirijo a la propiedad de fondo (en lugar de a Background.Color) para ColorAnimation, se compilará correctamente, pero en la animación en ejecución ... BUMP ... runtime error! En tal caso, en Expression Blend, la aplicación se bloqueará.

Answer 3

QtQuick es extensible a través de los complementos de C ++, en realidad, lo que recomiendan los chicos de Qt es que realices la interfaz de usuario, animaciones, transiciones, etc. en QtQuick / QML, mientras que toda la lógica de tu negocio está en C ++ / Qt. De este modo, de esta manera obtienes lo mejor de ambos mundos, puedes depurar tu código C ++ como lo haces normalmente, mientras que al mismo tiempo hacer que las IU se conviertan en un esfuerzo y extremadamente fácil.

Otro aspecto importante de QtQuick / XAML es que son acelerados por hardware, por lo que, por ejemplo, puedes obtener fps bastante buenos sin ningún esfuerzo. Así que no son lentos en absoluto para lo que se proponen lograr.

Se ahorra tiempo, mucho tiempo. Hice una IU con código en 3 días, hice lo mismo en QML en 2 horas.

Answer 4

(Actualizado)

El concepto erróneo de XAML es que no está compilado. De hecho, se compila a BAML un XAML binario pre-tokenizado. Aparentemente hubo una versión compilada de XAML IL también llamada CAML. El OP me señaló este buen artículo que explica qué son XAML / BAML y CAML.

De todos modos, a la pregunta de por qué usarlo:

XAML es simplemente un formato de serialización para objetos C # que es particularmente adecuado para describir estructuras jerárquicas de objetos, como las que se encuentran en las GUI de WPF.

Lo que WPF te ayuda a hacer es escribir un código C # menos aburrido como este:

var grid = new Grid();
grid.Content.add(new TextBlock() {Text = "Hello"});
grid.Content.add(new TextBlock() {Text = "World"});

y simplemente expresarlo de una manera más legible como esta:

<Grid>
<TextBlock Text="Hello">
<TextBlock Text="World">
</Grid>

Como el anidamiento de objetos de WPF (poner cosas dentro de otros objetos) puede ser muy profundo, WPF hace que sea mucho más fácil de leer que el código C # resultante.

En cuanto a la separación de inquietudes: XAML también ayuda aquí, ya que solo le permite expresar objetos y sus relaciones / propiedades, en lugar de lógica. Eso te obliga a separar la lógica del diseño de la interfaz de usuario. El patrón MVVM es muy adecuado para esta tarea y permite la capacidad de prueba y las vistas intercambiables.

La complejidad agregada en XAML también se puede descartar fácilmente porque el mismo código en C # se vuelve más complejo que el marcado XAML.

Aunque no puedo darte una idea de QTQuick. Lo siento