¿Por qué las personas construirían aplicaciones móviles nativas para Android / iOS usando Java / Objective-C cuando podrían usar Xamarin / C # para todas las plataformas si el costo de la licencia no es un problema?

Principalmente razones religiosas, que generalmente reducen el pensamiento, la capacidad de comprender a las personas: tecnología en este caso y aquí es donde se detiene la discusión. Y Church-Of-Apple es una raza especial (verifique las respuestas anteriores), aunque mi primer cuadro fue IIe y hoy es MBP, nunca estuve infectado.

Puedo recordar mi primera charla sobre MonoDroid, más tarde Mono para Android, ahora Xamarin.Android en 2011-02. La primera pregunta del desarrollador de Java fue “¿Puedes hacer F5?” (Inicie la aplicación con una sola pulsación de tecla). Podría, pero esto explica la mayoría de los desarrolladores “nativos” y su mentalidad.

¿Por qué “nativo”? Porque se necesita la definición de “nativo” (esto suena como una exageración orgánica o bio-algo). Cuando el desarrollador de Android me dice que Xamarin no es nativo, es fácil demostrar que están equivocados con iOS, es un poco más difícil, pero factible con una discusión más larga.

Conversación habitual con el desarrollador “nativo” de Android, en realidad este es casi un estenograma de la última discusión hace 2 semanas, (AFB, IFB, XFB, Android, ios xamarin fanboy respectivamente XFB – yo / yo / yo)

XFB: “Entonces, ¿desarrollas \” de forma nativa \ “con Java y Android SDK?”
AFB: asiente o dice “Sí”
XFB: “Entonces, ¿para qué sirve NDK?”
AFB: “Esto es para el desarrollo [nativo / c-c ++]”
Los inteligentes usan c-c ++, porque entienden que la pregunta los está conduciendo a hielo delgado, por lo que para ellos necesito más Qs para reducir su quard:
XFB: “Entonces, ¿por qué c-c ++? ¿Para qué se usa c / c ++?”
Hay que esperar la palabra “nativo”, luego se baja la guardia y las manos están cansadas.
XFB: “¿Entonces teóricamente puedo escribir una aplicación de Android perfectamente legal de forma nativa en c / c ++? ¿Por qué necesito Java?”

Por lo tanto, es fácil con los desarrolladores de Android demostrar que su definición de nativo carece de algo. Esto se debe simplemente a la tecnología (VM, bytecode, etc.). Con iOS es un poco diferente porque no hay VM, el objetivo-c es un superconjunto de c y, por lo tanto, está más cerca del metal. Pero preguntas como “¿Qué es más objetivo nativo-c o rápido?” baja la guardia también.

Esos fanáticos religiosos no entienden la tecnología y ese lenguaje de programación es solo un parámetro / variable en este tema complejo y hay mucho más.

En el mundo móvil, personalmente defino nativo como el proveedor de conjunto de herramientas / cadena de herramientas / ecosistema que ha elegido hacer una copia de seguridad del desarrollo en su plataforma, por lo que “native” (llamado-native / fanboy-native) es Java en Android y Objective-C / Swift en iOS

Es posible llamar a java desde c / c ++ escribiendo así la interfaz de usuario de Android en c / c ++. Lo mismo es cierto para iOS con Objective-C ++. ¿Pero es factible? En la mayoría de los casos no.

Por otro lado, intente buscar bibliotecas para VoIP (protocolo SIP) u OCR para iOS y Android o incluso mejor intente implementarlas. No hay bibliotecas nativas de fanboy ampliamente utilizadas, solo aquellas escritas en c / c ++ (SIP -PJSIP, OCR – tesseract). Sí, hay bibliotecas de pila SIP escritas en Java o incluso C #, pero no para usos de la vida real.
Por lo tanto, los casos de uso / requisitos deben definir qué herramientas pueden / deben usarse.

Las implementaciones de teléfonos SIP en Android e iOS llaman nativo (c / c ++) del mundo “nativo” (Objective-c / java) y esto es exactamente lo que hace Xamarin, pero “nativo” es c # / f # y nativo son (c / c ++ libSomething.a o libSomething.so, libSomething.a / framework, jar)

Cómo es nativo o no nativo Xamarin verifica este (con enlaces de actualización 2) hecho por el ex Googler Harry Cheung:
2015-03:
https://medium.com/@harrycheung/ …
2015-02:
https://medium.com/@harrycheung/ …

Para la toma de decisiones basada en el intercambio de código, compartamos el código y reduzcamos el costo leyendo las respuestas sobre un caso de uso:
¿Por qué Trello eligió a Xamarin?

Hoy, incluso Apple está copiando ideas y tecnologías bien probadas para habilitar sus paradigmas multilingües y múltiples plataformas de hardware y sistemas operativos. Mono / .net.java utiliza esas tecnologías (lenguaje intermedio, bytecode, cuasi ensambladores, código máquina de alto nivel) durante 15-20 años.

Nadie está hablando de las principales noticias para desarrolladores de Apple: Bitcode

Aplicación Thinning (iOS, watchOS)

App Thinning es lo que Microsoft ya hace con las aplicaciones de Windows Phone y Windows Store, optimizando el código en la tienda y las optimizaciones finales para el dispositivo y el sistema operativo después de la instalación (descarga desde la tienda) en el dispositivo.

Pero para los desarrolladores que no desean tener aplicaciones de “costo reducido”, esto podría ser difícil de aceptar debido a creencias religiosas.

Veamos las ventajas y desventajas de usar Xamarin:

Pros:

1. Código compartido
2. Lenguaje común C #
3. IDE común – Visual Studio
4. Bibliotecas disponibles (paquetes NUGET)

Contras:

1. Aunque la plataforma proporciona soporte desde hace mucho tiempo, todavía hay momentos en que los desarrolladores se quedan atrapados en algunos problemas / errores durante mucho tiempo.
2. Los desarrolladores nativos necesitan aprender un nuevo lenguaje de programación.
3. Muchas bibliotecas útiles aún no tienen plataforma cruzada en Xamarin como BLE. es decir, se requieren conocimientos de SDK específicos de la plataforma (iOS y Android) para tener
4. Hay dos formas de crear aplicaciones en Xamarin a) Xamarin Forms & b) Xamarin Native. En Xamarin Forms es posible compartir código, pero la IU personalizada es difícil de lograr. En Xamarin native: la interfaz de usuario es nativa, lo que significa que el desarrollador nativo debe codificar en C # en este caso. Por lo tanto, ambos enfoques de Xamarin tienen sus propias deficiencias.
5. (Experiencia personal) Soporte mínimo para Visual Studio para Mac. En VS2017 para Mac, los desarrolladores solo pueden abrir una solución a la vez. Además, VS tiene toneladas de problemas, como el código de construcción se atasca, la aplicación no se inicia, se requiere reiniciar VS con frecuencia.
6. Si está desarrollando una aplicación multiplataforma en un sistema que no sea Mac, entonces necesita una conexión remota con una máquina Mac para depurar el código en el simulador de iOS y verificar si hay problemas.

En pocas palabras, si está creando aplicaciones simples y pequeñas, puede optar por Xamarin, pero para aplicaciones complejas de IU / características ricas en funciones, Xamarin no parece ser una idea rentable.

La pregunta no es qué herramientas elegir al desarrollar una aplicación, sino qué enfoque sería el mejor para sus necesidades.

Enfoque de desarrollo de aplicaciones móviles nativas

La aplicación está desarrollada en el lenguaje de plataforma nativo: Java, si es Android, y Objective-C / C ++ si es iOS. Las aplicaciones estándar para teléfonos inteligentes, como despertador, navegador, galería y reproductor de música, se desarrollan con el enfoque nativo de forma predeterminada. El entorno de desarrollo en el desarrollo de aplicaciones nativas es un conjunto especial de herramientas diseñadas para la escritura de código más conveniente, diseño de interfaz, depuración, monitoreo y ensamblaje de la aplicación.

Enfoque de desarrollo móvil multiplataforma

Si el enfoque nativo significa el desarrollo de aplicaciones por separado para iOS y Android, entonces una aplicación diseñada con el enfoque multiplataforma funcionaría en ambas plataformas. Los lenguajes de programación son HTML y CSS, lo mismo que cuando desarrolla un sitio web.

El desarrollo de aplicaciones multiplataforma utiliza herramientas especiales (Unity, PhoneGap, Xamarin), que le permiten crear aplicaciones para varios sistemas operativos móviles. El marco y la lógica de tales aplicaciones se programan primero en una herramienta multiplataforma, luego el código se interpreta en un proyecto XCode o Android Studio.

Ambos enfoques tienen sus propias ventajas y desventajas (aquí están: Desarrollo de aplicaciones móviles nativas versus plataforma cruzada) . Pero a pesar de este hecho, puede elegir el desarrollo nativo si:

• su aplicación requiere acceso gratuito a todos los recursos y servicios del teléfono;
• desea obtener la aplicación más receptiva;
• la aplicación debe tener modo fuera de línea;
• su aplicación debe aprovechar al máximo las partes de hardware del dispositivo.

o desarrollo multiplataforma si:

• está listo para aceptar con baja capacidad de respuesta;
• la aplicación no involucra animación compleja y no trata con cálculos;
• la aplicación necesita acceso constante a Internet para descargar contenido;
• necesita ingresar rápidamente al mercado para probar ideas;
• tienes un sitio web y quieres incluirlo en la aplicación por un precio mínimo.

¡Buena suerte al convertir sus ideas en excelentes resultados!

Oh wow, esta es una pregunta espinosa. He seguido la ruta de Xamarin por los siguientes motivos:
1. Soy un desarrollador de .NET / C #. El tiempo para aprender ObjC, XCode, Java, Eclipse no es insignificante. Necesito ser tan productivo como pueda ser lo más rápido posible. Eso significó C # para mí. Xamarin.iOS se envió por primera vez en 2009 en el momento en que lo necesitaba por primera vez. Xamarin.Android en 2010. El momento fue el adecuado para mí. No tuve que aprender un nuevo idioma.
2. Siempre he tratado de compartir código no relacionado con la IU y el dispositivo. Odio compartir la interfaz de usuario ya que a los usuarios no les gusta eso. xamarin me permite crear una interfaz de usuario nativa con herramientas nativas utilizando los controles nativos. Puedo compartir código pero aún tengo una experiencia nativa con las API nativas.

Elegir Xamarin o cualquier herramienta depende de su situación. No hay una respuesta correcta que funcione para todos.

La pregunta debería ser ¿por qué usarías Xamarin / C # para desarrollar para Android / iOS? La parte de la interfaz de usuario debe seguir el marco de la interfaz de usuario nativa. Si un desarrollador tiene el ancho de banda para aprender una nueva plataforma, ¿por qué no un nuevo idioma?

Probablemente, el único beneficio es que la lógica de negocios (sin interfaz de usuario) se puede factorizar en C #; se puede hacer el mismo argumento si convierte la lógica de negocios central (sin interfaz de usuario) en C ++.

El desarrollo de aplicaciones es un proceso largo y complicado. Sin embargo, en el caso del uso de las herramientas adecuadas, es posible que pueda reducir todos los esfuerzos pagados por la creación de un proyecto. Una de estas herramientas podría ser la biblioteca Node.JS. Sin embargo, si está dispuesto a mejorar la calidad de esa tecnología en particular, existe la oportunidad de hacerlo gracias al uso de varios marcos sobre los que vamos a hablar hoy. https://artjoker.net/blog/differ …

Las aplicaciones nativas son las aplicaciones móviles creadas con Objective-C (para iOS), Java (para Android) o .NET (para Windows), para una plataforma en particular. El código está escrito para una plataforma específica y no funcionará para otras plataformas.

Las aplicaciones nativas, que se adaptan a una plataforma en particular, pueden ofrecer el mejor rendimiento y una experiencia de usuario sorprendente.

El costo de desarrollo está ligeramente en el lado superior, sin embargo, son importantes ya que el foco está demasiado en la experiencia del usuario.

Sin embargo, la clave para seleccionar una tecnología adecuada es describir claramente las expectativas de su organización a partir de la aplicación que está creando. El propósito de la aplicación, el presupuesto, el público objetivo y la disponibilidad del talento tecnológico impulsarán su decisión. En caso de que se materialice una idea, póngase en contacto con Cygnet Infotech.

He estado desarrollando C # para la mayoría de los proyectos no móviles. La razón por la que prefiero usar nativo para IOS y Android es porque termino muchos ajustes usando Xamarin Studio, además, tienes que ir y venir a XCode que fue hace 2 años. He oído que incorporan cosas a Visual Studio, lo cual es bueno, pero cuando leo la documentación dice que debe crear formularios separados en cada plataforma (Xamarin.IOS y Xamarin.Android), a menos que esté dispuesto a pagar EXTRA. No quiero fingir que soy un genio, pero aprender Java y Swift no es malo en contra de lo que he leído antes de comenzar a desarrollar en ambas plataformas. Lo bueno es XCode y Android Studio es gratuito sin ningún paquete adicional de estafa y las actualizaciones de vez en cuando no son apresuradas.

Porque Xamarin, como cualquier otra solución, es una compensación. Hay compensaciones en la deuda técnica de las aplicaciones actuales, las habilidades de los desarrolladores y la voluntad de usar una nueva pila de tecnología.

Puede sentir que Xamarin es la única solución necesaria, pero eso no significa que mi jefe o mi cliente se sientan así.

Aquí hay una gran infografía que puede ilustrar las características del desarrollo de la plataforma nativa y el desarrollo multiplataforma, en particular, Xamarin:

Desarrollo Xamarin: buena opción para su aplicación de negocios.

Porque el nativo produce las mejores experiencias. Y los envoltorios multiplataforma producen algo que es menos que eso.

Hasta donde puedo ver, el beneficio es reducir el costo de escribir la aplicación para múltiples plataformas.

Pero como consumidor, no quiero usar software que se vea como “costo reducido”.

Ser nativo siempre es lo mejor. Por supuesto, el gran problema es: ¿por qué tantos sistemas operativos? Hace que la fragmentación sea un gran obstáculo para obtener excelentes aplicaciones disponibles en todos los dispositivos móviles, sin importar qué sistema operativo. Algunos usuarios de dispositivos Android tienen que esperar años para obtener aplicaciones que sus amigos obtienen en iOS. Aunque, Xamarin y muchas otras soluciones de CP intentan resolver estos problemas, pero a veces es a expensas de problemas de rendimiento por no programar nativamente, además de agregar otros costos como tarifas de licencia, soporte, etc.

Tal elección es realmente difícil. Es necesario considerar todas las oportunidades, fortalezas y debilidades.

En la reescritura de la aplicación creada con Xamarin de una plataforma a otra, hasta el 96% del código original permanece sin cambios. Entre las desventajas están el alto costo de la licencia (pero si la empresa puede soportar comprar la licencia de Xamarin, significa que tiene el éxito suficiente para pagar tales gastos), acceso limitado a bibliotecas de código abierto y baja actividad comunitaria. atractivo para las pequeñas empresas de software como herramientas gratuitas para el desarrollo multiplataforma, pero para las empresas establecidas que emplean el marco es una dirección muy prometedora. Hoy Xamarin es muy popular entre los desarrolladores de aplicaciones, a pesar de su alto costo

Xamarin vs Desarrollo de aplicaciones nativas: ¿Cuál es la elección correcta?

En mi opinión, esos marcos son terribles y no pertenecen a la industria móvil. Cada vez que agrega capas adicionales a un ecosistema ya complejo, las cosas generalmente no mejoran. Sin embargo, puede haber ocasiones en las que las bibliotecas de terceros sean buenas, como las de FB. Recientemente porté una aplicación de Xamarin a Native porque siento que es la forma correcta de hacer las cosas y nuestros clientes estaban 10 veces más felices con las versiones nativas.

No estoy realmente calificado para hablar sobre Xamain / C # en términos de este debate ‘nativo’. Hay algunos buenos puntos hechos en ambos lados allí.

Desde mi perspectiva, la pregunta clave sobre este debate es: ¿puedo encontrar desarrolladores que conozcan la tecnología? Al menos donde estoy, es mucho más fácil encontrar desarrolladores de Objective-C / Swift y Java que Xamarin.

Porque entonces tengo que aprender C #, y no he encontrado ninguna herramienta de desarrollo de C # realmente buena para Mac o Linux.