2010-03-06 10 views
18

Acabo de terminar un proyecto relativamente grande para Android, y me dejó un sabor amargo en la boca con el conocimiento de que nunca funcionará en uno de los teléfonos más ubicuos de este lado del solar sistema (el de ese pequeño club afrutado).Objective-C and Android

Por lo tanto, para mi próximo proyecto, quiero escribirlo de forma que la mayoría de los componentes se puedan transportar fácilmente entre las plataformas de iPhone y Android. La forma en que pienso hacer esto es codificando la mayor parte en Objective-C y luego agregando las partes específicas de la plataforma en más Objective-C y Java, respectivamente. En el lado de Android, esto requerirá usar el NDK.

Mi conocimiento de C es bueno, pero mi conocimiento de Objective-C es cercano a cero, y no deseo aprender C++. ¿Cuán cuerdo es el enfoque anterior, y hay uno mejor? ¿Hay alguna forma de que pueda codificar en Java y aún alcanzar el mercado de iPhone no pirateado? ¿Y qué posibilidades hay de que las personas que conozco (usuarios de iPhone) tengan un teléfono Android para el próximo año?

+6

@Tom R: algunas compañías de juegos profesionales que desarrollan aplicaciones para móviles usan una herramienta de portabilidad automática, que traduce Java a Obj-C (y también a Qualcomm BREW). El juego * Uniwar *, por ejemplo, que llegó al top ten en la AppStore de iPhone y que ha sido clasificado como el segundo mejor juego de estrategia de 2009 en el iPhone, fue escrito completamente en Java y traducido automáticamente a Obj-C. En los días en que el precio de la tecnología era de aproximadamente $ 2500/trimestre por desarrollador, y funcionó bien :) – SyntaxT3rr0r

+0

http://stackoverflow.com/questions/2380258/crossplatform-iphone-android-code-sharing –

+0

Hay un nuevo StellaSDK lanzó lo que hará esto: http://stackoverflow.com/a/16677772/308315 – iwasrobbed

Respuesta

9

Mi conjetura, que no tiene experiencia para realizar copias de seguridad, es que probablemente podía escritura Obj-C con NDK de Google de alguna manera, dado que GCC existe para ARM, es de código abierto, tiene un compilador Obj-C y un tiempo de ejecución básico de Obj-C (que si bien probablemente ya no podría ser pirateado para funcionar en una nueva arquitectura), etc.

Eso también podría ser un gran trabajo para un beneficio cuestionable.

Y, por supuesto "Obj-C" (sin las clases NS) significa algo muy diferente de "Cacao", que es lo que la mayoría de la gente realmente quieren decir cuando dicen "Obj-C". Es posible que puedas volver a utilizar algo de GNUstep para algunos, pero ... Honestamente, lo dudo. Suena de nuevo como un montón de trabajo.

Entonces, sí, creo que es posible. También es mucho trabajo y no creo que valga la pena.

Teniendo en cuenta lo que ha dicho, si estuviera intentando hacer esto, me sentiría tentado de escribir la mayor parte de la lógica del núcleo posible en C, y luego ajustarla con dos GUI separadas para cada plataforma.

+4

Esto se está convirtiendo en mi nuevo modelo mantra ... (y en cualquier servicio/biblioteca/código compartido) en C, ver/controlador en el lenguaje/biblioteca de plataforma más apropiado. – rcw3

11

Objective-C sin Cocoa no es tan útil y no te acercará mucho más a tener una base de código de iPhone que funcione. Probablemente sea mejor escribir su núcleo en C con Core Foundation y usar Java u Objective-C para las partes específicas de la plataforma. Apple ha abierto una gran cantidad de Core Foundation como CF-Lite, y tiene un puente libre con Cocoa en OS X (es decir, puede usar muchas clases de CF indistintamente con sus contrapartes de Cocoa).

+0

Gracias por su respuesta. La razón por la que menciono específicamente a Obj-C como el lenguaje en el que me gustaría codificar el núcleo (a diferencia de C/C++) es que se me recomendó como un muy buen lenguaje POO basado en C. ¿Qué tan inutilizable es Obj-C sin Cacao? –

+3

Objective-C me parece un lenguaje perfectamente razonable sin Cocoa.Casi nadie lo usa sin Cocoa, porque hay idiomas más populares en todas las plataformas que no son Mac, pero no veo ninguna razón para no usarlo. Es parte de gcc, por lo que debería estar disponible en prácticamente cualquier plataforma Unix o Linux. –

+0

No dijo que Objective-C era * irracional * sin Cocoa, simplemente no era tan útil. Imagine Java sin java. * Y javax. * Clase, C sin la biblioteca estándar, C# sin .NET, etc. Un lenguaje puede ser genial, pero la biblioteca de códigos correspondiente es lo que realmente agrega valor para la mayoría de las personas. Cocoa reduce drásticamente el trabajo que el desarrollador debe hacer hasta el punto de que sin él, Objective-C se reduce a un lenguaje realmente interesante. Por sí mismo, "interesante" no paga las facturas. Más específicamente, una aplicación de iPhone sin Cacao será rudimentaria y difícil de escribir y mantener. –

1

No estoy seguro acerca de Android, pero con el iPhone, básicamente puede escribir C directamente siempre que lo termine en clases Objective-C.

22

Da un paso atrás y piensa en lo que al final lógicamente podrás compartir.

Los modelos de IU son bastante diferentes, los componentes son diferentes. Al final, lo que podría compartir es clases de objetos de datos, posiblemente algunos algoritmos. No es como si realmente pudieras terminar compartiendo código de red como en los viejos tiempos porque no estás usando directamente sockets, estás usando librerías HTTP.

¿Entonces todo el esfuerzo que está poniendo en esto realmente encontrará una recompensa al final? Me parece que el resultado final será un desastre frágil que es difícil de actualizar, y es mediocre en ambas plataformas en lugar de ser excelente en cualquiera de los dos.

¿Por qué estás escribiendo aplicaciones? Para hacer la vida más fácil para usted o sus usuarios?

+0

¿Es demasiado pedir ambas cosas? :) –

+7

No es pedir demasiado ... ¡pero el universo no es propenso a responder a tales solicitudes con mucha frecuencia! –

+12

Puede sorprenderlo, pero incluso hoy, a pesar de los mejores esfuerzos de algunas personas, no todo el mundo encaja perfectamente en una solicitud HTTP. – asveikau

14

Otros han dicho básicamente esto, pero me gustaría hacerlo más explícito. Su mejor apuesta es probablemente para escribir:

  1. modelos de datos entre plataformas & núcleo lógico, usando:
    • bits de GNUstep (Obj-C), o
    • CF-Lite (C), o
    • lo que desea, siempre y cuando sea multiplataforma: P
  2. iPhone de sólo código de la interfaz, usando Cocoa Touch (Obj-C)
  3. código de interfaz solo para Android, sin embargo lo hacen para Android.

Eso es lo más cerca que puede llegar; cualquier intento de escribir multiplataforma interfaz código sin duda dará lugar a una aplicación mediocre en ambas plataformas. Pero haciendo todo el resto de su código portátil y simplemente envolviendo una interfaz específica del dispositivo alrededor de él se hace todo el tiempo y ha funcionado muy bien para algunos desarrolladores de iPhone.

+0

La mejor respuesta hasta ahora. Esto es muy útil para cosas como juegos simples, donde una gran cantidad del código es lógica del juego, y una cantidad mucho menor representa el procesamiento y la IU. –

+0

No estoy de acuerdo con que CF-Lite sea una buena solución multiplataforma. Básicamente es conveniente para los programadores de Mac y nadie más. Antes sugeriría algo como GLIB, aunque eso es un poco parcial hacia los programadores gtk +. – asveikau

+0

Es poco probable que encuentre algo que sea conveniente usar tanto con el código del iPhone como con el código de Android; Me imagino por qué no elegir algo así como CF-Lite que tiene un puente gratuito con clases NS? De esa forma, al menos UNA de sus interfaces será fácil de escribir. :) – andyvn22

2

Viniendo a esto desde un ángulo diferente ... Sé que dijiste que querías probar y seguir con Java, pero si conoces C# entonces podrías ir con el framework MonoTouch para el iPhone. Mono es esencialmente y la implementación de código abierto de la pila .Net. El equipo de Mono está trabajando para llevar Mono al Android, así que básicamente puedes escribir una biblioteca compartida de C# para tu lógica de negocio y tener diferentes vistas/controladores por plataforma. Todo esto estaría en C#, por supuesto, y es un poco más caro, pero resuelve el problema de escribir todo en diferentes idiomas.

Creo que se llama MonoTouch en el iPhone y MonoDroid en Android.

+0

Vaya con esto y obtenga su tienda bloqueada de la AppStore. Apple no quiere que vayas de esta manera. Al parecer, la pregunta original también lo sabía, y es por eso que pensó en la idea de "está bien, así que usaremos el objetivo C en todas partes", que tampoco es viable. La restricción de Apple requiere que su aplicación se escriba "originalmente" en alguna combinación de C, C++ y Objective C. Dado que las bibliotecas C están permitidas, no veo por qué el asker original se preocuparía por usar ObjectiveC en cualquier lugar que no sea iPhone.Por lo tanto, la pregunta es un poco inusual. –

+1

@Warren P: Sé que este es un comentario antiguo, pero para los lectores futuros, me gustaría señalar que esto ya no es así. Ni Unity ni Mono han tenido problemas con Apple. La restricción de Apple estaba dirigida a Adobe Flash, y eso fue todo. La regla también fue levantada. –

+1

Eso es correcto. Apple se ha relajado mucho desde entonces. Relajaron no solo las preguntas mono (tiempo de ejecución) y de lenguaje (que no sean Objective-C), sino que también permitieron el ingreso de emuladores (como C = 64) y mucho más. Mi comentario fue correcto cuando se escribió, y podría ser correcto nuevamente, en el futuro, si los vientos en Apple cambian nuevamente. –

1

El tiempo de ejecución de Objective-C aún no se ha portado a Android. No debería ser demasiado trabajo, pero aun así, sin un conocimiento práctico del idioma, dudo que lo tenga fácil para portarlo.

Lo que estás tratando de hacer va a ser difícil para una aplicación genérica, pero debería ser posible para juegos, si eliges desarrollar el juego en C simple (que es compatible con Android NDK y iPhone) . Tendría que escribir un código de pegamento para pasar eventos de entrada de los entornos de Obj-C y Java a su código C, pero eso no debería ser un gran problema: Objective-C le permite llamar directamente a su código C y hay muchos proyectos de ejemplo que hacen exactamente esto para Android.

0

Si puede esperar hasta más adelante este año (la cantidad exacta de tiempo se desconoce), Adobe tendrá AIR para Android y un compilador para iPhone. De este modo, puede escribir una aplicación en AIR para Android y usar la mayor parte del mismo código para compilar en el iPhone.

http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/

Incluso si usted no puede esperar ver: http://www.insideria.com/2008/12/actionscript-to-cocoa---protot.html donde explica las similitudes entre ActionScript y cacao.

También consulte: http://labs.adobe.com/technologies/air2/ para la versión AIR que puede usar la pantalla táctil.

para que pronto pueda escribir una vez y desplegar a Android y iPhone con ActionScript 3.

1

XMLVM es un proyecto que es capaz de traducir (algunos) las aplicaciones de Android en el iPhone. Para obtener más información, visite http://xmlvm.org/android/

1

Me doy cuenta de que esto puede ser un poco tarde, pero parece que la industria va en dirección de las aplicaciones web en estos días para lograr la portabilidad de la aplicación. Es decir, incorporar un navegador web en su "aplicación nativa de esqueleto" y escribir javascript, css y html para Android, iOS y otras plataformas principales de teléfonos inteligentes.

Hay herramientas que lo ayudan con esto. Es posible que desee comprobar PhoneGap y Sencha Touch, pero hay muchos más. Tenga en cuenta que este enfoque puede no ser ideal para aplicaciones intensivas en tiempo real/animación.

2

Apportable SDK es un enfoque de Objective-C para escribir una vez e implementar en iOS y Android. Compilará un proyecto IOS Xcode en ejecución en un SDK de Android.

Consulte here para ver ejemplos de aplicaciones que se ejecutan en ambas plataformas en minutos después de la descarga.

1

Aquí hay una charla de la conferencia mobile @ scale de facebook donde dos equipos (Dropbox y orquesta) utilizaron enfoques similares. Dropbox usó C++ para crear libdropbox y Orchestra (buzón) utilizó Objective-c para crear libmailbox.

Una vez más, escribieron sus interfaces en el idioma nativo de la plataforma y usaron sus librerías de plataforma cruzada para la lógica del núcleo y los datos.

Principales ventajas que me quité: Mailbox pasó de ios a Android en 5 semanas porque solo estaba construyendo código de UI. Dropbox puede probar los cambios en la funcionalidad principal que se encuentran en la biblioteca compartida con las implementaciones beta de Android si fuera más fácil realizar despliegues masivos a escala para compilaciones beta.

Cuestiones relacionadas