Portar WPF a Cacao (y / o viceversa)

Question

Estoy en las primeras etapas de la creación de software para un futuro mISV. El programa es una aplicación de escritorio y, a la larga, quiero tener una versión nativa tanto para Windows como para OS X (he examinado varias API multiplataforma y ninguna de ellas satisface mis necesidades). Inicialmente, sin embargo, no creo que tenga sentido desarrollar dos plataformas a la vez. Con eso en mente, he estado mirando WPF para Windows y Cocoa para OS X, y parecen similares.

¿Alguien ha tenido experiencia portando uno al otro? ¿Existen técnicas / paradigmas particulares a seguir que facilitarán la transferencia? Ignorando las consideraciones comerciales, ¿recomendaría desarrollar primero una de ellas?

Answer 1

Actualmente estoy trabajando en herramientas de portabilidad en este espacio y tengo muchos años de experiencia a menudo dolorosa en ya sea usando o escribiendo frameworks multiplataforma en Mac y Windows.

Uno de los mayores problemas en el pasado ha sido la negativa de Apple a abrir el formato de plumín para Cocoa (los plumines de carbono eran archivos XML abiertos hace años). Eso cambió con XCode 3 y el formato .xib , bien explicado por Frasier Speirs .

En el nivel de diseño básico, al menos, ahora existe la oportunidad de automatizar la transferencia de un formato XML a otro. Considero que WPF (XAML) es más limpio y lo estoy usando como mi formato base y migrando a Cocoa.

Cuando se trata del código detrás, aunque puede usar C # en Mono, el CocoaSharp El proyecto parece estancado o muy lento y no lo recomendaría.

Si se siente cómodo con C ++, considere tener tanta lógica como sea posible en C ++ con una capa delgada específica de plataforma en C # y Objective-C.

Otro enfoque que vale la pena investigar es usar un lenguaje dinámico como Python o Ruby. No estoy seguro de cuál es más maduro en la actualidad entre IronPython y IronRuby pero ambas personas ahora son compatibles con Microsoft. En el lado del cacao, creo que la flexibilidad de la sintaxis de Ruby triunfará y RubyCocoa probablemente esté superando a PyObjC .

De lo contrario, trabaje en C # y Objective-C y mantenga dos bases de código completamente independientes con diseños idénticos. Afortunadamente, los marcos tienen una semántica comparable para la mayoría de las cosas, especialmente si utiliza enlaces.

Answer 2

Creo que está en el camino correcto al elegir entornos de ventanas específicos para cada plataforma. Este enfoque le permite crear una experiencia de usuario en cada plataforma que no está restringida por los compromisos inherentes a los juegos de herramientas de ventanas multiplataforma.

Un buen primer paso es dividir su diseño en dos partes: elementos específicos de la plataforma y elementos neutros de la plataforma. Ya puede poner cualquier código de interfaz de usuario en la columna específica de la plataforma, pero tal vez su aplicación necesite cierta persistencia de datos que se pueda escribir en C ++ neutral de la plataforma. Lo que puede encontrar con este enfoque es que hay bastante lógica e infraestructura que puede escribir de manera neutral en la plataforma, dejando solo la interfaz de usuario y el código de pegamento como específicos de la plataforma.

Hubo un episodio reciente de Late Night Cocoa titulado Portar grandes aplicaciones a la plataforma Mac . Es posible que su aplicación no califique como "grande" pero este podcast brinda un gran conocimiento de portabilidad de alguien que lo ha hecho varias veces.

Answer 3

Bueno. Una vez que haya escrito una aplicación para Cocoa, es posible portarla a Windows. Esto se puede hacer usando gnustep o Cocotron .

Si lo hace de otra manera, WINE está destinado a facilitar la transferencia.

Prefiero escribir primero la versión OSX. Esto se debe a que los usuarios de Windows no tienen una idea clara de cómo quieren que se vea una aplicación. En mi experiencia, son bastante capaces de sufrir a través de todo tipo de interfaces de usuario. La consistencia tiene poco valor para ellos. Dado que no hay un acuerdo común, cómo debería ser una aplicación de Windows, nada impide que a los usuarios de Windows realmente les gusten los diseños de OSX, e incluso lo hacen con frecuencia. iTunes para Windows parece una aplicación OSX muy típica y escuchas muy pocas quejas de que no sería suficiente Windows-ish.

Yendo en la otra dirección, esto no es cierto. Los usuarios de OSX tienen una clara preferencia por las aplicaciones de Cocoa y muy poca tolerancia para, por ejemplo, cosas como GIMP o Inkscape que funcionan bajo OSX tan bien como en cualquier otro lugar, pero se ven claramente feas para el ojo entrenado de OSX.

Answer 4

Bueno, no hay un camino directo. El mejor método es usar algo como el patrón Modelo-Vista-Controlador o alguna otra arquitectura para separar la lógica comercial y demás de la presentación. Sin embargo, a menos que esté usando Mono, creo que habrá muy poco código para compartir. Si está desarrollando WPF, seguramente está haciendo .NET y, aparte de Mono, Objective-C es la herramienta de programación estándar en Mac OS X.

Mantenga un buen diseño y puede hacer que la mayoría de su código sea simplemente una versión Objective-C de su código .NET y viceversa, en lugar de tratar de encontrar una ruta de migración.