wpf - gui - qt creator

¿Cómo se compara Cocoa con Microsoft, Qt?

Question

He hecho algunos meses de desarrollo con Qt (interfaz gráfica de usuario integrada solo mediante programación) y ahora estoy empezando a trabajar con Cocoa. Debo decir que amo a Cocoa. Muchas de las cosas que parecían difíciles en Qt son fáciles con Cocoa. Obj-C parece ser mucho menos complejo que C ++.

Probablemente sea solo yo, así que, ¿qué sientes por esto?

¿Cómo se compara Cocoa con WPF (es ese el marco correcto?) Con Qt?
¿Cómo se compara Obj-C con C # a C ++?
¿Cómo se compara XCode / Interface Builder con Visual Studio con Qt Creator?
¿Cómo se comparan las documentaciones?

Por ejemplo, encuentro Outlets / Actions de Cocoa mucho más útil que Qt''s Signals and Slots porque en realidad parecen cubrir la mayoría de las interacciones de la GUI mientras que tuve que trabajar con Signals / Slots la mitad del tiempo. (¿Acabo de usarlos mal?)
Además, las plantillas estándar de XCode me dan copiar / pegar, deshacer / rehacer, guardar / abrir y muchas otras cosas prácticamente de forma gratuita, mientras que estas eran tareas bastante complejas en Qt.

Responda solo si tiene conocimiento real de al menos dos de estos entornos / marcos / idiomas de desarrollo.

Answer 1

Esta es una forma de verlo. Para escuchar el otro lado, diría que esto hace una lectura bastante buena: http://arstechnica.com/apple/news/2008/04/what-microsoft-could-learn-from-apple.ars

Personalmente encuentro que uno también debería considerar el rendimiento. Objective-C y las antiguas bibliotecas de Nextstep parecen mucho más compactas, mientras que WPF es un poco exagerado.

Answer 2

He trabajado con Cocoa / Obj-C de vez en cuando a lo largo de los años. A partir de 2010, me parece bastante limitado en comparación con WPF / NET Framework. Enumeraré algunas de las diferencias que he encontrado, y usted puede juzgar por usted mismo.

Lenguaje de marcado

Cuando diseño en WPF obtengo un marcado que es un XML muy simple que puedo editar o editar a mano con herramientas que yo mismo escribo. En Cocoa debo usar archivos xib, que no están diseñados para una fácil edición manual o manipulación. Aquí hay un ejemplo simple de marcado de WPF:

<DockPanel>
  <Label>Select your favorite food:</Label>
  <ComboBox
    SelectedText="{Binding FavoriteFood}"
    SelectedItemsSource="{Binding AllFoods}" />
</DockPanel>

Este es el marcado completo, y es equivalente a aproximadamente 50 líneas de .xib difícil de editar.

La capacidad de ver y editar un XAML simple es increíblemente valiosa para:

• Edición manual directa
• Comunicación con compañeros (por ejemplo, )
• Fuente contrrol
• buscando
• Transformaciones automatizadas

Capacidades de diseño

En WPF puedo usar paneles para diseñar automáticamente mis controles a medida que cambia el tamaño de la ventana. Puedo usar estilos para definir el espacio entre mis controles, o puedo ajustar los márgenes para obtener el aspecto preciso que quiero, o ambos. En cualquier caso, mi IU se ajustará automáticamente a los cambios en el tamaño de las fuentes, el tamaño de la ventana y la resolución de la pantalla. En Cocoa, todos los controles están en ubicaciones x e y específicas como con WinForms y lo único que puedo hacer es cambiar el tamaño automáticamente. Esto es extremadamente limitante Por ejemplo:

• Los controles no se pueden ajustar a una nueva fila o columna a medida que la ventana se hace más pequeña (WrapPanel)
• Los controles no pueden agregar / eliminar detalles en función del espacio disponible
• Los controles no pueden moverse para dejar espacio para un control que tiene más texto de lo que originalmente se esperaba
• Los controles no pueden encogerse ni agrandarse selectivamente para llenar el espacio disponible
• Interface Builder inicialmente establece controles para cumplir con las pautas de interfaz, pero un nuevo estilo aplicado no puede cambiar el diseño.

La ventaja del diseño de WPF es que puede expresar su intención a través de la forma en que agrega controles a los paneles, luego ajusta el diseño preciso más adelante. Tenga en cuenta que WPF también puede funcionar a la antigua usanza, pero una vez que haya utilizado paneles para el diseño, nunca volverá al diseño X / Y.

Por ejemplo, una aplicación que hice tenía filas que contenían calificaciones de estrellas más cuadros de comentarios. Normalmente, la fila era solo el máximo de una calificación de estrella, pero cuando se escribían comentarios largos en el cuadro de texto, el TextBox se hacía más alto, lo que hacía que la fila fuera más alta, por lo que las siguientes filas se movían hacia abajo. Con WPF obtuve este comportamiento de forma gratuita, con Cocoa tendría que haberlo codificado a mano.

Conectividad de datos

Con Cocoa / Obj-C está prácticamente limitado a la conectividad de datos integrada, que incluye acceso básico a la base de datos y serialización hacia y desde archivos. Con WPF / NET Framework puede vincular directamente su UI a prácticamente cualquier cosa bajo el sol, incluyendo:

• Bases de datos relacionales (SQL, Oracle, etc.)
• Bases de datos de objetos (Objectivity, Versant, etc.)
• Bases de datos heredadas (Acceso, dBase, R: Base, etc.)
• Bases de datos COBOL en mainframes
• Formatos de bases de datos propietarios (cientos)
• páginas web
• Servicios web (SOAP, REST, etc.)
• Archivos XML
• Archivos planos (delimitados por comas, delimitados por tabuladores, ancho fijo)
• Documentos de Office (Word, Excel, etc.)
• Documentos de OpenOffice
• Campos de formulario en PDF
• Datos del receptor GPS (ubicación actual)
• Posiciones de interruptores físicos, botones, palancas, perillas, controles deslizantes, etc.
• Hora (local o de red)
• Contadores de rendimiento (utilización de CPU, etc.)
• Cámaras (cámaras de video, cámaras web, cámaras de imágenes fijas, etc.)
• Entradas electrónicas analógicas
• MIDI (teclados de instrumentos musicales, pastillas, etc.)
• OBD-II (monitoreo de vehículos)
• LDAP y Active Directory (información de cuenta de usuario)
• WBEM y SNMP (estado y configuración del dispositivo de red)

De hecho, puede vincular prácticamente cualquier cosa que tenga un controlador escrito en cualquier lenguaje NET Framework, y existen más de cien lenguajes NET Framework.

Código repetitivo

En Cocoa, su modelo consta de un archivo .hy un archivo .m, su controlador consta de un archivo .hy un archivo .m, y su vista consta de un archivo .xib. ¡Cada campo de cada objeto en su modelo debe estar referenciado en cada uno de estos lugares!

En WPF / NET, un solo campo generalmente solo aparece en dos líneas de código: una vez donde se define el modelo, y una vez donde se presenta por la vista. Por ejemplo, en mi código generalmente defino campos de modelos simples en XML:

<Property Name="City" Type="string" />

luego, para crear un cuadro de texto para editar la ciudad, simplemente arrastro la propiedad "Ciudad" a mi vista y termino con este XAML:

<TextBox Text="{Binding City}" />

Entonces, "Ciudad" se menciona solo en dos líneas de código en toda mi aplicación (a menos que tenga otro cuadro de texto "Ciudad" en otro lugar). En Cocoa se hará referencia a "Ciudad" al menos cinco veces.

Encuadernación directamente al modelo

En Cocoa, un único controlador solo es adecuado para una sola vista: si crea una nueva vista para el mismo modelo, necesita un nuevo controlador. En WPF / NET hay una mejor manera de hacerlo, aunque aún puede crear controladores si realmente lo desea.

En WPF / NET, una vista generalmente vinculará la mayoría de sus controles directamente con el modelo (vea el ejemplo de mi ciudad anterior). Otros controles estarán vinculados a un "Modelo de vista" que modela la información de estado asociada con la vista actual. Por ejemplo, si está buscando, el "Modelo de vista" contendrá la cadena de búsqueda para que la vista pueda usarla tanto para filtrar los resultados como para buscar el texto de búsqueda.

En WPF / NET también puede vincular múltiples propiedades de un control a la misma o diferentes partes de su modelo (o modelo de vista):

<TextBox Text="{Binding AmountToTransfer}"
         Background="{edf:Binding UserIsHappy ? Green : White}" />

La diferencia es que en WPF un modelo de vista generalmente se puede compartir entre varias pantallas que son similares en su comportamiento, por lo que en una aplicación LOB cuando creas una vista personalizada, todo lo que necesitas hacer es editar un único archivo.

Arquitectura de comando

En Cocoa, un botón almacena su objetivo y acción en una NSActionCell dentro de la vista, lo que significa que invocará un método específico en un objeto específico (generalmente el controlador). En WPF / NET, un botón tiene un evento Click que funciona de la misma manera, pero también tiene una propiedad Command que le permite invocar un comando.

Los comandos en WPF son muy potentes, ya que un único comando puede ser compartido en toda la aplicación. Por ejemplo, WPF define un comando Eliminar. Siempre que su modelo responda a este comando, agregar un botón "Eliminar" a su vista es tan simple como seleccionar el comando Eliminar en la ventana de propiedades, que crea este XAML:

<Button Command="Delete" />

Esto es todo lo que tiene que hacer para obtener un botón de eliminación funcional que elimine el objeto de una lista. Tenga en cuenta el comando integrado Delete también:

• Tiene una tecla vinculante para la tecla Eliminar en el teclado
• Proporciona texto apropiado para el idioma ("Eliminar" o "Eliminar" o "Löschen" o "Supprimer" o ...)
• Incluye una sugerencia de herramienta descriptiva

Un comando se enruta a los objetos y modelos ancestrales, por lo que en una aplicación típica casi nunca es necesario especificar qué objeto recibe el comando.

Hojas de estilo

En Cocoa no hay ningún mecanismo para aplicar hojas de estilo a los paneles y hacer que afecten a todos los controles del panel, ya sea en tiempo de diseño o en tiempo de ejecución. Por ejemplo, una aplicación puede querer:

• Haga todos los cuadros de texto en un área determinada de solo lectura
• Hacer todas las etiquetas en negrita
• Dé a todos los ComboBoxes un fondo verde claro
• Añadir espaciado uniforme entre un conjunto de botones
• Use una marca de verificación verde grande para un conjunto de casillas de verificación
• Agregue un botón Eliminar a todas las listas
• Haga que todos los botones Eliminar aparezcan como una X roja "cepillada" en lugar de como un botón tradicional
• Realice la misma configuración en varios elementos separados

WPF / NET hace que todas estas operaciones sean triviales mediante el uso de estilos. Puede establecer cualquier propiedad de cualquier objeto a través de un estilo. Los estilos se pueden establecer implícitamente por tipo de objeto o explícitamente, por ejemplo:

<Button Style="{StaticResource DeleteButtonStyle}" />

Las hojas de estilo se pueden definir en cualquier lugar que desee: en una biblioteca de control, en el nivel de la aplicación, específica de un "tema", en una ventana, en un dicionario de recursos de control específico o directamente en un control.

Plantillas de control

En Cocoa no se puede hacer mucho para cambiar el diseño visual de los controles, excepto para subclasificarlos, ya que cada uno dibuja su propia apariencia. En WPF / NET, la apariencia de un control viene dada por su plantilla, que puede reemplazarse libremente con casi cualquier cosa que se le ocurra.

Por ejemplo:

• Puede usar un ListBox en sus menús desplegables y configurarlo para que se vea como elementos de menú normales (con una casilla de verificación junto al elemento seleccionado actualmente)
• Puede cambiar un TreeView para que aparezca como una secuencia de ListBoxes en lugar de un árbol
• Puede cambiar el "pulgar" de un control deslizante para que aparezca como un símbolo comercial o un personaje de dibujos animados dependiendo de su público objetivo (deslice una bombilla o Mickey Mouse de un lado a otro)
• Puede cambiar un control deslizante para que aparezca como un control o para seguir un camino no lineal
• Puede cambiar un CheckBox para que aparezca como un clic en / botón de apagado, un ícono de candado que se abre y se cierra, o una puerta que se abre y se cierra

Las plantillas de control y las plantillas de datos también pueden incluir animaciones incorporadas, por lo que, por ejemplo, su puerta puede animar realmente el abrir y cerrar cuando hace clic en él. Esto es trivialmente simple de hacer en Expression Blend: toma unos 20 clics del mouse. Solo crea dos animaciones lineales y adjúntalas a desencadenantes de eventos.

Controles personalizados

Cocoa y WPF le permiten clasificar los controles existentes para crear otros nuevos. En Cocoa, los nuevos controles se serializan al archivo .xib / .nib. En WPF son parte del XAML al igual que los controles incorporados:

<StackPanel>
  <TextBlock>
    Hello, <Run Text="{Binding FirstName}" />.
    <Bold>Good morning!</Bold>  How are you today?
  </TextBlock>
  <my:JoySelector Happiness="{Binding Happiness}" />
</StackPanel>

En este ejemplo, JoySelector sería un control que definí y la Felicidad sería una de sus propiedades.

Una gran diferencia entre Cocoa y WPF está en el dibujo de los controles personalizados. En Cocoa debe codificar llamadas a primitivas de dibujo para crear la apariencia de su control. Si bien esta es una opción en WPF, generalmente se hace mucho más fácilmente usando una plantilla de control.

Por ejemplo, en Cocoa puedes escribir:

CGSize size = CGSizeMake(30, 20);
UIGraphicsBeginImageContext(size);
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextSetRGBFillColor(context, 1.0, 1.0, 0.0, 0.0);
CGContextFillEllipseInRect(context, rect);
UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
return image;

mientras que en WPF usando XAML el equivalente sería:

<Ellipse Width="30" Height="20" Fill="Red" />

o en WPF en el código (C #):

return new Ellipse { Width=30, Height=30, Fill=Brushes.Red };

Un ControlTemplate puede, por supuesto, tener varios elementos:

<ControlTemplate TargetType="my:JoySelector">
  <Grid Width="50" Height="50">
    <Ellipse Width="30" Height="20" Fill="Red" VerticalAlignment="Left" />
    <Path Data="M0,0 L3,5 L8,8 L5,3 L0,0" Fill="Blue" />
    <ComboBox
      SelectedItem="{TemplateBinding Happiness}"
      Style="{StaticResource JoySelectorBoxStyle}" />
  </Grid>
</ControlTemplate>

Normalmente, este XAML se creará en Expression Blend haciendo clic con el botón derecho en JoySelector, seleccionando Editar> Plantilla> Crear nuevo, dibujando la Elipse, Ruta y ComboBox usando las herramientas de dibujo, y seleccionando el enlace y estilo de ComboBox desde la ventana Propiedades.

Plantillas de datos

En Cocoa, si desea una lista o árbol de artículos de varios tipos, como un inventario de equipos en un juego o una lista de varios tipos de cuentas (inversión, mercado monetario, ahorros), prácticamente tiene que codificarlo todo usted mismo. En WPF / NET puede usar DataTemplates.

Por ejemplo, si cada arma tiene una "fuerza de ataque" y una "fuerza de defensa", puede incluir una plantilla de datos como esta:

<DataTemplate TargetType="game:Weapon">
  <DockPanel TextElement.FontWeight="Bold">
    <Image Source="{StaticResource WeaponDrawing}" />
    <TextBlock Text="{Binding WeaponName}" DockPanel.Dock="Top" />
    <TextBlock Text="{Binding HitStrength}" Foreground="Red" />
    <TextBlock Text="{Binidng DefenseStrength}" Foreground="Blue" />
  </DockPanel>
</DataTemplate>

Otros objetos del juego usarían diferentes plantillas, luego el inventario podría mostrarse usando un ListBox usando un WrapPanel para establecerlos en orden de lectura. (Tenga en cuenta que en WPF, un ListBox no tiene que presentar sus elementos en una lista vertical: se puede usar cualquier panel).

Esta misma técnica es importante en las aplicaciones LOB: por ejemplo, puede tener una representación predeterminada para una Factura que esté configurada en una DataTemplate para toda la aplicación, de modo que cualquier parte de su aplicación que presente listas de Facturas las mostrará automáticamente en el formato predeterminado . Esto podría incluir un icono, el número de factura, una ventana emergente de información sobre herramientas con información adicional y un menú contextual que permite abrir y / o editar la factura.

Disparadores y animaciones

En Cocoa puedes hacer animaciones, pero debes escribir el código tanto para crear la animación como para aplicar la animación. En WPF puede definir la animación usando una línea de tiempo en Expression Blend, y establecer EventTriggers y PropertyTriggers en la vista para controlar cuándo se ejecuta. Para crear una animación que agita un botón, simplemente haga clic con el botón derecho para crear una línea de tiempo, configure la posición del botón, la rotación o la escala con el mouse en algunos puntos de la línea de tiempo y cambie el EventTrigger creado automáticamente para el evento que desee para activar el botón.

Cocoa no tiene una tienda de propiedades de animación o un mecanismo de coerción, por lo que los cambios realizados por la animación son permanentes: no puede eliminar la animación y los valores de propiedad revertir. Además, no puede animar las propiedades de los recursos compartidos (como los colores del pincel) sin copiarlos manualmente, y no puede animar a valores fuera de rango y hacer que el control coaccione al valor apropiado. En WPF, el sistema de animación tiene la capacidad de realizar un seguimiento de los valores de animación, valores encuadernados, valores predeterminados y valores forzados por separado para que no se encuentre con estos problemas.

En WPF puede establecer animaciones para que se ejecuten en eventos de IU como clics de botón, cambios de estado de propiedad (incluidos los cambios de datos en el modelo), eventos generados por el modelo, para ejecutarlos continuamente o por código.

En WPF puede crear clases de animación personalizadas y usarlas con Expression Blend como si fueran parte de WPF. También puede dibujar los objetos de Geometría utilizados por la Animación de ruta integrada en lugar de codificarlo usted mismo.

Tenga en cuenta que WPF tiene la capacidad de construir e iniciar animaciones en código si realmente lo desea. También tenga en cuenta que incrustar una animación desde una aplicación separada, como Quartz Composer, no es lo mismo que animar las propiedades de los objetos UI. Tanto Cocoa como WPF pueden incorporar animaciones creadas con otras tecnologías, pero con WPF puede usar Expression Blend para crear una línea de tiempo que anime cualquier parte de su UI.

Conversiones como parte de vinculante

Cocoa tiene la capacidad de realizar conversiones desde y hacia un único valor utilizando un NSFormatter. Algo más complicado debe hacerse en el controlador. En WPF puede usar un StringFormat para los casos simples de la cubierta de NSFormatters integrada de Cocoa, pero también puede especificar un IValueConverter o IMultiValueConverter para implementar la conversión personalizada de valores. Por ejemplo, puede agregar un convertidor personalizado a una serie de datos de gráfico de barras para hacer que los elementos de datos en el gráfico de barras se animen a sus valores objetivo en secuencia rápida (conocida como animación "gelatina"). Los conversores de WPF se pueden usar de una manera o de dos vías y pueden convertir un solo valor o valores múltiples.

Las conversiones también le permiten enlazar a propiedades o cálculos múltiples y formatear el resultado, por ejemplo:

<TextBlock Text="{edf:Binding (Height + Width)/2, StringFormat=0.000}" />

Este tipo de enlace con la conversión no es posible en Cocoa.

Controles de terceros

En Cocoa generalmente solo puede incluir widgets UI diseñados para Cocoa en su aplicación. En WPF puede incluir controles WPF pero también puede incluir secciones de su UI desarrolladas usando WinForms, MFC, HTML, Java, Flash y otras tecnologías. WPF proporciona instalaciones para integrar estas otras tecnologías directamente en WPF, incluso hasta el punto de utilizar su sistema de marcado para construir los objetos y establecer sus propiedades, por ejemplo:

<StackPanel>
  <TextBlock>Here is a WinForms control:</TextBlock>
  <WindowsFormsHost>
    <tools:LegacyChartingControl
      Width="20" Height="30"
      Title="Graph of something"
      SeriesXMin="0"
      SeriesXMax="10" ... />
  </WindowsFormsHost>
</StackPanel>

Medios creados externamente

Tanto Cocoa como WPF pueden incluir medios como videos, animaciones y mapas de bits que se han creado en herramientas de terceros. Cada entorno admite todos los tipos de medios admitidos por el sistema operativo subyacente. WPF proporciona un poco más que Cocoa en términos de control de los medios, por ejemplo, si configura el comando de un botón en "Comandos de medios.NextTrack" o "Comandos de medios.FastForward", los medios responderán automáticamente de manera adecuada. Además, WPF proporciona algunas mejoras en la carga asincrónica de medios.

WPF (a través de Silverlight) también es compatible con varios códecs de audio y video de alta calidad de manera totalmente multiplataforma, por lo que puede confiar en que sus medios funcionen en cualquier plataforma.

También hay herramientas que le permiten convertir dibujos creados en herramientas como Illustrator o animaciones creadas en herramientas como Flash en dibujos y animaciones nativas de WPF, lo que le permite manipular y vincular sus propiedades con datos. Por ejemplo, puede tomar una animación de bola que rebota creada en Flash y vincular datos con su coordenada Y en el apogeo para que la pelota rebote más o menos según el valor de los datos en su modelo.

Recolección de basura

A partir de 2007, la recolección de basura finalmente se admite en Cocoa / Obj-C, pero muchas bibliotecas aún no pueden manejarlo, por lo que la mayoría del código Cocoa que se está escribiendo hoy sigue utilizando la asignación de memoria manual con recuento de referencias. Por lo tanto, incluso hoy en día, todavía hay una gran cantidad de "[abc release]" salpicados en todo el código de Cocoa. WPF / NET ha tenido recolección de basura desde el primer día, por lo que no tiene este problema.

Ejecución dentro del navegador web

Las aplicaciones de cacao están actualmente limitadas a la ejecución como aplicaciones de escritorio, mientras que WPF puede ejecutarse con la misma facilidad tanto en el navegador web como en el escritorio, utilizando tecnología XBAP o Silverlight.

Capacidad multiplataforma

La historia aquí es similar:

• Las aplicaciones Cocoa se ejecutan de forma nativa en Mac OS X, y también pueden ejecutarse en Windows y Linux utilizando Cocotron o GNUstep y restringiéndose a un subconjunto de características.

• Las aplicaciones WPF se ejecutan nativamente en Windows, y también se pueden ejecutar en Mac OS X y Linux utilizando Silverlight y restringiéndose a un subconjunto de las características.

La única diferencia significativa es que Silverlight puede ejecutarse en el navegador y tiene mucho mejor soporte de proveedor y herramientas que Cocotron o GNUstep.

Otras capacidades avanzadas de WPF

Hasta ahora no he encontrado ninguna capacidad en Cocoa que no esté también en WPF / NET, pero he encontrado muchas en WPF / NET que no están en Cocoa, por ejemplo:

• Todos los controles, como botones, cuadros de texto, cuadros combinados, etc., pueden funcionar tan bien en escenas 3D como en diseños 2D. También se pueden estirar, rotar, sesgar, etc. arbitrariamente
• Capacidades de dibujo avanzadas como PolyBeziers, geometrías combinadas, RenderTransform vs LayoutTransform, control de transparencia alfa, etc.
• Pinceles avanzados como pinceles de degradado, pinceles de imagen en mosaico y "Pinceles visuales" que le permiten crear un pincel arbitrariamente complejo para pintar; por ejemplo, puede pintar un reflejo de su ventana, incluidos todos sus controles.
• El subsistema de animación permite que prácticamente todas las propiedades estén animadas, por ejemplo, animé una propiedad de "Texto" de TextBox para que pareciera que el texto se estaba escribiendo.

Algoritmos y controladores de terceros

Cocoa / Obj-C puede llamar a bibliotecas precompiladas que utilizan convenciones de llamadas C y métodos de invocación de llamadas en objetos definidos en otros idiomas. Esto significa que generalmente se requiere una API estilo C para código de terceros que debe integrarse en su aplicación. WPF / NET puede incluir código escrito en más de 100 idiomas directamente en su aplicación y le permite acceder a todas las funcionalidades directamente. Además, también puede llamar a un código precompilado escrito en otros idiomas utilizando C, C ++, COM, DCOM, servicios web y otras convenciones de llamadas. Además, hay calzas de código abierto que permiten que el código de NET Framework llame directamente a una amplia variedad de otros lenguajes y sistemas. Esto significa que las aplicaciones de WPF casi nunca deben incluir más que una pequeña cantidad de código de pegamento para conectarse a un código de terceros, incluidos los controladores de dispositivos.

Comparación de lenguaje

Comparar Objective-C con C # es una tarea importante, y una que no intentaré. Baste decir que a partir de la versión 4.0, C # contiene todas las características de Objective-C y muchas, muchas, muchas más. Aprendí Objective-C en 1989, mucho antes de que C # fuera concebido, y en ese momento era un lenguaje increíblemente poderoso. Ahora, cuando lo uso, me estremezco, especialmente por la pérdida de LINQ y genéricos.

Pruebe este tipo de transformación de datos en Objective-C:

DataContext =
  from lesson in AllLessons
  where lesson.Active
  groupby lesson.Category into category
  select new
  {
    categoryName = category.Key.Name,
    lessonsInCategory =
      from lesson in category
      select new
      {
        lesson,
        fullName = lesson.ShortName + " " + lesson.Suffix,
        priority = rand.Next(10)
      }
  };

Si AllLessons se proporciona dinámicamente, puede vincular directamente este resultado en WPF (con <ListBox ItemsSource="{Binding}" /> ) y hacer que se actualice dinámicamente en tiempo real.

Al usar LINQ con C # también puede hacer combinaciones, ordenar, etc. No hay código de fondo para escribir, y IntelliSense de Visual Studio lo ayuda a completar los nombres de las propiedades, etc. a medida que edita e incluso subraya sus errores.

No conozco ninguna buena comparación entre Objective-C y C #, pero hay una buena comparación entre C # y Java en wikipedia que menciona muchas de las características de C # que también faltan en Objective-C.

Enlaces de idiomas

El cacao no está restringido a Objective-C, y WPF no está restringido a C #. Ambos son accesibles desde varios otros idiomas. La diferencia es que Cocoa está construido alrededor de Objective-C, por lo que usarlo de otro idioma puede ser bastante incómodo. Por ejemplo, las acciones se convierten en una llamada al método Objective-C que tiene una semántica muy diferente a Java u otros lenguajes. Por otro lado, WPF fue diseñado intencionalmente para no requerir ninguna característica especial de C # por lo que podría ser utilizado fácilmente desde otros idiomas. Por ejemplo, cuando se usa con Java (que carece de propiedades verdaderas), el PropertyDescriptor usa en su lugar los métodos get y set.

Además, debido a que está construido sobre el Marco NET, una aplicación WPF puede funcionar simultáneamente contra objetos y bibliotecas codificadas en múltiples idiomas. Esto significa que si encuentra una gran implementación de C ++, Haskell o Ruby de un algoritmo, puede simplemente usar el código sin reescribirlo en el idioma de su elección. Con Cocoa generalmente tiene que volver a escribir el código como Objective-C o crear código shim para llamar al otro idioma.

Ventajas comunes

Aquí hay varias ventajas de Cocoa sobre sus competidores que comparte con WPF:

• Funcionalidad de tipografía enriquecida
• Posibilidad de incluir gráficos en 3D
• Construido en la edición de texto enriquecido, incluida la revisión ortográfica
• Deshacer rehacer
• Agregar funcionalidad a clases existentes (categorías en Obj-C, propiedades y estilos adjuntos en WPF)
• Remoto fácil de llamadas de método

Notas finales

Al comparar Cocoa con WPF, debe comparar Interface Builder con Expression Blend, no con Visual Studio. Visual Studio está bien para escribir código, pero en mi opinión, Expression Blend es la única herramienta para diseñar la interfaz de usuario.

Para el desarrollo de aplicaciones prácticas, la principal diferencia entre WPF y Cocoa generalmente no son las capacidades gráficas más potentes de WPF, ya que pueden incluirse en una aplicación Cocoa codificándolas manualmente. La principal diferencia es el enlace de datos y la evolución de model-view-controller a model-view-viewmodel, lo que hace que WPF sea mucho más eficiente para desarrollar aplicaciones.

Pude haber perdido una mejora reciente de Cocoa en la descripción anterior, ya que no he usado Cocoa mucho recientemente. Si he sido injusto con Cocoa (o con WPF en este caso) de alguna manera, por favor agregue un comentario y dígame qué me perdí.

Answer 3

WPF es la parte de UI del framework .NET, por lo que si solo comparas las partes de UI, entonces podrías decir que es el marco correcto. Qt y Cocoa proporcionan mucho más (sockets, threading, etc.) que WPF (pero esas cosas están cubiertas en otras partes del framework .NET).

Obj-C es menos complejo que C ++ y C # pero, como todos los lenguajes de programación, tiene sus gotcha-moments. También es solo Mac, por lo que si se dirige a Windows o Linux, no es realmente una opción.

No hay mucha diferencia entre Outlets / Actions y Signals / Slots y esa es probablemente la razón por la que no tuve muchos problemas cuando me presentaron Cocoa Outlets / Actions (provenientes de un fondo de Qt). Entonces, si estuvieras trabajando en torno a ellos, probablemente estarías haciendo algo mal ...

En cuanto a los IDE, depende en gran medida del sistema operativo al que apunte, ninguno de ellos es mejor que los demás, todos hacen el trabajo, todos tienen sus fortalezas y debilidades (y problemas), todos tienen diseñadores de GUI y todos ellos funcionan de manera suficientemente diferente como para que la comparación entre ellos no tenga mucho sentido;). Entonces, lo que uso depende del sistema operativo del software que estoy escribiendo:

Mac OS X solamente -> Cocoa con Xcode Windows solamente -> Visual Studio (principalmente .NET framework) Cross platform -> QT con QtCreator (la misma plataforma de desarrollo en todos los sistemas operativos es una clara victoria en este caso)

En cuanto a la documentación, considero que la documentación de Qt es la más legible y la más fácil de navegar ... aunque utilizo Google la mayor parte del tiempo como mi documentación;)