versiones para descargar desarrollo caracteristicas aprender iphone objective-c

iphone - descargar - swift para windows



¿Cuál es el estado de la programación no-Objective-C para iPhone? (18)

Después de pasar tres semanas aprendiendo programación de Objective-C y Cocoa para mi trabajo, me encargaron de investigar alternativas para el desarrollo de iPhone.

Conozco dos alternativas existentes y una posibilidad futura.

DO#

  • Xamarin (anteriormente MonoTouch) es una implementación de C # .NET con enlaces para funcionalidades específicas de iPhone como pantalla táctil y acelerómetro. Se integra con Xcode y Interface Builder y también permite la creación de enlaces personalizados de Objective-C.

Java

  • alcheMo-for-iPhone genera código C ++ para compilar para iPhone desde la fuente J2ME. También proporciona enlaces de pantalla táctil y acelerómetro.

Flash / ActionScript 3

  • Adobe ha anunciado que Flash Professional CS5 permitirá la implementación de aplicaciones Flash para iPhone. Aún no se han dado detalles.

Me gustaría saber si alguien tiene experiencia con alguno de estos. Nuestra compañía está buscando reutilizar el código usando estas soluciones, si es posible, en lugar de reescribir la misma funcionalidad en Objective-C.

EDIT: Sé que los inconvenientes de no usar Objective-C y los marcos proporcionados. Me gustaría recibir sugerencias sobre posibles soluciones de personas con experiencia que hagan esto en lugar de razones por las que Objective-C es mejor.

¿Qué hay del otro lenguaje incorporado, Javascript?

Puede ejecutar una aplicación web dentro de un UIWebView, o puede usar un UIWebView oculto para ejecutar fragmentos de código Javascript y examinar sus valores de retorno para impulsar su aplicación nativa.

Una ventaja sobre los lenguajes y marcos de terceros es que la licencia de desarrollo de Apple claramente le permite descargar y ejecutar programas javascript (a medida que usa su API oficial para hacerlo).

Acabo de encontrar este complemento de Xcode que ofrece el desarrollo de aplicaciones nativas HTML y Javascript: Nimble Kit . Puede valer la pena un vistazo ...

Aquí está mi respuesta como alguien que compró MonoTouch y lo estoy utilizando como base para todas las aplicaciones de mi iPhone.

No hay atajos. Debe conocer Objective-C y CocoaTouch antes de considerar algo más. No puedes tomar MonoTouch y comenzar a programar el teléfono sin ningún conocimiento de las cosas nativas, simplemente no va a suceder.

MonoTouch es lo suficientemente fácil de extender / modificar según sea necesario, si ya conoce CocoaTouch y ObjC lo suficientemente bien. Entonces, la idea de que los marcos nativos podrían cambiar dejándote en el polvo no es tan relevante.

Según mi experiencia, las aplicaciones MonoTouch son más lentas que sus contrapartes nativas, pero no lo suficiente como para importarlas. Si es importante, siempre puede escribir esa parte de la aplicación con código nativo, y es posible que ObjC no sea lo suficientemente rápido de todos modos y usted quiera usar C pura incluso en una aplicación nativa.

MonoTouch me ha reportado importantes ganancias en productividad, desde el hecho de poder usar un lenguaje menos conciso y hablador hasta el de poder usar bibliotecas como Rhino Mocks y NUnit fuera de la caja.

MonoDevelop es un gran IDE en teoría. También es muy superior a Xcode, en teoría. Es ligero, simple, muy fácil de usar, excelente inteligencia y macros, y hace que administrar un proyecto de iPhone sea mucho más fácil que con xcode. Pero ... es realmente buggy. Esa es su verdadera caída ahora mismo.

Aunque el uso de C # y Java en el Iphone hará que alguien con antecedentes en esos idiomas se sienta más cómodo, todavía me quedo con ObjectiveC.
Al principio parecerá más fácil usar C # o Java, pero puede ser más difícil más adelante. Por ejemplo, ¿qué pasa si Apple decide modificar el marco cocoatouch en el futuro? Tendrá que depender de que monotouch implemente todos esos cambios y, de hecho, se quedará rezagado con respecto a los tipos que están usando ObjectiveC.
Incluso cuando Apple mantenga las cosas como están, todavía será posible que corras con las peculiaridades de la pila Mono y tengas que saltar a través de los aros para hacer las cosas.

Como alguien que tuvo acceso temprano a la exportación de la aplicación nativa de iPhone en Flash CS5, espero poder proporcionar un poco de información al respecto. Para que conste en acta, uno de mis juegos creados con esta tecnología se presentó en la conferencia Adobe MAX 2009, por lo que se sabe públicamente que he trabajado con ella, y no estoy rompiendo la NDA al hablar de mis experiencias, siempre y cuando se adhieren a lo que Adobe ya ha revelado.

Primero, déjame hacer un punto importante. En muchos casos, es posible que Flash no sea la tecnología adecuada para lo que desea construir. Por ejemplo, los juegos 3D y las aplicaciones que deberían usar los controles UIKit nativos están mejor si se desarrollan con Objective-C u otros idiomas que tengan acceso a todas las capacidades y bibliotecas nativas del dispositivo. Para el tipo correcto de experiencia, y el desarrollador debidamente capacitado, Flash puede ser una buena opción.

Como es de esperarse, existe una gran diferencia en las capacidades de la CPU entre el escritorio y el móvil. Afortunadamente, en el proceso de conversión, ActionScript 3 pasa a través de un compilador impulsado por LLVM para ser optimizado de antemano como ensamblaje ARM nativo para el iPhone. Como resultado, el rendimiento del código no sufre demasiado, si es que lo hace. La mayoría de mi código de proyectos existentes que estoy portando a dispositivos móviles permanece sin cambios. Principalmente, tengo que rediseñar el contenido visual para que quepa en el dispositivo y centrarme en los cuellos de botella en el procesador de software de Flash. Incluso en el escritorio, el renderizador es probablemente la pared principal a la que se enfrentan los desarrolladores al impulsar las capacidades de Flash Player.

Afortunadamente, una cosa que los ingenieros de Adobe finalmente están explorando es la aceleración de hardware (en realidad, el video se acelera en el complemento de escritorio, pero solo en ciertas situaciones específicas). Por ejemplo, siempre que un objeto de visualización permanezca estático, se puede marcar para que se almacene en caché como una superficie y se dibuje en la pantalla muy rápido porque se guarda en la memoria gráfica. También se pueden hacer otras optimizaciones interesantes para acelerar el contenido visual, como el uso de mapas de bits para reemplazar los objetos de visualización que tienen filtros (sombras oscuras, brillos y otras cosas por el estilo). Este tipo de cosas también puede mejorar el rendimiento en el escritorio, pero los desarrolladores perezosos no siempre hacen lo mejor cuando se ven "suficientemente buenos" en sus propias máquinas. Algunos de mis colegas consideran inaceptable este tipo de cambio en el flujo de trabajo, pero considero que es tanto una llamada de atención sobre lo perezosos que algunos de nosotros nos hemos convertido como un requisito obvio de pasar a una plataforma más limitada.

Con respecto al compilador de flash podría haber un par de problemas allí:

  • El binario compilado agrupa todos sus recursos en la aplicación compilada, mientras que con XCode el binario compilado agrupa todo como archivos individuales. Esto puede costarle mucho espacio, ya que existen técnicas de compresión que Apple utiliza en algunos recursos (PNG, etc.) para obtener binarios más pequeños del otro lado. Además, las optimizaciones de manejo de recursos disponibles por el sistema operativo no estarán disponibles para los recursos en el binario flash.
  • Se ha discutido sobre la aceptabilidad de los binarios compilados en flash de iPhone. La opinión de Adobe es que son binarios legítimos y no violan las reglas binarias de la aplicación del iPhone, los términos de servicio, etc. Apple no es muy conocida por interpretar al dictador benévolo en la App Store cuando se trata de aplicaciones que los ponen nerviosos. Hasta que haya demostrado ser un método aceptado por Apple, creador de advertencias .

MonoTouch se ve bien, pero es terriblemente lento. He estado jugando con XCode en mi MacBook de última generación por un tiempo (ca 2007) y es rápido y sensible. Descargué MonoTouch la semana pasada, ya que me gustaría convertir una base de código Mono grande existente para que se ejecute en el iPhone, y mientras se instala y funciona bien, usarlo es extremadamente doloroso, ya que todo en el IDE es insensible y no responde.

YMMV si tienes un kit más nuevo y más potente, pero no funciona bien.

Objective-C y Cocoa son mejores por una razón: porque eso es lo que Apple quiere que uses en la plataforma. El proceso de aprobación del iPhone es demasiado negro para comenzar a jugar con marcos y herramientas no respaldados. ¿Quién puede decir que Apple no ideará una manera de ver quién está creando aplicaciones con Mono y simplemente las rechazará?

Sería bastante escéptico de los idiomas que no son ObjC en el iPhone. No necesariamente porque hay que superar un gran obstáculo técnico (puedes compilar casi todo lo que quieras para el iPhone e incluso hacer que se ejecute con algunos ajustes), pero por otras dos razones importantes:

  • Marcos Si bien las cosas que enumeraste tienen enlaces de pantalla táctil y acelerómetro, es probable que te falten elementos como la conectividad Bluetooth y el Kit de juego, los marcos de audio, la compra en la aplicación y similares. Sería bastante difícil reproducir todo lo que Apple ofrece en otro idioma, y ​​si eliges una forma diferente y luego terminas necesitando uno de esos marcos, puedes quedarte atascado.
  • Envío de aplicaciones. Si desea obtener aplicaciones en la App Store, probablemente debería quedarse con ObjC. Apple es notoriamente exigente con lo que permiten, y usar un lenguaje diferente puede sorprender a algún crítico.

También tendrá muchos más problemas con cosas como la firma / certificados de código, sin mencionar la depuración (me pareció extraño que MonoTouch esté publicitando la depuración como una característica, en lugar de algo que se da por sentado en el lenguaje)

En general, me quedaría con ObjC si puedes. En general, es simplemente más fácil para todos los interesados.

Actualización : septiembre de 2010 Los nuevos términos de uso de iOS incluyen el desarrollo de terceros y las plataformas de publicidad.

Si simplemente está mirando un puerto directo, retroceda y pregúntese si realmente desea que su producto sea mediocre. Para cualquier plataforma para la que tenga una aplicación, debe enviar la aplicación más sólida posible para esa plataforma, y ​​las aplicaciones móviles son lo suficientemente pequeñas como para que no sea una dificultad tan grande que tenga bases de código separadas para algunas plataformas.

Una aplicación web también es una muy buena alternativa si desea crear una aplicación para su sitio web. Una gran cantidad de hardware está expuesto a través de algunas de las próximas API de HTML5, y PhoneGap expone algunos más para usted .

Puede evitar el proceso de aprobación de Apple si solo lo aloja en la web, o puede agregarlo a la App Store utilizando UIWebView para cargar su aplicación web. PhoneGap puede ayudarte con esto también .

Hay otra pregunta que pregunta específicamente sobre los marcos de aplicaciones web para iPhone, que enumera muchos marcos alternativos buenos: Biblioteca de IU de JavaScript de la aplicación web de iPhone disponible

Dado que WebKit interpreta JavaScript de forma nativa en el iPhone, Apple también aprueba estas aplicaciones (según la calidad). El navegador en el iPhone es uno de los mejores navegadores en un teléfono móvil en este momento, pero no son los únicos. Con un poco de trabajo extra puede hacer que su aplicación web también funcione en múltiples plataformas. Peter-Paul Koch ha investigado mucho sobre el estado de los navegadores y también realiza blogs regularmente sobre el desarrollo web para dispositivos móviles. Echa un vistazo a sus resultados científicos en navegadores móviles o lee algunos de sus comentarios (divertidos e informativos): http://www.quirksmode.org/mobile/

También me gusta el libro de Jonathan Stark Construyendo aplicaciones para iPhone con HTML, CSS y JavaScript

Incluso puede hacer que la aplicación esté disponible sin conexión con la ayuda de un archivo de manifiesto: referencia de Safari - HTML 5 caché de la aplicación sin conexión . Esto también se describe con más detalle en el libro de Jonathan Stark, de modo que usted modifica automáticamente el manifiesto cuando se modifica un recurso. Como el navegador descarga todos los recursos especificados en el archivo de manifiesto, podría compararse con la actualización de la aplicación en la App Store. Excepto que es instantáneo y no hay proceso de aprobación;)

Unity para iPhone es una buena plataforma para el desarrollo no ObjectiveC.

http://unity3d.com/unity/features/iphone-publishing

Es más que solo juegos, y si necesita .NET u otro soporte de lenguaje de script, esta puede ser una buena manera de hacerlo.

En mi humilde opinión: MonoTouch es más trabajo que una buena pila de IB + ObjectiveC, incluso con parte de la sobrecarga de aprendizaje de ObjectiveC.

Usted estará perdiendo de varias maneras al no elegir Objective-C, ya que es el único entorno compatible con Apple.

Todos los documentos, el código de muestra, la cadena de herramientas, etc. de Apple asumen que estás usando Objective-C. Realmente no podrá utilizar los incidentes de soporte de nivel de código. Cualquier nuevo marco tendrá que ser envuelto para su entorno, que también introduce una nueva fuente de errores.

Para mí, usar algo que no sea Objective-C para el iPhone sería abrir una gran bolsa de dolor.

Yo sugeriría mirar utilizando una solución híbrida.

Debido a la flexibilidad de Objective-c, puede implementar su interfaz en Objective-c y su modelo de datos en casi cualquier otra cosa. Prácticamente puede dibujar la interfaz utilizando Interface Builder, de modo que su codificación real en Objective-c sea mínima. Las partes más difíciles de la mayoría de las aplicaciones serias están en el modelo de datos y es donde es más probable que tenga un código heredado o un código de otros proyectos.

Como lo mencionaron otros, hay muchas bibliotecas que le permiten pegar casi cualquier lenguaje / API importante en Objective-c.

También busqué alternativas a Objective-C porque escribirlo para mí simplemente no es productivo. Actualmente estoy buscando en XMLVM ( http://xmlvm.org/overview/ ) como una forma de escribir Java que luego se convierte en el código fuente de Objective-C. Hay muchas cosas buenas sobre esta solución, pero la más importante en mi opinión es que produce el código fuente de Objective-C, por lo que no se le impide adjuntar su aplicación principal a las API que aún no se han asignado mediante XMLVM. Mi intención es escribir el núcleo de mis aplicaciones en Java, que luego es portátil a IPhone y Android, y luego agregar una funcionalidad específica de la plataforma, ya sea en Objective-C o Android-Java.

También está el marco de Rhodes, que es un intérprete de rubí que le permite escribir aplicaciones de estilo Rails con vistas HTML.