.net - usado - ranking de lenguajes de programacion
¿Dirigido/Desarrollado para múltiples plataformas móviles con un lenguaje de programación(C#)? ¿Coste-beneficio? (8)
Hoy es posible usar la programación de C # para múltiples plataformas móviles tales como:
(Siéntase libre de editar si me perdí algo) Por supuesto, todavía es un esfuerzo de programación para la interfaz de usuario, pero se pueden compartir las principales bibliotecas de la aplicación.
Todos podemos agradecer a un equipo reunido alrededor del proyecto Mono y el superhéroe Miguel de Icaza cuyo esfuerzo no tiene precio.
Lo que me molesta es, ¿cuáles son los beneficios de estas opciones? ¿Es el costo de mantener una aplicación en múltiples plataformas móviles menos impedimento que tener que codificar cada biblioteca por separado para un mejor rendimiento? Curva de aprendizaje de cada idioma? Ser Jack of All intercambios vs .NET Ninja
O sabiendo que los binarios de la aplicación programada en el entorno nativo son de menor tamaño, tal vez incluso mejor optimizados y no se olvide de que debe esperar el soporte de nuevas actualizaciones de la plataforma.
ACTUALIZACIÓN : Obviamente, hay una cosa más a considerar y eso es apoyo. Desde que Novell es comprado por Attachmate Group, todo el equipo de Mono es despedido. Sin embargo, el miembro principal del equipo dirigido por Miguel De Icaza fundó la nueva compañía Xamarin que reinventará las herramientas de desarrollo de Mono Mobile desde cero.
Dado que la respuesta aceptada se había escrito en 2011, surgieron un par de marcos diferentes, que traen patrones MVC y MVVM a Mono para Android y MonoTouch, lo que ayuda bastante cuando se desarrollan aplicaciones para estos objetivos.
Para MVC MonoCross el proyecto llamado MonoCross
Para MVVM echa un vistazo a MvvmCross de Stuart Lodge
Este último contiene una gran cantidad de código para abrir imágenes en las tres plataformas, componer correos electrónicos, abrir webbrowsers, reproducir sonidos y mucho más. También maneja la navegación entre ViewModels.
En mi opinión, el gran profesional de usar un único entorno (es decir, C # / .NET) es la portabilidad de código. Y cosas geniales como LINQ que, una vez que te acostumbras, no puedes vivir sin ellas. Sin embargo, los pocos sistemas operativos móviles (iOS, Android, WP7) son bastante diferentes con respecto a la interfaz de usuario.
Y, si no me equivoco con su aplicación, tiene una buena cantidad de interacciones de UI si se va a ejecutar en un dispositivo móvil. La mayoría de las aplicaciones móviles tienen un 80% de código de UI.
Por lo tanto, terminará escribiendo un conjunto separado de código de UI para cada plataforma de todos modos; por ejemplo, escribirá en Silverlight WP7 (y todas las bondades de WPF), escribirá un conjunto de códigos completamente diferente. para iOS en Cocoa (IB, Vistas, controladores y demás), escribirás un conjunto de códigos completamente diferente para Android.
Mi experiencia siempre ha sido que se requiere mucha experiencia para escribir un buen código de UI en cualquier plataforma, por ejemplo, aprender WPF / SL ya es la pesadilla, arrojar Cocoa Touch y todo el desastre de Android. Por supuesto, puede escribir tres conjuntos de UI que se vean y se sientan razonablemente similares, pero es probable que intente reutilizar el código y tenga estructuras de datos comunes para que su UI resulte inferior a la de las aplicaciones dedicadas: - y en este mundo feroz de las aplicaciones móviles de hoy en día, una experiencia de UI no súper (por no mencionar el peor) significa la muerte de su aplicación.
Además, los tres entornos móviles tienen diferentes paradigmas de conectividad, así como paradigmas multimedia. Terminas escribiendo tres versiones y aprendiendo tres entornos, aunque escribiendo en un idioma con el que estás familiarizado.
Lo máximo que volverá a utilizar son los módulos de fondo. Motores de decisión, rutinas de búsqueda, gestión de datos, etc. E incluso estos serán problemáticos porque obligarán a tener compromisos en sus estructuras de datos solo para permitir una fácil integración con tres conjuntos diferentes de códigos UI trabajando en tres paradigmas de IU diferentes . Por ejemplo, ¿usa DependencyObjects para usarlo para vincularse a las vistas de Silverlight en un modelo MVVM? Si lo hace, no funcionará con el modelo MVC de Cocoa, y debe codificar esas vinculaciones por separado.
Y dado que no todos los entornos móviles le permiten usar el conjunto completo de funcionalidades, por ejemplo, MonoTouch para iOS no incluye construcciones genéricas que no puedan determinarse en tiempo de compilación. Básicamente, está utilizando un subconjunto muy pequeño de .NET (y debe recordar constantemente qué funcionalidad se puede usar en) para que pueda ejecutarlos en tres plataformas diferentes sin cambios significativos.
Ahora la imagen tiene todas estas limitaciones cuando escribe para la plataforma WP7, que es compatible con todo el conjunto de características de .NET. No sé ustedes, pero me volveré loco. Y su aplicación WP7 nunca estará ni cerca de ser competitiva con otras aplicaciones.
En mi opinión, el dolor y los compromisos no valen la pena. Terminarás con tres aplicaciones mediocres, que a la gente de ninguna de las plataformas les va a gustar.
A menos que toda la bondad se encuentre en la lógica de back-end de su aplicación, y es tan buena que las personas van a ignorar los problemas de UI solo para llegar a las funcionalidades de back-end de su aplicación. En mi experiencia, esto casi nunca sucede.
Hay ciertos inconvenientes en las bibliotecas Monotouch / Droid. Hay un pequeño retroceso de velocidad (alrededor del 5%, tan insignificante en la mayoría de los casos).
En mi experiencia, el tamaño no difiere mucho. Gran parte del tamaño está en los recursos ( recursos de datos, imágenes empaquetadas y similares, no en el uso del procesador), y la mayoría de las aplicaciones no llevan consigo tantos recursos (debido a los tiempos de carga y la disponibilidad de muchos controles predeterminados en las plataformas móviles). .
No obstante, no creo que debas usar los marcos en los juegos. No tengo mucha experiencia en el desarrollo de juegos para dispositivos móviles, pero los marcos bastante diferentes que estás usando en el desarrollo de juegos (XNA, NDK de Android) y la necesidad de recursos del sistema (uso del procesador, memoria, etc.) los hacen bastante inútiles. En mi humilde opinión.
La mayor ventaja para mí es la capacidad de reutilizar la lógica comercial y el código de comunicaciones entre plataformas móviles. Sí, tengo que escribir la UI una y otra vez, y lleva tiempo entender eso, pero al menos mi plataforma base es reutilizable.
Según mi experiencia al pasar a una plataforma nueva, me lleva mucho más tiempo aprender el marco de la interfaz de usuario que aprender un nuevo idioma.
La solución multiplataforma solo funciona si su aplicación es simple y directa. Si necesita funciones complejas como el almacén de datos local con gráficos de objetos complejos, hágase nativo o espere pasar meses para solucionar problemas
Otra forma de ver esto es que puede portar una aplicación .NET / C # existente a una variedad de clientes móviles (tanto nativos como no nativos) relativamente fácil usando el servidor de integración WebORB . En el lado del cliente, tendría que codificar en el idioma nativo o podría crear una aplicación Adobe AIR que sea bastante portátil en diferentes sistemas operativos móviles, como iOS, Android y BlackBerry PlayBook.
Ventajas:
- Codifique todo en el mismo idioma y (principalmente) utilizable en cada plataforma
- Tiempo de desarrollo reducido
- Más barato
Desventajas:
- La inclusión de las bibliotecas necesarias aumenta el tamaño mínimo de la aplicación de manera significativa: si su aplicación va a ser grande, la diferencia no es tan significativa.
- Sobrecarga de rendimiento
Si tiene el dinero y las personas, siempre es mejor tener a algunas personas centradas en el iPhone y Objective-C, algunas en Android y Java, etc. De esa forma, sus programadores tendrán un conocimiento profundo de la plataforma a la que se dirigen y podrán asegúrese de que su aplicación aproveche al máximo las características de la plataforma; una aplicación no debe ser exactamente la misma (excepto quizás los juegos) en todas las plataformas; debe jugar con sus fortalezas y debilidades: una aplicación de iPhone debe funcionar y funcionar como un iPhone aplicación, etc.
Dicho esto, si no tiene la gente o el dinero, usar un solo idioma junto con varios marcos es ciertamente más barato y más rápido, y puede brindarle mejores resultados que el resultado del intento tenso de desarrollar para cada plataforma individualmente.
una gran ventaja es sin duda la reutilización de bibliotecas de códigos / clases en todas las plataformas. Con esto en mente, puede portar / desarrollar aplicaciones aún más rápido, lo que a su vez reduce los costos.
Además, debido a la reutilización del código, reducirá los gastos de mantenimiento.