GUI de Windows: WPF o WinRT (2015+)

Estoy tratando de obtener una descripción general de las diferentes tecnologías para usar al crear GUI en Windows World.

Para el contexto, estoy construyendo un pequeño juego multijugador de plataformas 2D. (Solo con el propósito de aprender ..)

Mi maestro dice que cree que WPF es el camino correcto, pero parece que solo lo compara con Windows Forms.

Mi entendimiento es que aquí en 2015, ¿Windows Forms está totalmente muerto?

En estas otras preguntas de stackover, dicen que WinRT + XAML es para la construcción de GUI de Metro (¡cosa de mosaicos de Windows 8!), Y parece que WPF es algo que se usa solo para escritorio en Windows 7/8 y está estrechamente relacionado con Silverlight.

¿Cómo se compara Windows 8 Runtime (WinRT / aplicaciones de la tienda de Windows / aplicación universal de Windows 10) con Silverlight y WPF?

• El escritorio es donde viven las aplicaciones antiguas (rojo. WFP).
• La nueva clase de aplicaciones, las aplicaciones Metro, se pueden construir de varias formas, incluso mediante VB.NET, C # o C ++. Estas tres opciones de idioma pueden usar XAML para crear la interfaz de usuario. La alternativa es utilizar JavaScript / HTML5 / CSS para el desarrollo tanto de la interfaz de usuario como del código de la aplicación.

Mi verdadera pregunta es: ¿No hay UNA buena manera de construir GUI en Window World?

Y si no es así, ¿qué tecnologías se deben usar en Windows 7, Windows 8 (Desktop y Metro), Windows Phone (¡y Windows 10!), E incluso x-box ...

¿Es con diferentes tecnologías para comparar de esta manera?

¿En qué crees que es correcto invertir tiempo?

Hay mucho aquí, pero aquí va:

• ¿Windows Forms (Winforms) está muerto ? No. Aún recibe apoyo activo. Dicho esto, es una tecnología horrible para trabajar (al menos una vez que conoces la magia de WPF)
• Si desea crear una aplicación de escritorio atractiva y bien diseñada (clásica, no Metro), WPF es la respuesta en términos puros .NET. Usted puede utilizar las API de WinRT (como sus clases de socket) pero no se puede ejecutar en sistemas operativos antes de que Windows 8. La interfaz de usuario es todavía WPF.
• Las aplicaciones WinRT son para la Tienda Windows 8 (también están disponibles en la Tienda Windows 10). No puede usar WPF aquí o WinRT en el escritorio, por lo que el lugar donde implementa determina lo que usa. Tiene razón en su comprensión de los idiomas / tecnologías disponibles.
• Windows Phone 8 (ahora en desuso) usa un tiempo de ejecución modificado de WinRT (esto ha cambiado en Windows 10). Para Win8 / WP8, puede utilizar aplicaciones "universales" para compartir la mayor parte del código entre una aplicación estándar de WinRT y una aplicación de Windows Phone.
• Windows 10 usa la Plataforma universal de Windows (UWP) que se basa en .NET Core. El código desarrollado para Windows 10 también se puede usar en Xbox One, Windows Phone 10 y HoloLens. WPF sigue siendo para aplicaciones de escritorio "estándar".
• XBox es complicado. XNA se ha ido, y Microsoft parece alejarse del contenido creado por la comunidad para la plataforma. Dicho esto, Unity3D se puede implementar en XBox, y creo que el desarrollo estándar de DirectX (C ++) funciona para ello. Las aplicaciones de la Plataforma universal de Windows también se pueden implementar en Xbox One, y esta parece ser la estrategia de Microsoft en el futuro.

En cuanto a en qué dedicar el tiempo, eso depende de a qué te dirijas :). Aprender WPF / UWP + XAML le reportará muchos beneficios si desea mantenerse "actualizado" en el desarrollo de GUI .NET, así que eso es lo que yo haría. WPF tiene la mayoría de las funciones, por lo que al comenzar allí, solo tiene que encontrar soluciones alternativas para lo que falta en UWP (o cualquier otra tecnología basada en XAML).

Si hace eso, asegúrese de aprender el patrón MVVM (Modelo-Vista-Modelo de Vista). Funciona muy bien con las tecnologías basadas en XAML y le permite compartir mucha lógica entre sus aplicaciones WPF y UWP. La misma lógica también se puede usar si eventualmente desarrolla aplicaciones Xamarin para iOS / Android, etc.

Tenga en cuenta que para un verdadero desarrollo de juegos, querrá un marco de juego real (como Unity3D o incluso XNA). Puede hacerlo en WPF, y esa es una mejor opción que Winforms, pero ninguno está destinado a juegos.

Es un hilo bastante antiguo, pero como me encontré con esto a través de Google (por interés), tal vez alguien más podría llegar aquí también. Esta es una pregunta que los nuevos programadores se hacen una y otra vez. Así que me gustaría responder algunas cosas también, ahora que Windows 10 se lanzó oficialmente.

En primer lugar, ya no se debería empezar con Windows Forms. Es la tecnología más madura por ahora, pero no habrá más desarrollo de Windows Forms, solo está en etapa de mantenimiento ahora. WPF se desarrolla activamente (última vez que leí). Pero ahora, las aplicaciones universales de Windows (WinRT one) ya no necesitan usarse en pantalla completa y se pueden usar en modo de ventana al igual que otras aplicaciones de escritorio (WPF y WinForms). Esto aumenta mucho su usabilidad en computadoras que no son tabletas. Creo que este también será el futuro de las aplicaciones de escritorio. Aunque, los softwares de WPF son las aplicaciones de escritorio tradicionales (sin permisos, solo UAC). De cualquier manera, no importa si aprendes el desarrollo de WPF o WinRT (usando .Net), terminarás aprendiendo ambos. Ambos son XAML + C # (o algún otro lenguaje .Net). Estaba aprendiendo WPF cuando WinRT salió con Windows 8. Me sentí como en casa, solo algunos cambios menores a los que te acostumbras muy pronto. Sin embargo, no estoy seguro del escenario MVVM (enlace de datos) en WinRT. Todavía estoy aprendiendo ese aspecto de WPF.

Window 10 acaba de lanzarse. Windows 8 / 8.1 no tuvo tanto éxito como Windows 7. Entonces, si desea crear una aplicación que tenga una audiencia más amplia, debería optar por WPF por ahora. Pero en un futuro cercano, WinRT será el camino a seguir.

Para su pregunta, "¿qué tecnologías se deben usar en Windows 7 , Windows 8 (escritorio y Metro), Windows Phone, (¡y Windows 10!), E incluso x-box", la única respuesta es Windows Universal Apps. Esta es la razón exacta por la que se desarrolló este marco. Una tecnología que se utilizará para desarrollar aplicaciones para todos los dispositivos. Computadora de escritorio, tableta, teléfonos (incluido Android con Xamarin incluido con Visual Studio 2015), Xbox e IoT (Internet de las cosas).

Intentaré responder solo una de sus preguntas:

¿Windows Forms está totalmente muerto?

No, la tecnología de formularios de Windows no está muerta. Te diré por qué. WPF y XAML es una tecnología muy completa y compleja y puede crear una interfaz de usuario muy agradable. ¡Pero! Esta tecnología requiere un conocimiento profundo. Para los diseños básicos, no necesita tanto conocimiento, pero para algunos diseños avanzados debe tener un conocimiento profundo y cuando comencé con esta tecnología y pasé mucho tiempo buscando algunos consejos en Google. Entonces, cuando necesito algunos formularios simples para la entrada del usuario, siempre elijo la tecnología Windows Forms, que es muy simple y directa. Esta es también la razón por la que esta tecnología tuvo mucho éxito en el mundo. Cuando comienza con WPF, también necesita saber qué es el patrón de diseño MVVM y algunos programadores no experimentados se confunden con eso.

Ahora es abril de 2016 y todavía no hay una respuesta clara a esto. Estamos desarrollando una aplicación de escritorio de monitoreo del rendimiento en tiempo real muy moderna que tiene que representar múltiples gráficos y pantallas, entremezclados con texto y varios otros gráficos. Nuestra aplicación es C #, WPF con .NET Framework 4.5.2 pero todavía estamos escribiendo algunos componentes usando WinForms y GDI + para obtener un rendimiento aceptable. Simplemente no lo hemos logrado con WPF. Incluso hemos desarrollado un par de pantallas en la aplicación con DirectX, pero eso agrega mucha complejidad que solo algunos miembros del equipo pueden admitir. La simplicidad y la velocidad pura que podemos obtener al alojar una pantalla de WinForms dentro de WPF y la velocidad de GDI + nos brindan lo que necesitamos al costo de la estructura pura de View / ViewModel, además de tener que lidiar con varios problemas del espacio aéreo. Nuestra aplicación es bastante especializada y me encantaría deshacerme de WinForms por completo, pero desafortunadamente esto aún no es posible en nuestro caso. Para obtener un rendimiento puro, deberá utilizar DirectX o WinForms.

Mis dos centavos ... si quieres verdaderas aplicaciones universales, es decir, programas que pueden ejecutarse en CUALQUIER sistema operativo de escritorio, incluido Windows, WinForms sigue siendo el camino a seguir. Solo asegúrese de mantener la compatibilidad con CLR, y puede implementar en Mac y Linux a través de Mono. Un gran beneficio. XAML puede ser genial, pero no se trasladará a otros sistemas operativos.

Personalmente, encuentro aterrador el modelo de negocio de UWP de espacio aislado (¿arena rápida?); contrarresta la apertura que ha representado Windows desde el principio.

He trabajado con tecnologías de Microsoft durante más de 10 años. Lo más importante que aprendí es no solo escuchar lo que Microsoft te ofrece. Cuando Microsoft dice que este es el futuro, tiene un 50% de posibilidades de salir mal. Microsoft seguramente hará lo mejor que pueda para promover los productos en los que ha invertido, pero eso no significa que deba seguirlos. Vea lo que sucede con WCF y Silverlight.

Aunque WPF es una plataforma muy agradable para aprender, tiene una curva de aprendizaje enorme. No creo que ningún desarrollador con menos de 5 años de experiencia en programación pueda hacer WPF correctamente.

Siguiendo el patrón MVVM, encontrará que hacer algo relativamente fácil en WinForm puede volverse muy desafiante en WPF. Como colorear una celda en función de alguna condición después de una actualización, o desplazarse por una fila en la vista y resaltarla.

Por supuesto, puede decir que no tiene que hacer MVVM. Simplemente ponga su código en código detrás y hágalo funcionar. Sí, eso funcionará, pero ¿cuál es el punto de usar WPF? ¿Por qué no usar Win Form?

Este es un hilo antiguo pero importante con el progreso actual del marco .NET, las características de c # y un mayor enfoque en c # como una opción de desarrollo de juegos.

Con toda honestidad, WPF casi nunca se elige como plataforma de juego ac #. Los problemas del espacio aéreo de WPF asustaron a la gente bastante rápido. No creo que muchos (si los hay) títulos principales o motores de juegos de transmisión principal sean compatibles con WPF como plataforma de destino debido a esto. ¡Sin embargo, WPF es una gran plataforma para lanzadores de juegos!

WinForms, aunque ahora está en modo de mantenimiento, seguirá siendo una opción válida durante los próximos años. Es estable y probado en el tiempo. Por lo que he visto, incluso en 2017, WinForms sigue siendo la plataforma más común elegida para el desarrollo de juegos basado en c #.

Al observar los datos de Steam Hardware Survey , puede ver que en el momento de escribir esta respuesta (julio de 2017), Windows 10 de 64 bits es ahora la plataforma de juegos de PC dominante con una participación de mercado del 50%, seguida de Windows 7 de 64 bits con un 32% y Windows 8.1 de 64 bits a casi un 7%. La cuota de mercado de todas las demás plataformas de SO es tan pequeña que apenas vale la pena considerar otra cosa que no sean estas tres.

Siendo ese el estado actual de los juegos de PC, WinForms es el denominador más común para apuntar a las 3 principales plataformas de PC. De cara al futuro, UWP será la mejor plataforma de destino para el desarrollo de juegos de C #, ya que Windows 7 y 8 pierden una participación de mercado significativa frente a Windows 10, a menos que aparezca una nueva plataforma que la reemplace. Eso es solo por los números.

Si elige en función del mejor nivel de compatibilidad por plataforma de sistema operativo en lugar de respaldar la participación de mercado máxima, las opciones serían más como:

• Windows 10: UWP
• Windows 8.1: WinRT o Tienda Windows
• Windows 7: WinForms

La mayoría de las otras respuestas se centran en el desarrollo de aplicaciones estándar de Windows, pero el desarrollo de juegos es un ámbito muy diferente y diferentes factores influirán en sus elecciones, como el sistema operativo objetivo y lo que su elección de API de gráficos o motor de juego realmente admite mejor.

WinRT ha estado en el escritorio durante mucho tiempo, estoy escribiendo WinRT, que se ejecuta en mi escritorio. Y en Windows 10, esas aplicaciones admitirán ubicaciones no acopladas (con ventanas como las conoce tradicionalmente).

No recomendaría WinForms o WPF a nadie que empiece hoy. Deben aprender principalmente sobre WinRT / XAML. Y aprenda algo de Win32 / .net según lo necesiten, según el idioma que elijan ...

"Dicen que WinRT + XAML es para la construcción de GUI de Metro (¡cosa de ventanas con 8 mosaicos!)" - Esto es una abstracción tan excesiva que es inútil. WinRT es un tiempo de ejecución, como Win32, no es solo para GUI, entonces lo que "dicen" es BS completo. XAML es una capa de interfaz de usuario (muy similar a XAML en WPF), pero decir que Metro GUI también es incorrecto, ya no existe Metro GUI. XAML es la capa de interfaz de usuario de Windows. Y "¡Lo de los mosaicos de Windows 8!" expresa la visión de túnel de ciertas personas. Sería como si dijera que Win32 es una cosa del menú de inicio. Puedes ver lo ridícula que es esa afirmación.

Me encontré con esta pregunta hace un año. Llegué a la conclusión de que si XAML, WPF o WinRT son el entorno de desarrollo correcto para empezar.

Recomiendo encarecidamente utilizar .Net Framework para la capa de datos (incluidos los servicios web y la capa RESTful (JSON)) y HTML5 / CSS3 puro y Javascript para su capa de presentación web.

Dentro de Windows 10 puede integrar cualquier aplicación web como una aplicación metropolitana nada más sacarlo de la caja.

WinRT, XAML, WPF y otras cosas similares de ms se ejecutan solo en Windows y tienen muchas limitaciones.

Entonces, después de un año, todavía estoy muy feliz con mi decisión de no usar WinRT o XAML para mi nuevo proyecto.