¿Cómo decidir entre MonoTouch y Objective-C? [cerrado]

273

Después de asistir a una sesión hoy en Mono en un evento local .Net, el uso de MonoTouch fue "tocado" como una alternativa para el desarrollo de iPhone. Siendo muy cómodo en C # y .Net, parece una opción atractiva, a pesar de algunas peculiaridades de la pila Mono. Sin embargo, dado que MonoTouch cuesta $ 400, estoy un poco desgarrado si este es el camino a seguir para el desarrollo de iPhone.

¿Alguien tiene experiencia desarrollando con MonoTouch y Objective-C, y si es así, desarrollar con MonoTouch es mucho más simple y rápido que aprender Objective-C y, a su vez, vale los $ 400?

c# objective-c mono xamarin.ios jamesaharvey
fuente
13
Creo que muchos comentarios sobre MonoTouch no pueden ejecutarse en iOS ya no son válidos ya que Apple relajó la restricción de sus herramientas de desarrollo. Ver: apple.com/pr/library/2010/09/09statement.html
sivabudh

Respuestas:

520

He visto esta pregunta (y sus variaciones) mucho últimamente. Lo que me sorprende es la frecuencia con la que la gente responde, pero la poca respuesta .

Tengo mis preferencias (disfruto de ambas pilas), pero aquí es donde la mayoría de las "respuestas" comienzan a fallar. No debería ser sobre lo que quiero (o lo que alguien más quiere).

Así es como debería determinar el valor de MonoTouch: obviamente, no puedo ser objetivo, pero creo que esto es bastante fanático:

  • ¿Es esto por diversión o negocios? Si desea consultar en esta área, puede recuperar sus $ 399 muy rápidamente.

  • ¿Desea aprender la plataforma de adentro hacia afuera, o "solo" quiere escribir aplicaciones para ella?

  • ¿Te gusta .Net lo suficiente como para que usar una pila de desarrollo diferente te quite la diversión? Nuevamente, me gustan las dos pilas (Apple y Mono), pero para mí MonoTouch hace que la experiencia sea mucho más divertida. No he dejado de usar las herramientas de Apple, pero eso se debe principalmente a que realmente disfruto de ambas pilas . Amo el iPhone y amo .Net. En ese caso, para mí, MonoTouch era obvio.

  • ¿Te sientes cómodo trabajando con C? No me refiero a Objective-C, pero C: es importante porque Objective-C es C. Es una versión OO agradable, elegante y amigable, pero si los punteros te dan los heebie-jeebies, MonoTouch es tu amigo. Y no escuches a los detractores que piensan que eres un experto en desarrollo si sucede que no te gustan los punteros (o C, etc.). Solía ​​caminar con una copia de la referencia de bolsillo de IBM ROM BIOS, y cuando estaba escribiendo ensamblaje y forzando a mi computadora a modos de video divertidos y escribiendo mis propios bits de representación de fuente para ellos y sistemas de ventanas (ciertamente basura), no lo hacía. No creo que los desarrolladores de QuickBasic fueran wusses. Yo estabaun desarrollador de QuickBasic (además del resto). Nunca cedas ante el machismo nerd. Si no le gusta C, y si no le gustan los punteros, y si desea mantenerse lo más lejos posible de la gestión de memoria manual (y, para ser justos, no está nada mal en ObjC), entonces. .. MonoTouch. Y no te preocupes por eso.

  • ¿Te gustaría dirigirte a usuarios o empresas? No me importa mucho, pero todavía hay personas en Edge, y el hecho es que puedes crear un paquete de descarga mucho más pequeño si usas la pila de Apple. He estado jugando con MonoTouch, y tengo una pequeña aplicación decente que, una vez comprimida, se reduce a aproximadamente 2.7 MB (cuando envía su aplicación para su distribución, la comprime, cuando las aplicaciones se descargan de la tienda, ' vuelva a comprimir, así que cuando descubra si su aplicación va a llegar por debajo del límite de 10 MB OTA, cierre primero la ventosa; se sorprenderá gratamente con MonoTouch). Pero, aparte de la felicidad MT, medio meg frente a casi tres (por ejemplo) es algo que podría ser importante para usted si se dirige a usuarios finales. Si está pensando en el trabajo empresarial, unos pocos MB no importan en absoluto. Y, para que quede claro: pronto enviaré una aplicación basada en MT a la tienda, y no tengo ningún problema con el tamaño. No me molesta en absoluto. Pero si eso es algo que preocuparíausted , entonces la pila de Apple gana este.

  • ¿Funciona algún XML? MonoTouch. Período.

  • Manipulación de cuerdas? Manipulación de la fecha? ¿Un millón de otras pequeñas cosas a las que nos hemos acostumbrado con los marcos de fregadero de cocina y todo de .Net? MonoTouch.

  • ¿Servicios web? MonoTouch.

  • Sintácticamente, ambos tienen sus ventajas. Objective-C tiende a ser más detallado donde tienes que escribirlo . Te encontrarás escribiendo código con C # que no tendrías que escribir con ObjC, pero va en ambos sentidos. Este tema en particular podría llenar un libro. Prefiero la sintaxis de C #, pero después de superar mi reacción inicial de este es otro mundo a Objective-C, aprendí a disfrutarla un poco. Me burlo un poco en las conversaciones ( es extraño para los desarrolladores que están acostumbrados a C # / Java / etc.), pero la verdad es que tengo un punto en forma de Objective-C en mi corazón que me hace feliz.

  • ¿Planeas usar Interface Builder? Porque, incluso en esta versión inicial, me encuentro trabajando mucho menos para construir mis interfaces de usuario con IB y luego usarlas en el código. Parece que faltan pasos completos de la forma de hacer las cosas de Objective-C / IB, y estoy bastante seguro de que es porque faltan pasos completos de la forma de hacer las cosas de Objective-C / IB. Hasta ahora, y no creo que haya probado lo suficiente, pero hasta ahora , MonoTouch es el ganador aquí por la cantidad de trabajo que tiene que hacer.

  • ¿Crees que es divertido aprender nuevos idiomas y plataformas? Si es así, el iPhone tiene mucho que ofrecer, y la pila de Apple probablemente lo sacará de su zona de confort, lo que, para algunos desarrolladores, es divertido (Hola, soy uno de esos desarrolladores, bromeo al respecto y doy Apple es un momento difícil, pero me he divertido mucho aprendiendo el desarrollo de iPhone a través de las herramientas de Apple).

Hay tantas cosas a considerar. El valor es tan abstracto. Si hablamos del costo y de si vale la pena, la respuesta se reduce a mi primer ítem: si esto es por negocios, y si puede obtener el trabajo, recuperará su dinero de inmediato.

Entonces ... eso es lo más objetivo que puedo ser. Esta es una breve lista de lo que podría preguntarse, pero es un punto de partida.

Personalmente (dejemos caer la objetividad por un momento), amo y uso ambos. Y me alegro de haber aprendido la pila de Apple primero. Me fue más fácil ponerme en marcha con MonoTouch cuando ya conocía el mundo de Apple. Como han dicho otros, todavía vas a trabajar con CocoaTouch, solo estará en un entorno .Net.

Pero hay más que eso. Las personas que no han usado MonoTouch tienden a detenerse allí: "Es una envoltura, bla, bla, bla", eso no es MonoTouch.

MonoTouch le da acceso a lo que CocoaTouch tiene para ofrecer, al mismo tiempo que le da acceso a lo que (un subconjunto de) .Net tiene para ofrecer, un IDE con el que algunas personas se sienten más cómodas (yo soy uno de ellos), una mejor integración con Interface Builder , y aunque no puede olvidarse por completo de la administración de memoria, obtiene un buen margen de maniobra.

Si no está seguro, tome la pila de Apple (es gratis) y tome la pila de evaluación MonoTouch (es gratis). Hasta que se una al programa de desarrollo de Apple, ambos solo se ejecutarán contra el simulador, pero eso es suficiente para ayudarlo a descubrir si prefiere enormemente uno al otro, y es posible si MonoTouch, para usted, vale los $ 399.

Y no escuches a los fanáticos: tienden a ser los que no han usado la tecnología contra la que están criticando :)

Rory Blyth
fuente
50
Wow, Rory, gracias por tomarte el tiempo de responder mi pregunta con tanto detalle. Por lo que puedo decir, usted es el único que ha utilizado ambas opciones, que es de quien estaba buscando una respuesta. Definitivamente voy a intentarlo a ambos desde allí. Por cierto, te escuché en el podcast SO más reciente, ¿verdad? Buen material. ¡Gracias de nuevo!
jamesaharvey
17
Gracias por los comentarios :) Me he frustrado con algunos de los odios que he visto. Una y otra vez se responde a la pregunta con "¡¡¡Ur, un idiota para ritar el sistema opurante primero, más suelto !! ??" Lo cual es inútil e insultante. MonoTouch tiene sus puntos difíciles, pero esos tipos tienen un historial de genio. MT ha avanzado rápidamente y es más hermoso cada día. Sigo diciendo: dales un par de meses. Están siendo prudentes sobre las características, pero creo que vamos a ver cosas importantes . Me encanta la pila de Apple, pero ahora tengo otro patio de juegos, eso es algo bueno y estoy vertiginosa :)
Rory Blyth
44
@Stephan - Puede que no sea correcto decir lo que "falta" - Puedo hacer el trabajo con Cocoa. Se trata más de las API. Es mucho más fácil trabajar con cadenas, fechas, XML, etc., con .Net. No sé si está familiarizado con la forma .Net de hacer estas cosas, así como el alcance del soporte de MonoTouch para ellas, si no lo ha investigado, debería hacerlo, solo para comprobarlo. No quiero decir que hay cosas que no puedes hacer con Cocoa, pero hay muchas cosas que son mucho más fáciles de hacer con .Net. Analizar es más fácil en todos los ámbitos: las matemáticas de fechas son más fáciles en todos los ámbitos, etc.
Rory Blyth
3
También está el problema de la reutilización de su propio código en el iPhone / iPad con MT. Tenemos algunos códigos criptográficos y códigos de lógica de negocios que se ejecutan en nuestros servidores y contrapartes de escritorio, que podríamos recompilar con MT y usar en nuestra aplicación cliente iOS. Eso puede ser importante para algunos proyectos.
Monoman
2
También vale la pena considerar el hecho de que, aunque la licencia cuesta $ 400, también hay una suscripción de mantenimiento que debe renovar (por razones obvias) cada año: $ 250. Probablemente sea un precio justo, pero vale la pena tenerlo en cuenta.
Amc_rtty
62

Hay muchos rumores en esta publicación de desarrolladores que no han probado MonoTouch y Objective-C. Parece ser que los desarrolladores de Objective-C son los que nunca han probado MonoTouch.

Obviamente soy parcial, pero puedes ver lo que la comunidad MonoTouch ha estado haciendo en:

http://xamarin.com

Allí encontrará varios artículos de desarrolladores que se han desarrollado tanto en Objective-C como en C #.

miguel.de.icaza
fuente
29
@NSResponder - ¿Has usado MonoTouch? Es una versión v1.x, prácticamente nueva, y ya es sorprendente. Pruébalo antes de comentarlo. Hay grandes cambios (su integración de Interface Builder es mucho mejor que la de Xcode), y hay pequeños cambios (compare la forma de ObjC / Cocoa de obtener la carpeta de documentos del usuario en comparación con la de MT, por ejemplo). Todavía uso la pila de Apple para algunas cosas, pero la MT es hermosa y está llena de potencial. En serio, solo pruébalo. O mire cómo se han vinculado las API de Cocoa, no tiene que usarlas, simplemente no arruine el trabajo sin conocerlo .
Rory Blyth el
¡Si! Además, algunas de las nuevas características de C # 5.0 hacen que la codificación sea mucho más divertida en comparación con el objetivo-c.
harsimranb
39

Entonces, mi respuesta a una pregunta similar anterior es aprender Objective-C. (Además, no se olvide del soporte de depuración)

Esto probablemente ofenderá a algunos, pero para ser honesto, si va a hacer un desarrollo serio, debe aprender Objective-C. No conocer Objective-C en el desarrollo de iPhone solo será un obstáculo. No podrás entender muchos ejemplos; tiene que lidiar con las peculiaridades de Mono, mientras que si tuviera un conocimiento práctico de Objective-C podría obtener mucho más de la documentación de la plataforma.

Personalmente, no entiendo la posición que dice aumentar la cantidad de información que necesita a favor de usar Mono sobre el idioma nativo de la plataforma. Me parece algo contraproducente. Creo que si esta es una propuesta muy costosa (aprender un nuevo lenguaje), entonces puede valer la pena dedicar un tiempo a conceptos de programación fundamentales para que aprender nuevos idiomas sea una propuesta bastante barata.

Otro usuario también escribió esto:

Monotouch es más fácil para ti ahora. Pero más difícil después.

Por ejemplo, ¿qué sucede cuando salen nuevas semillas que necesita probar pero romper MonoTouch por alguna razón?

Al seguir con Mono, cada vez que busca recursos para frameworks, debe traducir mentalmente cómo los va a usar con Mono. Los binarios de su aplicación serán más grandes, su tiempo de desarrollo no será mucho más rápido después de unos meses en Objective-C, y otros desarrolladores de aplicaciones tendrán una ventaja mucho mayor sobre usted porque están utilizando la plataforma nativa.

Otra consideración es que está buscando usar C # porque está más familiarizado con el lenguaje que Objective-C. Pero la gran mayoría de la curva de aprendizaje para el iPhone no es Objective-C, son los marcos, a los que también tendrá que recurrir con C #.

Para cualquier plataforma, debe usar la plataforma que expresa directamente la filosofía de diseño de esa plataforma, en el iPhone, que es Objective-C. Piense en esto desde el ángulo inverso, si un desarrollador de Linux acostumbrado a programar en GTK quisiera escribir aplicaciones de Windows, ¿recomendaría seriamente que no usaran C # y se apegaran a GTK porque era "más fácil" para ellos hacerlo?

BobbyShaftoe
fuente
12
Probablemente, sin querer, haya tergiversado la MT. No es para nada, ni remotamente, análogo al uso de GTK para escribir aplicaciones Win. Las fijaciones de MT son muy fieles a CocoaTouch. En realidad, han mejorado algunas de las convenciones de API de CT. Pero no está escribiendo sus aplicaciones utilizando, por ejemplo, una abstracción basada en formularios Windows Forms sobre CT. MT con MonoDevelop tiene una mejor integración con IB que Xcode (si lo desea), y a menudo puede hacer las mismas cosas en la mitad del código o menos. Se está mejorando el tamaño binario, y las herramientas (generador de encuadernación, etc.) son mejores todo el tiempo. Una aplicación MT es una aplicación nativa.
Rory Blyth
77
Para dar ejemplos en lugar de esperar que tomes mi (obviamente) opinión de MT-fanboy por su cuenta, puedo hacer cosas como (y esto es solo un pequeño subconjunto de ventajas): Crear una propiedad con una línea; tome una referencia a la carpeta de documentos sin espeleología ridícula (una aplicación tiene una carpeta de documentos, siempre en el mismo lugar, ¿por qué todo el trabajo extra para "encontrarla"); use el marco .Net donde Cocoa apesta (NSDate, ¿alguien?); usar habilidades básicas para aplicaciones empresariales; use bits XML modernos y adecuados (me encanta cuando Cocoa se ahoga silenciosamente en los personajes y simplemente se detiene , sin bloqueo, solo se detiene ).
Rory Blyth
8
No digo que lo usaría para todo. Me gusta ObjC y todavía lo uso. Y, si el rendimiento es un problema, tengo un control más granular sobre lo que está sucediendo. Pero ... hay momentos en que la MT tendrá más sentido, y creo que hará que el iPhone sea una opción viable para el desarrollo empresarial. Lanza una piedra al aire y golpearás a un desarrollador de .Net. La mayoría de las empresas no tienen desarrolladores de ObjC internos. Y para el trabajo empresarial, no deberían tener que hacerlo. MT es mucho más fácil para trabajar con servicios web y bases de datos. Realmente puedes escribir muchos tipos de aplicaciones con MT con la mitad del código que tomaría en ObjC.
Rory Blyth
8
Finalmente (podría continuar, pero creo que estoy haciendo un punto importante), los cambios que "rompen" MonoTouch probablemente tienen la misma probabilidad de romper las aplicaciones ObjC. Una vez que su aplicación está en la tienda, es una aplicación nativa de iPhone (como debe ser). En última instancia, las llamadas no son diferentes: el mismo tiempo de ejecución que las aplicaciones creadas con la pila de Apple. Si su aplicación MT se rompe debido a un cambio en el entorno de tiempo de ejecución, también lo harán las aplicaciones creadas con ObjC. Y el equipo de MT ha estado al tanto de todo esto, lanzando actualizaciones y correcciones de errores rápidamente. Los enlaces de MT se asignan lo suficientemente cerca de los CT como para que la probabilidad de cualquier problema real sea baja. Aight - Me callo ahora :)
Rory Blyth
27

Usar Mono no es una muleta. Hay muchas cosas que agrega al iPhone OS. LINQ, WCF, código para compartir entre una aplicación Silverlight, una página ASP.NET, una aplicación WPF, una aplicación Windows Form, y también hay mono para Android y también funcionará para Windows Mobile.

Por lo tanto, puede pasar mucho tiempo escribiendo Objective-C (verá en muchos estudios que el mismo código de muestra en C # es significativamente menos para escribir que OC) y luego DUPLICAR todo para otras plataformas. Para mí, elegí MonoTouch porque la aplicación en la nube que estoy escribiendo tendrá muchas interfaces, siendo el iPhone solo una de ellas. Tener transmisión de datos WCF desde la nube a la aplicación MonoTouch es increíblemente simple. Tengo bibliotecas principales que se comparten entre las diversas plataformas y luego solo necesito escribir una capa de presentación simple para las implementaciones de iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET. Volver a crearlo todo en Objective-C sería una enorme pérdida de tiempo tanto para el desarrollo inicial como para el mantenimiento, ya que el producto continúa avanzando, ya que toda la funcionalidad debería replicarse en lugar de reutilizarse.

Las personas que insultan a MonoTouch o insinúan que los usuarios de él necesitan una muleta carecen del panorama general de lo que significa tener el marco .NET a su alcance y tal vez no entienden la separación adecuada de la lógica de la presentación de una manera que se puede reutilizar en plataformas y dispositivos.

Objective-C es interesante y muy diferente de muchos lenguajes comunes. Me gusta un desafío y aprender diferentes enfoques ... pero no cuando hacerlo impide mi progreso o crea una codificación innecesaria. Hay algunas cosas realmente buenas sobre el marco del SDK de iPhone, pero toda esa grandeza es totalmente compatible con MonoTouch y elimina toda la administración manual de memoria, reduce la cantidad de código requerido para realizar las mismas tareas, me permite reutilizar mis ensamblajes y mantiene abiertas mis opciones para poder moverme a otros dispositivos y plataformas.

Pablo
fuente
19

Cambié. Monotouch me permite escribir aplicaciones al menos 3-4 veces más rápido (4 aplicaciones por mes en comparación con mi anterior 1 por mes en Obj C)

Mucho menos mecanografía.

Solo mi experiencia.

Ian Vink
fuente
2
"4 aplicaciones por mes": cuando la cantidad es más importante como la calidad. MT es como McDonalds. Pero obtienes mejor comida en XCode-Restaurant.
netshark1000
2
Aunque los resultados hablan de manera diferente, Rdio e iCircuit son aplicaciones MT demostradas por Steve Jobs. C # y MT se deshacen del trabajo de fontanería que obj-C te obliga a hacer.
Ian Vink
17

Si esta es la única aplicación para iPhone que desarrollará, y también tiene cero interés en desarrollar aplicaciones para Mac, entonces MonoTouch probablemente valga la pena.

Si crees que alguna vez desarrollarás más aplicaciones para iPhone, o si alguna vez querrás hacer un desarrollo nativo de Mac, probablemente valga la pena aprender Objective-C y los marcos asociados. Además, si eres el tipo de programador que disfruta aprender cosas nuevas, es un nuevo paradigma divertido de estudiar.

Febo
fuente
66
Si esta es la única aplicación para iPhone que desarrollarás, los $ 99 / año tampoco valen la pena.
Dinah
Puede usar las mismas herramientas de desarrollo de C # para crear aplicaciones para Mac. De hecho, puede compartir código entre las aplicaciones de iPhone C # y Mac C #. MonoTouch ahora se llama Xamarin
Ian Vink
9

Personalmente, creo que lo pasarás mejor aprendiendo Objective-C.

En breve:

  • "Learning Objective-C" no es tan desalentador como podría pensar, incluso puede disfrutarlo después de las primeras semanas
  • Ya está familiarizado con la sintaxis de "estilo C" con muchos * & () {}; En todas partes
  • Apple ha hecho un muy buen trabajo documentando cosas
  • Interactuará con el iPhone de la manera prevista por Apple, lo que significa que obtendrá los beneficios directamente de la fuente, no a través de algún filtro.

He descubierto que se supone que los proyectos como Unity y MonoTouch "le ahorrarán tiempo", pero en última instancia, deberá aprender su lenguaje específico de dominio de todos modos y, en ocasiones, tendrá que esquivar las cosas. Probablemente, todo eso te llevará tanto tiempo como aprender el idioma que estabas tratando de evitar (en tiempo calendario). Al final, no ahorró tiempo y está estrechamente vinculado a algún producto.

EDITAR: Nunca quise implicar nada negativo sobre .NET. Soy un gran admirador. Mi punto es que agregar más capas de complejidad solo porque aún no te sientes cómodo con la peculiar notación de corchetes objc realmente no tiene mucho sentido para mí.

Actualización de 2019: son 7 años después. Todavía me siento igual, si no más. Claro, 'lenguaje específico de dominio' puede haber sido un término incorrecto para usar, pero todavía creo que es mucho mejor escribir directamente para la plataforma con la que está trabajando y evitar las capas y abstracciones de compatibilidad tanto como sea posible. Si le preocupa la reutilización y el reprocesamiento de códigos, en general, cualquier funcionalidad que su aplicación multiplataforma necesite realizar probablemente se pueda lograr con las tecnologías web modernas.

slf
fuente
12
En primer lugar, C # no es un "lenguaje específico de dominio", ni mucho menos. Es una habilidad básica. Eso es parte del valor de MonoTouch. Se podría argumentar (de manera injusta e inexacta) que ObjC es un DSL en el sentido de que la mayoría de los desarrolladores (fuera de los laboratorios financieros y universitarios y sótanos) solo lo usarán para el desarrollo de OS X o iPhone. Pero no lo es. Al igual que C #, es un lenguaje versátil que básicamente existe para permitirle centrarse en los marcos en lugar del lenguaje en sí (creo que estamos de acuerdo allí). Pero tenga en cuenta que su código ObjC se romperá con las actualizaciones de Apple. Ese no es un problema específico de MT.
Rory Blyth el
3
MT podría incluso salvarte en algunos casos porque existe esta capa de abstracción. ¿Apple modifica una API? Bueno, su aplicación ObjC y su aplicación MT equivalente (supongamos que existe) se romperán. Los chicos de MT podrían lanzar una solución provisional para modificar cómo la API MonoTouch maneja la llamada detrás de escena. Su código MT no tendría que cambiar, simplemente podría reconstruir con la versión provisional de MT. Sí: esta es una solución sucia que fácilmente podría generar problemas, pero desaprobar adecuadamente la API MT provisional proporcionaría a los desarrolladores tiempo para manejar el cambio sin problemas y ganar tiempo para una solución real .
Rory Blyth el
44
Además, como MT es nuevo, ahora es mucho más fácil crear sus propios enlaces si es necesario (MT 1.2). No eres completamente dependiente de las personas de MT para hacer todo ese trabajo (aunque lo están haciendo), y nunca lo hiciste. Tienen formas muy simples de crear enlaces. Exponen suficiente tiempo de ejecución de ObjC con los marcos de trabajo de MT para que no esté bloqueado en su forma de hacer las cosas. He reimplementado enlaces solo para ver si me gusta más. Puede ignorar los marcos MT y enviar y recibir mensajes "manualmente" si lo desea, y se necesita poco código. Son personas inteligentes. Confía en ellos :)
Rory Blyth el
2
Creo que slf no es consciente del hecho de que Monotouch es solo C # (con GC) que se une directamente a las bibliotecas ObjC + bibliotecas .NET opcionales. Entonces todavía usa la API proporcionada por apple. Pero con una sintaxis más ordenada y recolección de basura.
basarat
4

Para agregar a lo que otros ya han dicho (¡bueno!): Mi sensación es que básicamente estás duplicando la cantidad de errores de los que tienes que preocuparte, agregando los de MonoTouch a los que ya están en el sistema operativo iPhone. La actualización para nuevas versiones del sistema operativo será aún más dolorosa de lo normal. Yuck, todo alrededor.

El único caso convincente que puedo ver para MonoTouch son las organizaciones que tienen muchos programadores C # y códigos C # que deben aprovechar en el iPhone. (El tipo de tienda que ni siquiera parpadeará a $ 3500).

Pero para cualquiera que empiece desde cero, realmente no puedo verlo como valioso o sabio.

Sixten Otto
fuente
-1: ¿Qué quieres decir con "más errores"? ¿Hay una evidente falta de coincidencia de impedancia entre Mono y Objective-C?
Jim G.
4

Tres palabras: Linq a SQL

Sí, vale la pena los $.

Bryan
fuente
44
Con los enlaces de valor clave y los datos básicos de Objective-C obtienes algo muy similar a Linq-to-SQL. No es el mísmo. Tal vez no sea tan poderoso, pero cubriendo mucho del mismo terreno. Tenga en cuenta que Core-Data no es compatible actualmente con MonoTouch
philsquared
¿Linq to SQL es incluso relevante para una aplicación de iPhone? Funciona con SQLite?
bpapa
1
Y desea que sus usuarios compartan datos a través de una red. ¿Qué haces con SQL lite?
Bryan
"MonoTouch se basa en un perfil híbrido de .NET 2.0 y Silverlight 2 API" ¿Es compatible LINQ con los objetos?
Chris S
2

Algo que me gustaría agregar, a pesar de que hay una respuesta aceptada: ¿quién puede decir que Apple no solo rechazará las aplicaciones que tienen signos de haber sido creadas con Mono Touch?

bpapa
fuente
Ciertamente deberían, y también deberían rechazar las aplicaciones Flash, pero los términos de su App Store no impiden su uso.
NSResponder
3
@bpapa: esa es una preocupación totalmente válida, pero: 1) No hay razón para rechazar las aplicaciones (a los usuarios no les importa con qué están escritas sus aplicaciones, sino las propias aplicaciones), y 2) MonoTouch tiene mucho potencial para el desarrollo empresarial , y siempre que tenga una cuenta de desarrollo empresarial, Apple no puede evitar que distribuya su aplicación. Además, Apple acepta juegos creados con Unity. En definitiva, MT sigue las reglas. El proceso de Apple parece aleatorio a veces, pero ... MT sigue las reglas: |
Rory Blyth el
1
@bpapa: no sé cómo me perdí este comentario durante tanto tiempo, pero: 1) Toneladas de aplicaciones ObjC se "rompen" por usar API indocumentadas ("privadas") - FB, como notó, siendo una de ellas, aún FB todavía está vivo y disponible para descargar, 2) El problema de Unity se resolvió rápidamente, y Unity está de vuelta. - En lo que respecta a que Apple quiera que uses sus propias cosas, no estaría en desacuerdo, pero querer y exigir es muy diferente. En cuanto a las aplicaciones empresariales: puede implementar aplicaciones empresariales MT. Son solo binarios nativos. No veo el problema, ni entiendo por qué eres tan anti-MT.
Rory Blyth
1
Debo agregar que no es que "odie" la sintaxis de ObjC, sino que prefiero C #. También prefiero las formas del marco .Net a las del cacao. Manipulación de cadenas, procesamiento de XML, cualquier cosa que involucre fechas, etc. - Usaré los enlaces MT CocoaTouch para el trabajo de UI, pero para la mayoría de las otras tareas, el subconjunto del marco .Net que se incluye con MT hace la vida mucho más fácil. Podría seguir y seguir (como mi preferencia por encontrar ciertos errores en tiempo de compilación ). Soy crítico con la pila de Apple, pero no me desagrada. Es posible que te gusten MT y ObjC / etc.
Rory Blyth
1
Apple ha cambiado de opinión y ahora acepta aplicaciones en cualquier idioma / marco, y establece una lista de criterios más "objetivos" para aceptar aplicaciones en la tienda.
Monoman
2

Invertiría el tiempo en Objective-C principalmente por toda la ayuda que puede obtener de sitios como este. Una de las fortalezas de Objective-C es que puede usar código C y C ++, y hay muchos proyectos por ahí que están bien probados .

Otra cosa es que su código (idioma de elección) será compatible con Apple. ¿Qué es iOS 5.x, por ejemplo, elimina la compatibilidad con una solución de terceros como MonoTouch? ¿Qué le dirás a tus clientes entonces?

¿Quizás sea mejor usar una solución independiente de la plataforma como HTML5 si no está completamente listo para pasar a Objective-C?

Konrad77
fuente
Creo que el argumento de que al usar MonoTouch queda encerrado en un proveedor que Apple podría suspender para permitir / apoyar es muy fuerte. Podría terminar invirtiendo en una plataforma que está a merced de una Apple que tiene su propia plataforma de desarrollo de todos modos ...
jl.
2

He estado usando MonoTouch durante unos meses, porté mi aplicación a medio terminar de ObjectiveC para poder soportar Android en algún momento en el futuro.

Aquí está mi experiencia:

Bits malos:

  • Xamarin Studio. Los desarrolladores independientes como yo me veo obligado a usar Xamarin Studio. Está mejorando cada semana, los desarrolladores están muy activos en los foros identificando y reparando errores, pero todavía es muy lento, con frecuencia se cuelga, tiene muchos errores y la depuración también es bastante lenta.

  • Tiempos de construcción. Construir mi aplicación grande (vinculada) para depurar en un dispositivo puede llevar unos minutos, esto se compara con XCode, que se implementa casi de inmediato. Construir para el simulador (no vinculado) es un poco más rápido.

  • Problemas de MonoTouch. He experimentado problemas de pérdida de memoria causados ​​por el manejo del evento, y he tenido que poner algunas soluciones bastante feas para evitar las pérdidas, como adjuntar y desconectar eventos al ingresar y salir de las vistas. Los desarrolladores de Xamarin están buscando activamente problemas como este.

  • Bibliotecas de terceros. He pasado bastante tiempo convirtiendo / vinculando bibliotecas de ObjectiveC para usar en mi aplicación, aunque esto está mejorando con software automatizado como Objective Sharpie.

  • Binarios más grandes. Esto realmente no me molesta, pero pensé en mencionarlo. En mi opinión, un par de Mb adicionales no es nada en estos días.

Buenos bits:

  • Multiplataforma. Mi amigo está felizmente creando una versión de Android de mi aplicación desde mi base de código central, estamos desarrollando en paralelo y nos estamos comprometiendo con un repositorio remoto de Git en Dropbox, está funcionando bien.

  • .Red. Trabajar en C # .Net es mucho mejor que Objective C IMO.

  • MonoTouch. Casi todo en iOS se refleja en .Net y es bastante sencillo hacer que las cosas funcionen.

  • Xamarin Puedes ver que estos chicos realmente están trabajando para mejorar todo, haciendo que el desarrollo sea más fácil y sencillo.

Definitivamente recomiendo Xamarin para el desarrollo multiplataforma, especialmente si tiene el dinero para usar las ediciones Business o Enterprise que funcionan con Visual Studio.

Si solo está creando una aplicación para iPhone que nunca será necesaria en otra plataforma, y ​​es un desarrollador independiente, me quedaría con XCode y Objective C por ahora.

danfordham
fuente
Una actualización rápida de mi respuesta anterior. Desde que me mudé a una Mac más rápida, descubrí que los tiempos de compilación son mucho más rápidos, todavía no es instantáneo como XCode, pero está bien.
danfordham
1

Como alguien con experiencia tanto en C # como en Objective-C, diría que para la mayoría de las personas, Xamarin valdrá la pena.

C # es un lenguaje muy bien diseñado y las API de C # también están bien diseñadas. Por supuesto, las API de Cocoa Touch (incluido UIKit) también tienen un gran diseño, pero el lenguaje podría mejorarse de varias maneras. Al escribir en C #, probablemente será más productivo en comparación con escribir el mismo código en Objective-C. Esto se debe a varias razones, pero algunas serían:

  • C # tiene inferencia de tipos . La inferencia de tipos hace que escribir código sea más rápido, ya que no tiene que "conocer" el tipo en el lado izquierdo de una tarea. También hace que la refactorización sea más fácil y más ahorradora.

  • C # tiene genéricos , lo que reducirá los errores en comparación con el código equivalente de Objective-C (aunque hay algunas soluciones en Objective-C, en la mayoría de las situaciones los desarrolladores los evitarán).

  • Recientemente Xamarin agregó soporte para Async / Await , lo que hace que escribir código asincrónico sea muy fácil.

  • Podrá reutilizar parte de la base de código en iOS, Android y Windows Phone.

  • MonoTouch implementa en gran medida las API de CocoaTouch de una manera muy sencilla. Por ejemplo: si tienes experiencia con CocoaTouch, sabrás dónde encontrar clases para controles en MonoTouch (MonoTouch.UIKit contiene clases para UIButton, UIView, UINavigationController, etc ..., también MonoTouch.Foundation obtuvo clases para NSString, NSData, etc ...).

  • Xamarin brindará a los usuarios una experiencia nativa, a diferencia de soluciones como PhoneGap o Titanium.

Ahora Objective-C tiene algunas ventajas sobre C #, pero en la mayoría de las situaciones, escribir aplicaciones en C # generalmente dará como resultado menos tiempo de desarrollo y un código más limpio y menos trabajo para portar la misma aplicación a otras plataformas. Una excepción notable podrían ser los juegos de alto rendimiento que dependen de OpenGL.

Wolfgang Schreurs
fuente
-35

El costo de la biblioteca MonoTouch es completamente intrascendente. La razón por la que no deberías usar Mono para las aplicaciones de tu iPhone es que es una muleta. Si no puede molestarse en aprender las herramientas nativas, entonces no tengo motivos para creer que valga la pena descargar su producto.

Editar: 14/04/2010 Las aplicaciones escritas con MonoTouch no son elegibles para iTunes Store. Esto es como debería ser. Apple vio muchos puertos poco profundos en la Mac, utilizando kits de herramientas multiplataforma como Qt, o la propia reimplementación parcial de Adobe de la caja de herramientas del Sistema 7, y en resumen, simplemente no son lo suficientemente buenos.

NSResponder
fuente
14
La cuota de mercado para Mac OS X es muy pequeña, por lo que el iPhone es, para muchos, la única razón convincente para considerar siquiera molestarse con X-Code y ObjC. Ambos fueron geniales hace más de 15 años cuando era Project Builder e hicieron complicaciones y empaques entre plataformas, pero francamente, como alguien que usa una gama de plataformas, con herramientas y lenguajes posiblemente mejores ahora, no es sorprendente que los desarrolladores quieran aprovechar un común codebase y usar herramientas de desarrollo alternativas. No implica que sus creaciones estén por debajo de la media.
Iain Collins el
37
No sé, amigo ... Creo que Objective-C y CocoaTouch son una muleta. Si no está escribiendo ensamblaje, sentiré que simplemente no le importó demasiado, y no voy a descargar su aplicación (porque lo primero que hacen los usuarios, por supuesto, es verificar qué herramientas eran solían construir la aplicación de simulación de flatulencia que están descargando).
Rory Blyth
3
Andrew, no sabes de qué hablas. Objetivo-C no es remanso; Es la columna vertebral del entorno de desarrollo nativo para Mac, iPhone y iPad.
NSResponder
55
Entonces, ¿elige un ejemplo simple de algo que Apple ha incorporado en el marco y afirma su superioridad, mientras ignora convenientemente las partes del marco que son mucho más clásicas que el equivalente de C #? ¿No es algo así como un argumento de hombre de paja?
Andrew Rollings
8
Cambié a MonoTouch y he publicado 47 aplicaciones hasta ahora en 4.0 también. Lo hago a tiempo completo. Funciona muy bien, rápido. Solía ​​escribir en Objective C pero encuentro C # con Linq más rápido con mucho menos código para escribir.
Ian Vink