Aplicación móvil: orientación a iPhone, WP7, Android y Blackberry

Question

¿Existe una forma sensata de desarrollar una aplicación móvil multiplataforma? Queremos que estas sean aplicaciones nativas en cada plataforma, y ​​no necesariamente un tipo de página web.

Actualmente estamos pensando que dividirlo en dos idiomas:

• C# backend (lógica de negocio)
• -> C# estándar de aplicaciones para WP7
• -> aplicación integrada en MonoTouch de iPhone/iPad/etc.
• Java backend (lógica de negocio)
• -> Estándar Android aplicación Java (versión MonoDroid de C# no está listo todavía )
• -> Estándar Blackberry Java aplicación

También podríamos desarrollar inicialmente en C# y use una de las herramientas de conversión para obtener nuestro C# convertido a Java como punto de partida.

¿Hay otro enfoque? Nuestros conjuntos de habilidades incluyen principalmente un fuerte fondo de C# .Net y una menor experiencia de Java.

Realmente no queremos bajar de nivel y usar algo como C/C++ para hacer el trabajo. Suelen ser simples aplicaciones LOB que se comunican con algún servicio web.

Pregunta lateral: ¿cómo los desarrolladores de juegos como los fabricantes de Angry Birds lo hacen?

ACTUALIZACIÓN:

MonoDroid ahora se lanza oficialmente. Parece que solo necesitarías usar Java para BlackBerry. Estamos considerando no desarrollar para BlackBerry en absoluto, porque el desarrollo de las otras 3 plataformas se ha simplificado. Definitivamente hay algún costo involucrado, ya que MonoTouch y MonoDroid son $ 399 y también necesitaría una licencia para Visual Studio (esto no incluye el costo de la tienda de aplicaciones, etc.).

Answer 1

No hay buena simple respuesta que conozco para todas las plataformas móviles. Puede utilizar entornos de desarrollo como Appcelerator Titanium, que compilan de forma cruzada con código nativo en varias plataformas (en este momento, por ejemplo, creo que Titanium admite iOS y Android, con planes para Blackberry). Sin embargo, estos generalmente tienen una API limitada a la que tiene acceso, y todavía necesita diseñar diferentes IU para las diferentes plataformas (en mi trabajo comercial, nunca he utilizado con éxito una plataforma como esta)

También podría diseñe toda la lógica empresarial en un back-end de servicios web y luego simplemente escriba aplicaciones "thin client" para cada plataforma. Esto funciona, pero por supuesto requiere acceso a la red cuando el usuario final quiere usar su aplicación. (Por lo general, estará allí, pero a veces no)

En última instancia, suelo terminar haciendo lo que usted propone: escribir la lógica comercial básica en un par de idiomas diferentes de la manera más genérica posible y luego agruparla en con código personalizado de UI/dispositivo para cada plataforma. No he encontrado una mejor manera de mí ...

(Por cierto, los juegos como Angry Birds están escritos principalmente en OpenGL y luego se cargan en el procesador OpenGL en cada plataforma. Pero podría estar equivocado ...)

Answer 2

No creo que esto sea (fácilmente) posible, si no está utilizando algún HTML5 (jquerymobile etc.) en una WebView en su propia aplicación (parece una aplicación real, pero de todos modos verá de alguna manera que no lo es) en lugar del navegador normal. Todavía puede usar alguna API nativa del dispositivo (acelerómetro, ...).

Existen plataformas (comerciales) como Sybase Unwired Platform que ayudan a generar algún código de cliente. Afaik para Blackberry y Windows Mobile incluso se puede generar alguna IU con los objetos comerciales en el servidor. Pero a mí me parece que esto podría ser demasiado pesado para su caso.

Saludos, Martin

Answer 3

Estas son algunas respuestas grande. Estoy de acuerdo, el desarrollo de la plataforma x es aún muy primitivo. Me gustaría agregar 2 puntos:

1) No es necesario que escriba su servidor en diferentes idiomas. Elija un idioma (según su nivel de comodidad, criterios de rendimiento, etc.) y luego conéctese desde las aplicaciones específicas de la plataforma directamente al servidor. Si su backend es el código del lado del servidor, una forma de hablar con él sería a través de XmlHttpClient. Si se trata de un fragmento de código nativo común en varias aplicaciones y está escrito en C++, puede usar JNI desde Java y el ensamblado de contenedor desde C#.

2) Otro motivo para evitar las herramientas de la plataforma x es que siempre tendrá que esperar a que sean compatibles con las nuevas API publicadas por el proveedor de la plataforma (Apple, Google, MSFT, etc.). Una vez que estas compañías lanzan nuevas API, las herramientas necesitarán ser actualizadas y solo entonces podrán usar las nuevas API.