pasar - nfc iphone 7 como activar

Cómo codificar el uso compartido entre Android e iOS (6)

Además de usar C / C ++ share so lib.

Si desarrolla aplicaciones multiplataforma como un juego, sugiera utilizar un marco basado en mono como Unity3D .

De lo contrario, si desea desarrollar aplicaciones comerciales que requieran una interfaz de usuario nativa y desee compartir el código de lógica de negocios con las plataformas móviles cruzadas, le sugiero que utilice el motor incrustado de Lua como centro de lógica empresarial del cliente.

La interfaz de usuario del cliente sigue siendo nativa y obtiene el mejor rendimiento de la interfaz de usuario . es decir, Java en Android y ObjectC en iOS, etc. La lógica se comparte con los mismos scripts de Lua para todas las plataformas . Entonces, la capa de Lua es similar a los servicios del cliente (en comparación con los servicios del lado del servidor).

- Anderson Mao, 2013-03-28

Me estoy alejando del estricto desarrollo de Android y quiero crear aplicaciones para iPhone. Según tengo entendido, puedo codificar el back-end de las aplicaciones de iOS en C / C ++ y también que puedo usar el NDK para incluir el código C / C ++ en las aplicaciones de Android. Mi pregunta sin embargo es ¿cómo? Busqué en Google bastante y no puedo encontrar respuestas claras y concisas. Al mirar el código de muestra para el NDK, parece que todos los nombres de funciones, etc., son Android (o al menos Java) específicos, por lo que no podría usar este backend de C / C ++ para desarrollar una interfaz de iPhone. Agradecería algunas aclaraciones sobre este tema y, si es posible, ¿algún código para ayudarme? (incluso un simple Hello World que lee una cadena de un archivo C / C ++ y la muestra en una aplicación iOS y Android).

Gracias chicos Chris

Aunque yo no los utilizo porque la mayoría de las cosas que escribo no funcionarán bien, recomendaría usar algo como Appcelerator o Red Foundry para crear aplicaciones básicas que luego se pueden crear de forma nativa en cualquier plataforma. En estos casos, no está escribiendo object-c o java, usa algún tipo de intermediario. Tenga en cuenta que si se muda fuera de la caja que lo han confinado, tendrá que escribir su propio código más cerca del metal.

Escribir una base de código compartido es realmente práctico en esta situación. Hay algunos gastos generales para configurarlo y mantenerlo organizado, pero los principales beneficios son: 1) reducir la cantidad de código compartiendo una funcionalidad común 2) Compartir correcciones de errores en la base de código común. Actualmente estoy al tanto de dos rutas que estoy considerando para un proyecto: usar el nativo c / c ++ (aumentos de velocidad a expensas de perder la recolección de basura y establecer objetivos por procesador) o usar monodroid/monotouch que proporcionan enlaces c # para la funcionalidad de la plataforma de cada sistema operativo (no estoy seguro de cuán maduro es esto).

Si estuviera escribiendo un juego usando 3d definitivamente usaría el enfoque # 1.

Publiqué esta misma respuesta a una pregunta similar, pero creo que es relevante, así que ...

Uso BatteryTech para mis cosas de abstracción de plataforma y mi estructura de proyecto se ve así:

En mi PC :

gamename - contiene solo el código común
gamename-android - contiene principalmente el código específico de Android de BatteryTech y la configuración de Android, los constructores apuntan a un proyecto gamename para código común
gamename-win32 - Solo para construir en Windows, usa el código del proyecto gamename

En mi Mac :

gamename - contiene solo el código común
gamename-ios - La compilación iPhone / iPad, importa código común
gamename-osx - La compilación nativa de OSX. importa código común.

Y utilizo SVN para compartir entre mi PC y Mac. Mis únicos problemas reales son cuando agrego clases a la base de código común en Windows y luego actualizo en el mac para sacarlos de SVN. XCode no tiene una forma de agregarlos automáticamente al proyecto sin secuencias de comandos, por lo que tengo que volver a hacerlas manualmente cada vez, lo cual es un dolor pero no es el fin del mundo.

Todo esto viene con BatteryTech, así que es fácil de entender una vez que lo obtienes.

Si bien el sentimiento es sólido (usted está siguiendo la política de No repetir), es solo pragmático si puede compartir ese código de manera eficiente. En este caso, no es posible tener un enfoque de "escribir una vez" para el desarrollo multiplataforma donde el código para dos plataformas debe escribirse en diferentes idiomas (C / C ++ / Obj-C en iPhone, Java para Android).

Será mejor que escriba dos bases de código diferentes en este caso (en dos idiomas diferentes). Un consejo: no escriba su código Java como si fuera C ++, o su código C ++ como si fuera Java. Trabajé en una empresa hace algunos años que tenía un producto que "portaron" de Java a C ++, y no escribieron el código C ++ como si fuera C ++, y causó todo tipo de problemas, sin mencionar que era difícil leer.

Tenga en cuenta que trabajo casi exclusivamente en aplicaciones de "negocios / utilidad / productividad"; cosas que dependen en gran medida de elementos de IU bastante estándar y esperan integrarse bien con su plataforma. Esta respuesta refleja eso. Ver el comentario de Mitch Lindgren a la respuesta de Shaggy Frog para buenos comentarios para los desarrolladores de juegos, que tienen una situación completamente diferente.

Creo que @Shaggy Frog es incorrecta aquí. Si tienes un código probado y efectivo en C ++, no hay razón para no compartirlo entre Android y iPhone, y he trabajado en proyectos que hacen exactamente eso y puede ser muy exitoso. Sin embargo, existen peligros que deben evitarse.

Lo más crítico es tener cuidado con el "mínimo común denominador". Código algorítmico autónomo, comparte muy bien. Los marcos complejos que gestionan hilos, hablan en la red o interactúan con el sistema operativo son más difíciles de hacer de una manera que no lo obligue a romper los paradigmas de la plataforma y disparar a la pantalla LCD que funciona igual de mal en todas las plataformas . En particular, recomiendo escribir su código de red usando los marcos de la plataforma. Esto a menudo requiere un enfoque "sándwich" donde la capa superior es específica de la plataforma y la capa inferior es específica de la plataforma, y el medio es portátil. Esto es algo muy bueno si se diseña cuidadosamente.

La gestión de hilos y los temporizadores también deben hacerse usando los marcos de la plataforma. En particular, Java usa mucho los hilos, mientras que iOS normalmente depende de su runloop para evitar los hilos. Cuando iOS usa subprocesos, GCD es muy preferido. De nuevo, la solución aquí es aislar los algoritmos verdaderamente portátiles y dejar que el código específico de la plataforma administre cómo se llama.

Si tiene un marco complejo y existente que tiene muchos subprocesos y tiene una gran cantidad de código de red o UI diseminado por él, entonces compartirlo puede ser difícil, pero mi recomendación sería buscar formas de refactorizarlo en lugar de reescribirlo.

Como desarrollador de iOS y Mac que trabaja extensamente con código multiplataforma compartido en Linux, Windows y Android, puedo decir que Android es, con mucho, la más molesta de las plataformas para compartir (Windows solía mantener esta distinción, pero Android sopló lejos). Android ha tenido la mayoría de los casos donde no es aconsejable compartir el código. Pero todavía hay muchas oportunidades para la reutilización del código y deben llevarse a cabo.