¿Por qué la comunidad no logró estandarizar el desarrollo de aplicaciones móviles?

No hay comunidad de aplicaciones móviles. Por lo tanto, no hay un cuerpo de estándares para aplicaciones móviles, al igual que no hay un cuerpo de estándares para aplicaciones de escritorio.

Probablemente preguntarías por qué. La razón es simplemente porque las plataformas están construidas para diferentes objetivos, utilizando diseños drásticamente diferentes. A partir de ahí, se extienden de diferentes maneras, muchas de las cuales se consideran nuevas. Si bien Windows Mobile, Android e iOS tienen características similares a las de un usuario general o un desarrollador principiante, el desarrollador experimentado (y el diseñador de UI / UX) los ve como bestias muy diferentes. No hay forma de estandarizar el desarrollo de aplicaciones sin romper mucho de lo que hace que estas plataformas sean únicas.

La web fue diseñada como una plataforma diseñada para ejecutarse dentro de un espacio restringido y tener poco o ningún apego a su host. Al igual que en algo que se ejecuta en Firefox, Chrome e IE, todos deberían ser relativamente similares. Las diferencias serían leves (idealmente) y prácticamente sin sentido. Por lo tanto, tanto los desarrolladores de navegadores como los desarrolladores web móviles tienen como objetivo utilizar las mismas interfaces porque la intención es que todos estos se alineen.

Android fue diseñado con la intención de ser una plataforma donde se admitan muchos procesadores diferentes, muchos factores de forma diferentes y muchos colaboradores que personalizan cada dispositivo. Esto tiene aspectos positivos, así como negativos. Pero la clave aquí es que los lleva por el camino de hacer que la mayoría de los desarrolladores escriban código para una máquina virtual (dalvik), en Java, para poder crear aplicaciones que sean portátiles entre dispositivos Android a pesar de que el hardware es muy diferente.

iOS fue diseñado con la intención de ser una plataforma donde solo Apple mantuviera el sistema operativo, donde la eficiencia y la seguridad superan a todo lo demás.
Esto también tiene aspectos positivos y negativos. Relevante para la pregunta, esto los lleva por un camino que requiere que los desarrolladores compilen en código nativo (C / Obj-C).

No hay forma de conciliar esto sin afectar los objetivos de la plataforma.
Las máquinas virtuales / intérpretes como Dalvik afectarían la eficiencia, que va en contra de los objetivos de iOS. El código nativo en Android afecta la compatibilidad entre dispositivos, lo que va en contra de los objetivos de Android.

Este es uno de los muchos problemas que impiden la creación de un estándar de desarrollo de aplicaciones móviles como el que usted sugiere. La otra forma de decirlo es: nadie quiere que las plataformas móviles se reduzcan al mínimo común denominador y poca o ninguna innovación.

Si no está convencido, piense en esto: si quisiéramos que la lógica de la aplicación fuera portátil en todas las plataformas, en qué idioma estaría, qué tipos de datos usaría y cómo abordaría la memoria y el hardware.

(Nota al margen: el uso de código nativo existe en Android, pero no se recomienda como su elección principal para el desarrollo de aplicaciones en Android. Tampoco es tan compatible. La última vez que lo comprobé, ni siquiera puede utilizar directamente los widgets de la interfaz de usuario de Android. )

Algunas personas pueden estar en desacuerdo conmigo en esto, pero por lo que he visto, tanto Apple como Google rechazan implícitamente los esfuerzos de estándares, mientras que Microsoft hace el mínimo esfuerzo para cooperar con los esfuerzos de estándares. Como resultado, existe una cultura de no cooperación entre las compañías más grandes en la forma en que trabajan juntas, con organismos de estándares y con desarrolladores externos.

Sí crea una oportunidad de negocio para las compañías que pueden negociar el laberinto de productos y API para escribir una API consistente multiplataforma. 3 que son exitosos incluyen:

• Xamarin
• Apportable
• Unity3D

El mercado de aplicaciones móviles explotó cuando se compara con el crecimiento del navegador web.

Los navegadores web llegaron uno por uno desde la base (ish) durante la década de los noventa, lo que significa que hubo tiempo de retroceder y hablar sobre estándares antes de que la primera gran corporación hiciera uno.

Las tiendas de aplicaciones fueron lanzadas como carretas por grandes compañías que tenían como objetivo tomar la mayor cuota de mercado. Después de que Apple lanzó la tienda de aplicaciones (usando herramientas de desarrollo patentadas), puede esperar que la próxima tienda tenga que pagarles por las aplicaciones de iOS.

Esta es una teoría mía, la otra es que las aplicaciones de terceros están vinculadas al sistema operativo del dispositivo, y los sistemas operativos tienen diferentes características, pero más importante cuando se habla de estandarizar cosas diferentes estilos de interfaz de usuario que los fabricantes de aplicaciones deben seguir.

No creo que esto se estandarice, pero la lógica se trasladará a la nube hasta que se desarrolle la interfaz de usuario mínima y la lógica en el dispositivo.

No es del todo cierto que todas las aplicaciones web funcionen de la misma manera en Safari o Chrome o Firefox. Algunas de las funciones que proporciona Chrome no están disponibles en Firefox. Pero sí, estoy de acuerdo en que hay más estandarización, pero esa no es la razón por la que es posible porque desde el principio las herramientas utilizadas para desarrollar una aplicación web han sido las mismas, a saber, CSS, HTML y JavaScript. Además, el protocolo subyacente básico para todas estas aplicaciones es http, por lo que el estándar se hace necesario. Además, en el caso de la web, no hay estandarización en los servidores web, las personas usan diferentes mecanismos e idiomas para hacer lo mismo. En el caso de las aplicaciones móviles, lo que sucede es que las compañías provienen de diferentes orígenes, es como las primeras computadoras de escritorio donde casi todos usaban diferentes osses.

Primero, Apple, Microsoft y Google no quieren que transfieras fácilmente tus aplicaciones a otras plataformas. Quieren que solo se desarrolle para su plataforma, y ​​no para los demás.

Segundo, tu mundo imaginario era la realidad anterior. Internet Explorer solía usar Visual Basic Script en lugar de JavaScript. Tuve un cliente en el pasado que me obligó a usar Visual Basic Script porque pensaban que Microsoft dejaría de admitir JavaScript. Estaba equivocado, tenía razón, niñera niñera boo-bo!

Si bien IE ahora es en su mayoría compatible con los estándares, Microsoft tuvo que ser arrastrado al mundo de la estandarización pateando y gritando, y todavía apenas han cruzado el umbral.

En tercer lugar, esa estandarización web de la que habla es el comienzo de la estandarización del desarrollo de aplicaciones móviles.

JavaScript se ha vuelto tan rápido y poderoso que la mayoría de las aplicaciones pueden escribirse en JavaScript y ejecutarse tan bien como las aplicaciones Objective-C, C # o Java en sus respectivas plataformas.

Hago desarrollo de gráficos, y WebGL ahora está disponible para iOS8, por lo que incluso las aplicaciones 3D avanzadas podrán escribirse en JavaScript y ejecutarse casi exactamente igual en todos los dispositivos y computadoras de escritorio, tal vez incluso en consolas de juegos.

Aquí hay un ejemplo simple de por qué no.

Hasta esta semana, todos los iPhones tenían el mismo ancho.

El modelo de programación que logró un rendimiento tan fabuloso e interfaces de usuario ingeniosas en el iPhone requirió ciertos enfoques, incluido el uso de muchas imágenes de tamaño fijo. Apple comenzó a cambiar esto hace unos años.

El mercado de hardware de Android está muy extendido con miles de dispositivos diferentes. Tiene que tener un modelo de diseño de GUI diferente.

Una diferencia simple como esta es un ejemplo de cientos de decisiones de diseño diferentes que influyen en el tipo de experiencia que se puede entregar y los costos de hardware relacionados.

Porque “la comunidad” no controla las plataformas móviles, mientras que HTML y CSS siempre han sido estándares abiertos.

Los actores privados han intentado con diversos grados de éxito a lo largo de los años, especialmente en los primeros días, secuestrar estos estándares abiertos mediante la implementación de características propietarias y alentar su adopción, pero en este punto HTML 5 puede manejar casi todo lo que se necesita para la implementación de ricas aplicaciones de internet y no está controlado por una corporación.

Esto lleva a una situación en la que la responsabilidad de la comunidad de código abierto es implementar marcos multiplataforma para dispositivos móviles porque aquellos que poseen esas plataformas aparentemente no ven ningún beneficio en facilitar el desarrollo de aplicaciones multiplataforma. Como Jeff Nelson señala, tales marcos existen: Xamarin, por ejemplo, es una implementación multiplataforma de .Net / C #. Cocos2d-x es un marco de trabajo para el dominio especializado de los juegos 2D. Hasta donde sé, lo que no existe es una implementación multiplataforma del entorno propietario de Apple, algo similar a Xamarin pero que implementa Cocoa para dispositivos que no son iOS.

Nada de esto es algo nuevo. De hecho, lo realmente inusual es la medida en que el navegador como plataforma ha resistido el control de entidades privadas.

No hay “la comunidad”. Hay desarrolladores de iOS, hay desarrolladores de Android, hay personas que crean sitios web receptivos. Estos grupos tienen poca superposición y no tienen un liderazgo común.

Los propietarios de la plataforma no tienen incentivos para estandarizar. Apple, por ejemplo, gana dinero vendiendo computadoras y teléfonos. Ganan mucho dinero haciendo eso ahora. Hay una gran cantidad de aplicaciones en la App Store. Pueden iterar anualmente porque tienen el control completo. ¿Dónde está el problema, desde su perspectiva?

¿Hay un esfuerzo por estandarizar? Existen herramientas multiplataforma, seguro. Entonces, en lugar de encerrarte en una plataforma específica, puedes encerrarte en una plataforma cruzada.

En cuanto a por qué no sucedió vs. W3C: el gato ya está fuera de la bolsa y se movió rápidamente. Mientras tanto, W3C fue fundado por el creador de la web, antes de que la mayoría del mundo supiera qué era la web. ¿Quién es el creador de la industria de los teléfonos inteligentes? Alguien en RIM? Steve Jobs? Quién sabe.

He estado trabajando en muchos frameworks js y también hice algunas aplicaciones móviles.

W3C tiene reglas estandarizadas para la comunicación de datos en navegadores web. Pero si nos fijamos en los motores de renderizado de los navegadores web. Es un mundo completamente diferente. El motor JavaScript más avanzado es google V8. Todos los navegadores usan el mismo protocolo para conectarse al servidor, pero la representación se realiza de una manera totalmente diferente.

Volviendo a las aplicaciones móviles. He trabajado en las tres plataformas. Puede ver fácilmente que todos los SDK utilizan una arquitectura similar. Han cambiado el nombre de los estados del ciclo de vida, pero si los compara, funcionan casi de manera similar. Nadie está detrás de nadie en seguridad móvil. Las tres plataformas permiten a los desarrolladores utilizar la medida más fuerte de seguridad en sus aplicaciones.

En su respuesta secundaria, menciona que “nunca tiene que volver a escribir su sitio web 3 veces para que funcione en los navegadores que Google, Microsoft y Apple crearon”, esto definitivamente NO es cierto. La estandarización ha reducido esta cantidad de reescritura, pero como cualquier desarrollador front-end puede decirle, con frecuencia ofrece sitios web dramáticamente diferentes basados ​​en el agente de usuario (también conocido como id del navegador)

Lo que estás preguntando no es diferente al desarrollo de aplicaciones en un escritorio: ¿por qué no podrían estandarizar?

1. Algunas tecnologías vinieron antes que otras y hay mucho legado en el lugar. Pedirle a una tecnología heredada que ponga en peligro las fuentes de ingresos para que se estandaricen es algo loco / loco / audaz, pero todo esto lleva a …
2. Si todos llegan a un estándar, entonces todos son una mercancía. Entonces, ¿por qué comprarías Apple vs. Google? ¿Una es más bonita que la otra? Bueno, ¿no podrían estandarizar el aspecto? Fabricación estandarizada? La materia a veces funciona y otras no. Para el consumidor y la empresa.
3. Las normas son esencialmente un acuerdo sobre “mejores prácticas”. Si tiene habitaciones llenas de SME súper inteligentes y no están de acuerdo, ¿y ahora qué? La ingeniería es una profesión de constantes compensaciones y juicios. Sin consenso de juicio no puede haber estándares.

Los estándares son una gran plataforma para que las startups rudimentarias se hagan cargo de grandes titulares de Goliat. Pero no te engañes; cuando esas nuevas empresas se conviertan en compañías adultas, a ellos también les gustarán sus formas patentadas.

Los intereses comerciales del titular de una plataforma no están alineados con ser idénticos a los demás.

Del mismo modo, los mejores atletas del mundo no están dispuestos a perjudicarse al nivel del competidor promedio.

Ser el mejor requiere distinción. La distinción requiere rechazar los estándares aceptados y reemplazarlos con algo mejor. Solo adoptas un estándar si no puedes hacerlo mejor.

La disposición a adoptar estándares beneficia a las compañías que están al final de la lista.

Tendría que apostar a que era una mezcla de Ego y falta de cooperación entre las plataformas.

Además, es un poco difícil lograr que las principales compañías de hardware / software acuerden abiertamente los estándares.

Probablemente algunos se preocupen también de que si aceptaran estos estándares pero quisieran ir en una dirección diferente más adelante, no podrían hacerlo debido al hecho de que la gente esperaba que estos estándares estuvieran vigentes.

Los estándares comercializan cosas que están en el corazón de los modelos de negocios de algunas compañías muy grandes. La comunidad no falló; nunca hubo una obra de teatro para la comunidad, la obra siempre fue para finlandesa.

Sé esto porque, en un momento, era mi trabajo evitar que sucedieran cosas como esta, o al menos, asegurarme de que si sucedían, sucedieran en una dirección favorable para mi empleador. Imagínese, si lo desea, mi “número opuesto” en otras 15 grandes compañías, jugando por el mismo resultado para su empleador.

El desarrollo de aplicaciones móviles multiplataforma será la mejor solución, pero para la personalización no es tan fácil integrarse con las plataformas que se están desarrollando. Además, la ingeniería de aplicaciones móviles no está tan restringida para hacer aplicaciones basadas en CSS y HTML para validarlas. Es bastante complicado, aunque prueban las aplicaciones, por lo que la validación se cruza. ¡Supongo!

¡El blog captaría tu interés!
http://blog.contus.com/what-are- …