Sobre Apache Cordova y su uso para el desarrollo multiplataforma
 

¡Hola a todos!

Antes de nada quiero disculparme por la tardanza en cumplir la promesa que hice de este otro hilo:

... He estado más de una semana con un constipado (tal vez una gripe, qué sé yo, si no he visto a mi médico, y, mira que mi médico está de buen ver...) y también trabajando en cierta aplicación que estoy llevando a cabo junto con un cliente. Voy a intentar cumplir en este mismo hilo con mi promesa, aunque, no sé muy bien cómo enfocarlo, puesto que hablo de "un nuevo mensaje con algunos frameworks y herramientas", pero, básicamente, voy a hablar un poco de Apache Cordova, por otro lado, conocido de muchos vosotros.

En estas tres semanas poco más o menos he estado enfermo, pero, como buen autónomo, también he seguido trabajando, precisamente, en la aplicación que digo junto a un cliente: que se desarrolla gracias en buena medida a Apache Cordova. ¿Pero qué es Apache Cordova y en qué puede resultar útil? Pues bien, se trata de desarrollar aplicaciones utilizando utilizando HTML, CSS y Javascript, que, correrán en todo caso en el "WebBrowser" que incorporen las plataformas soportadas: Android, iOS, Windows, etc.

Dije que iba a hablar de "frameworks", pero, en realidad el HTML que utilicemos, así como el estilo (CSS) y el Javascript que usemos, no tiene porqué estar basado en "framework" alguno. Puede estarlo, y, podremos beneficiarnos de esto, pero, no es estrictamente necesario, muchos menos usar algún "framework" en concreto. Hay "frameworks" que pueden sernos muy útiles, por ejemplo, Bootstrap CSS, puesto que usándolo, sin irnos más lejos, nuestra aplicación será "responsive" sin preocuparnos nosotros de ello.

También "Boostrap CSS" proporciona controles como botones, "casillas de formulario", "barras de progreso", "ventanas modales", etc. Todos estos controles, puesto que hablamos de HTML+CSS, lucirán de forma muy similar en todas las plataformas: navegadores web de escritorio y para móviles, "WebBrowsers" de Android, iOS, Windows, etc. Bootstrap es ampliamente utilizado, se desarrolla por Twitter y permite su personalización (colores, tamaños) y el uso de temas para afinar en el estilo que corresponda con nuestras aplicaciones.

He dicho que me iba a centrar en Apache Cordova y no iba a hablar de "frameworks"... pero tocado un poco el CSS (yo diría que "hundido" gracias a Bootstrap CSS) tratar de Javascript no esté demás. ¡Pero aquí tenemos infinidad de posibilidades para agotar nuestras preferencias! Javascript es un lenguaje que se muestra muy potente, que puede hacer infinidad de cosas. Cada vez más de forma "estándar": notificaciones en el escritorio, tomar imágenes con la cámara, realizar peticiones HTTP de todo tipo, etc. Pero me estoy yendo por las ramas y no he hablado de ningún "framework" en particular...

No tengo ninguno favorito, al contrario que me pasa con el CSS y el "framework" Boostrap CSS. Quizá podría decirse que una de las cosas más interesantes que he encontrado en los últimos tiempos es la posibilidad de hacer lo que llaman "Two-Way Data Binding", mal y pronto, que el modelo de nuestra aplicación (un array de objetos con diversa información, por ejemplo) se "muestre" en la interfaz de nuestra aplicación y viceversa, es decir, que un cambio en la interfaz (alguien escribió en un "textarea") se vea reflejado directamente en el modelo de nuestra aplicación.

De modo que lo dicho sería algo así como una característica que yo le pediría a un "framework", tal vez también que fuese capaz de manejar lo que se conoce como "Single Page Application", que, en pocas palabras permite controlar el estado de la aplicación mediante "vistas" que en realidad no corresponden documentos HTML "que se cargan" en el navegador, puesto que de lo que se trata es de que el usuario pueda incluso navegar por dichas vistas o páginas, pero, sin recargar en absoluto el navegador.

Esto último nos viene muy bien para mantener el estado de nuestra aplicación de una forma más sencilla, puesto que al no haber recargas de página en el navegador del usuario, digamos que nuestras variables no se "initializan" a cada paso o "recarga" o "petición", aunque seguramente esto se pueda explicar mejor. Y yo creo que me voy a quedar aquí y no voy a mencionar ningún "framework" para Javascript en concreto. De existen "mini frameworks" o "componentes" que implementan lo dicho "por separado", dejándonos completa libertad para todo lo demás.

No quisiera extenderme mucho más para que este mensaje no resulte pesado, pero, justo ahora llevamos a Apache Cordova. En pocas palabras Apache Cordova trata de llegar adonde Javascript no llega todavía. Por ejemplo, supongamos que queremos utilizar el GPS que incorporan nuestros teléfonos. Javascript aún (ojo, aún...) no puede con ello, de modo que entra en escena Apache Cordova, que, proporcionando un API en Javascript, precisamente, nos permitirá acceder al GPS del dispositivo, obtener información, utilizar "eventos", etc.

Apache Cordova tiene una arquitectura basada en "plugins", de modo que existe un plugin "Camera" para "hacer" fotos y seleccionarlas, un plugin "File" que permite trabajar con archivos, un plugin "FileTransfer" que permite subir archivos a nuestro servidor, plugins como "Compass", "Device", "Device Motion" y "Device Orientation", que nos permiten trabajar con la "brújula", obtener información del dispositivo, sobre su "sensor de movimiento" y su "sensor de orientación".

Apache Cordova publica otros plugins, que, digamos son los "oficiales", pero, gracias a que existe la posibilidad de que otros desarrolladores lleven a cabo este tipo de plugins, lo cierto es que existen un buen número de ellos, algo así como los componentes para Delphi, aunque, no en tanta cantidad. Tal vez no sea lo más común, pero, llegado el caso, si tuviésemos que hacerlo, estos plugins se desarrollan en Java y existe la documentación correspondiente para llevarlos a cabo.

Apache Cordova no es perfecto. ¡Ni nada lo es! Está en constante desarrollo desde hace años, y, se encuentran problemas todos los días, supongo. Por ejemplo, algo tan aparentemente sencillo como un control HTML "input file" no funciona en Android 4.4 debido a cierto "bug" (creo que lo aceptan así) en el "WebBrowser" de esa versión de Android en concreto. Podemos utilizar plugins, por ejemplo, si se trata de imágenes, el plugin "Camera" nos servirá, aunque tampoco es perfecto, y, en algunas versiones de... podríamos seguir...

Concluyendo, lo bueno de Apache Cordova vendría a ser, que, con la misma base de código, es posible desarrollar aplicaciones para plataformas como Android, iOS, Windows y aún otras... El ideal sería que Javascript contase con API estándar que permitiesen lo que ahora no es posible, puesto que además, de este modo, estaríamos hablando de que nuestras aplicaciones podrían funcionar en literalmente cualquier navegador web o "WebBrowser". Lamentablemente esto aún no parece algo cercano.

Seguramente dependa de nuestras necesidades y habilidades decantarse por unas herramientas u otras. No creo que ninguna sea mejor ni peor. Delphi, por ejemplo, es una magnífica herramienta (me está permitiendo ganarme la vida, ¡¿se puede decir más para valorarla?!) que desde hace poco, sin prisa pero sin pausa, permite desarrollar aplicaciones multiplataforma, utilizando no pocos de los conocimientos que se adquiriesen antes utilizando este lenguaje y entorno de desarrollo.

Personalmente, mezclo ambos "mundos"... porque ahora mismo estoy desarrollando una aplicación para Android e iOS (en principio) utilizando HTML, CSS, Javascript y Apache Cordova, pero, utilizando para ello un programa que está desarrollado en Delphi, precisamente. Sin embargo, como dije en el hilo que enlazo arriba, en realidad con el bloc de notas podría bastar. Para terminar, tal vez podría comentar algo acerca de la aplicación en que estoy trabajando, mencionando algunas características.

Esta aplicación en que trabajo, como digo, se está probando en Android e iOS. Hasta hace poco, con una única limitación (notificaciones "push") podía funcionar perfectamente en cualquier navegador, pero, el problema de Android 4.4 y el "input file" nos ha "obligado" a usar el plugin "Camera" de Apache Cordova, de modo que, algunas vistas de la aplicación no funcionarían ya en el navegador: pero sí las otras, y, también diré que hemos preferido mantener una sola base de código para todo.

La aplicación en que trabajo, tanto en su versión de Android como la de iOS, permite recibir notificaciones "push" (algo así como mensajes SMS "modernos", capaces de "levantar" nuestra aplicación aunque esta no estuviese corriendo en ese momento), cuenta con un "mercadillo" de anuncios, donde es posible publicar artículos a la venta, permitiendo la comunicación entre los distintos usuarios de la aplicación, estableciendo "chats" en tiempo real donde los usuarios pueden mostrarse interesados, cerrar una compraventa, etc.

La aplicación tiene otras muchas vistas en donde se muestran novedades, avisos, información personal de cada usuario (nóminas, otros documentos), permite a usuarios "administradores" enviar mensajes a diferentes "canales" de usuarios, en fin, se trata de una aplicación ideada para ser utilizada por los trabajadores de cierta empresa con vistas a mantener cierta comunicación entre la dirección y los trabajadores y entre estos mismos trabajadores. Funciona bastante bien, aunque, para decir la verdad, todavía no se ha "lanzado" públicamente...

Y no sé si se me olvida comentar algo... quizás insistir en el hecho de que todo esto tal vez pueda competir con Delphi de alguna manera, pero, desde luego, si pienso en alguna otra herramienta capaz de generar aplicaciones multiplaforma y de una forma que además me place, estoy pensando en Delphi. HTML, CSS, Javascript, Apache Cordova... son otras posibilidades para según qué casos en que quizás convenga utilizarlas, o quizás no, dependiendo, como se ha dicho, de nuestras necesidades, conocimientos y requerimientos de nuestras aplicaciones.

¿Y qué? ¿Cómo se os queda el cuerpo? Quizás tenía que haber puesto alguna imagen para ilustrar... ¡pero las que se me ocurren son todas NSFW! :D :D :D

^\||/^\||/^\||/ Lo he leído mientras estoy comiendo. Ahora me hago una idea más acertada de lo que es.

¡Hola!

Gracias Casimiro, me alegro hombre. :)

Muy buen artículo. ^\||/^\||/

Pero como está en "La Taberna" no le he hecho mucho caso. :p

Mucho mejor que Cordova, es usar React Native . Si vamos a sufrir el uso de JS entonces al menos usar la opción que da el mejor desempeño:

https://facebook.github.io/react-native/

(O http://www.telerik.com/nativescript tambien)

(Ademas que es posible usar TypeScript, que es JS pero menos horrible)

P.D: React Native es lo mas cercano a desarrollo nativo usando JS que hay.

Leyendo...

Mientras tanto...

A ver compañero ;), que el maese dec se ha echado un rollote informativo y como que eso de desdeñar la info de un plumazo, pues, no digo que no tengas razón, que muchas veces la tienes, pero, ¿no podrías ahondar un poco y así ayudarnos a fijar posturas? :)

LineComment Saludos

La informacion de dec esta bien, el porqué react es en general mejor es debido a que:

- Cordova y similares: Usas el control WebView y cargas todo como si fuera una página web, con un poco de comunicación entre el webview & el host para lo demás.

En donde quizás esto tiene mucho sentido es cuando queremos empaquetar un sitio existente y darle un toque de acceso al móvil, pero la app es definitivamente un sitio web "local".

- React & NativeScript: Solo usas el runtime de JS y los controles y clases son los NATIVOS de la plataforma. React también es una librería de hacer UI de forma declarativa, y se puede compartir una buena parte entre servidor/cliente.

Aquí estamos usando Javascript como un lenguaje de scripting sobre el runtime nativo del host, no usamos HTML, ni CSS, ni el DOM. Si tenemos un "Button" es el del host.

Esto es mejor si queremos que la app desempeñe prácticamente si fuera hecho de forma nativa, acceso casi completo a toda la API del host, etc. Es decir, es como si usaramos Xamarin o Delphi, solo que aqui es con JS.

React ADEMÁS es una excelente librería que resuelve el tema de cómo operar la UI y notificar los cambios (ie: data binding). Piensen que es como los controles RAD de Delphi, pero sobre una MUCHO MEJOR base lógica.

P.D: React es también usado en el servidor y para hacer páginas web, tanto directamente en el cliente, como compilado en el servidor. Se puede usar agregado al HTML/CSS o de forma totalmente independiente.

¡Hola a todos!

He leído vuestros mensajes esta mañana, pero, no he podido responderlos hasta ahora mismo. Pido disculpas. ¡Y vamos allá!

Bueno, tú de lo que leas créete la mitad de la mitad por si acaso. :D :D



Bueno, pero, también para eso estamos aquí, ¡para discutir! :)

Ciertamente, no he probado "React-Native", aunque, recuerdo haber leído al respecto. El "framework" "React" sí que lo he probado, he leído su documentación, y, en efecto, podría ser un candidato para implementar en nuestras aplicaciones el "Two-Way-Data-Binding" mencionado arriba.

En efecto, no sólo existe Apache Cordova, ni tan siquiera "React-Native", también hay otras herramientas similares, por ejemplo, las que tratan (como Apache Cordova) de utilizar el "WebBrowser" las diferentes plataformas añadiéndole algunos "componentes nativos" accesibles vía Javascript. Digamos, no obstante, que Apache Cordova está en desarrollo constante desde hace más de cuatro años... hasta donde yo llego.

No estoy muy seguro de si "React-Native" trabaja de este modo, pero, según entiendo de tu mensaje no se basa en los "WebBrowser", sino en otras cosas. Está bien, Mario, no hay ningún problema, seguramente "React-Native" puede ser también una buena herramienta para según qué aplicaciones.

Sin embargo, creo que hay algún que otro punto que puede al menos debatirse. Ciertamente, "React-Native" te liga a un "framework" Javascript determinado, como es "React". Apache Cordova, en este aspecto, no sólo no te liga a ningún "framework", pero, tu aplicación podría ser la siguiente después de escribirlo en el bloc de notas que mejor te parezca:

Por eso también, precisamente, una aplicación HTML, Javascript y CSS, aunque use partes de Apache Cordova, siempre funcionará en cualquier navegador. Por supuesto, no podrá contar con lo que Apache Cordova le proporciona, pero, podrá seguir contando con todo lo demás, cosa que, si desarrollamos en "puro nativo", no vamos a poder hacer.

A lo mejor me equivoco y una de las plataformas de "React-Native", como también ocurre en Apache Cordova, es, precisamente, la plataforma "Browser", es decir, de manera que algunos de los plugins de Apache Cordova estén disponibles también en los navegadores. Como digo, no sé si esto es posible utilizando "React-Native".

Sin embargo, aunque la plataforma "Browser" no estuviese disponible en Apache Cordova (que lo está), lo cierto es que, poniendo por ejemplo la aplicación en que estoy ahora trabajando, de las más o menos 20 vistas conque cuenta, en sólo tres de ellas es necesario el uso de cierto plugin para Apache Cordova: el plugin Camera.

En realidad, si quisiéramos, podríamos preparar lo necesario para que, en dicha aplicación, se utilizase un posible sustituto al plugin Camera de Apache Cordova: de hecho estaba ya implementado así, utilizando controles HTML "input file". Esto, insisto, al menos ha de considerarse: nuestras aplicaciones correrán también en cualquier navegador en cualquier dispositivo.

A la hora del desarrollo también nos viene muy bien que nuestra aplicación pueda correr en cualquier navegador. En el caso de la aplicación en que trabajo y del programa con el que lo hago, probar una aplicación en Android puede llevarme menos de 20 segundos con mi teléfono conectado al PC, pero, probarla en el navegador me lleva aún menos tiempo: esto mismo, el tiempo de "compilación y prueba" se agradece mucho en Delphi también. "Compilamos" muchas veces al cabo del día...

¿Posibles desventajas del desarrollo "web"? Pues que acaso los controles no luzcan como los nativos. Afortunadamente, con "frameworks" como "Bootstrap CSS" (nótese que es el único que he recomendado aquí), esto no parece un mayor problema: nuestras aplicaciones pueden lucir realmente bonitas y aún espectaculares: dependerá de nosotros mismos, del estilo de nuestra app, de las imágenes utilizadas, etc.

A más a más, de entre los cientos de temas que hay para "Bootstrap CSS", seguramente existirá alguno que "imite" los controles nativos de esta o aquella plataforma. Cambiar de tema, si es que se precisa, es cuestión de enlazar con este o con aquél archivo CSS y tal vez algún otro Javascript. Pero, sinceramente, lo digo de verdad de forma sincera, yo no me preocuparía por la comparación con los controles nativos en este aspecto.

Otra cosa que quiero añadir, para ir terminando, es que, en mi opinión, Mario, has mencionado de una forma un tanto "despectiva" (pero sin malos rollos) a las aplicaciones HTML "que corren en local". No sé si conocerás el cliente de correo web de Google, GMail, que, podría perfectamente correr en local. Personalmente, llevo usando GMail desde hace años... con estupendos resultados, hasta el punto de que no uso ningún otro cliente de correo desde que lo conocí. ¿Cómo te quedas?

Uno de los puntos que mencioné arriba trata del hecho de que las aplicaciones HTML, CSS, Javascript (cada vez más, y, hoy día con cosas como Apache Cordova o similares herramientas, siempre que no rompan la "compatibilidad web", como tal vez sea el caso de "React-Native"), digo, que estas aplicaciones, están lejos de ser "simples" o "meros juguetes". Antes al contrario, se ven aplicaciones, juegos, "sitios web", en definitiva, la mar de útiles y para nada "simples".

No voy a comparar la aplicación en la que trabajo con GMail (aunque cumple su cometido perfectamente), empero, como dije en mi primer mensaje, esta aplicación permite el acceso a documentos privados para cada usuario, publicar artículos en un mercadillo, y, al modo de Wallapop, el contacto entre compradores y vendedores. La aplicación implementa varios tipos de "avisos" en forma de notificaciones "push" (que te llegan a tu dispositivo casi en tiempo real), noticias de la empresa a sus trabajodes, el acceso a programas, cursos, y, en definitiva, un montón de cosas útiles que esperamos satisfagan a sus usuarios.

Para terminar sólo diré que yo no soy ningún máster del universo, quiere decirse, que, con el debido conocimiento y el trabajo que sea menester, las aplicaciones HTML, CSS y Javascript pueden resultar muy, muy potentes. No olvidemos una cosa que tal vez los desarrolladores Delphi pasamos por alto al enfocarnos en el "local" que significa Microsoft Windows y la posibilidad de acceso al sistema de archivos, etc.: en las aplicaciones HTML, Javascript y CSS podemos tener a nuestra disposición uno o más servidores detrás para ofrecernos todo tipo de datos e información con la que trabajar.

¡Y eso es todo de momento! ¡Siento haberme enrrollado tanto! :D

P.D. Estoy seguro de que "React-Native" tiene también no pocas ventajas, pero, como no lo conozco, no las he mencionado. :)

P.D.2. Se me ha olvidado comentar acerca de Javascript vs Dart vs TypeScript vs [Ponga aquí lo que quiera]. En realidad nadie te impide usar estos lenguajes, que, al cabo pueden y aún deben "compilarse" a Javascript. Personalmente, no sé porqué, llámame estúpido, porque, seguramente no es otra cosa, prefiero el Javascript "puro"... pero, como digo, Apache Cordova no te impide usar estos lenguajes si luego los compilas al Javascript que al final se termine usando.

Precisamente, el chiste de Cordova es tener la pagina web corriendo en local, con un toque de acceso a la API nativa (y tener icono de la "app" separada sin ir al navegador).


Pero si estamos hablando de hacer apps *moviles" es claro que no es la opcion ideal. Es lo mismo que decir: Usemos Cordova para hacer una app windows. Quedaria claro que no es lo mismo que usar los controles/api de windows, cierto?


P.D: Aunque no usaria Google Mail como un ejemplo, ya que aunque es funcional, es claramente inferior a otros clientes de correo (osea, en cuanto a UI/funcionalidad de cliente, no almacenamiento/anti-spam), al grado que Google compro Sparrow (el cual fue el mejor cliente para OSX que habia) porque era muy bueno, y asi no tienen una competencia mas ;)

Desde luego. De hecho, mi comentario a Mario fue una invitación a ello :).

Es que no entiendo esta afirmación. ¿Por qué es claro? Actualmente hay muchas aplicaciones que se ejecutan en un navegador y ya no se ve como algo "extraño". Pasándonos a un dispositivo móvil, no me queda nada claro porqué no sería la opción ideal. Y no digo que estés falto de razón. Es sólo que no me parece que sea tan obvio.

LineComment Saludos

Porque los controles nativos son:


1- Mucho mas rapidos
2- Consumen menos memoria, CPU y aun mas importante, menos bateria
3- No son controles web. Web es prácticamente otro OS con sus propias características y hay que hacer gimnasia para intentar hacer que una app web parezca una nativa.



Es muy notable cuando se compara una app nativa a una web que pretende serlo. Incluso en Desktop, las apps "web" mas notables (como Slack y otras hechas con Electron que es como cordova) son in-famosas por su excesivo consumo de recursos, lentitud y fallos en general.


Y a la larga, puede resultar mas costoso desarrollar no-nativo que nativo. Algo que por ejemplo experimento facebook, que termino cambiando de web -> nativo luego de creer que era buena idea; y de hecho, es la razon por la que termino haciendo React Native, como un punto intermedio entre ambos. Porque la REALIDAD del mercado, es que las tecnologias web permiten contratar MAS BARATO y a programadores MENOS EXPERIMENTADOS que nativo.


Ahora, de todas maneras estoy hablando de hacer apps, no de tener una pagina encapsulada, que es un caso de uso diferente. Hay apps donde tener la misma UI tiene sentido, y no hay intencion de ser ni parecer una app nativa, que es donde la falla se hace mas notable.

P.D: Quiero acotar que mi punto de vista es mas en termnos generales, que refutar que a roman o cualquier otro vean que les sirve su elección; que al final es mas significativa que la opinion de un tercero que no conoce tus circunstacias especificas.

Básicamente solo quera agregar que React Native es otra opción muy buena al arsenal, pero como cosa rara termine yendome por las ramas!

¡Hola a todos!

Discrepo contigo Mario. Sé por dónde vas, y, en efecto, nadie va a negar que el desarrollo nativo tiene sus ventajas, por ejemplo, acaso un mayor desempeño en cuanto a la rapidez y agilidad de las aplicaciones, pero, ¡qué duda cabe de que el desarrollo nativo también tiene sus desventajas!

Una aplicación "web" con un icono en el escritorio del dispositivo vendría a ser lo que Google inventó con las "Progressive Web Applications", empero, una aplicación que se apoya en Apache Cordova puede ir bastante más allá que eso, recordemos, por ejemplo, que podríamos crear plugins (escritos en Java) para cuanto fuese menester.

Por otro lado, quiero hacer notar que la idea de estos hilos míos va más bien por pensar en HTML, Javascript y CSS, lo que ya hoy día es posible hacer con Javascript, y, más particularmente, lo que pueda llegar a hacerse en el futuro con Javascript. Apache Cordova, como dices, es un añadido, pero, yo tengo mucha confianza en las aplicaciones HTML.

Ahora bien, ¡no vayamos a intentar atornillar con un martillo! Si mañana me dices, necesito hacer un programa para Windows, problamente pensaría en Delphi. Seguramente no pensaría en otra cosa que en Delphi. Pero si me hablas de Android, ya no lo tengo tan claro, precisamente, porque, con HTML, Javascript y CSS, ojo a esto, POR EL MISMO PRECIO y con la misma base de código, podemos atacar varias plataformas más.

¿Quiero esto decir que ya sólo pensaré en términos de HTML, Javascript y CSS? No, por supuesto que no. Pero sí que quiero transmitir la idea de que estos lenguajes son cada vez más potentes, y, que, ya no hablamos de una, dos o tres plataformas, no... hablamos de poder llegar a esas dos o tres plataformas en que todos pensamos (sí, también Windows y su Windows Store) y además CUALQUIER navegador disponible en cualquier dispositivo.

Para mí eso tiene ventajas indudables. ¿Superan las ventajas a los incovenientes? ¿Sería mejor usar algo nativo? Dependerá de cada caso, ¡digo yo!

Estoy contigo, Román, de forma completamente honesta además. Tal vez hace años la web se limitaba a mostrar información, pero, eso cada día es menos así. Cada día hay más "aplicaciones web", algunas lo son inlcluso sin saberlo, y, claro está que habrá sitios web que no necesiten más. Pues muy bien. Pero estoy contigo, en el mismo sentido: yo no veo nada claro que lo "no nativo" (estaría mejor decir lo "universal"... o "multiplataforma"...) tenga nada de malo, todo lo contrario.

Posiblemente un cliente de correo escrito en Delphi o cualquier otro entorno nativo para Windows sea más rápido que GMail... si es que guarda los mensajes en una base de datos local, pues, de lo contrario, habrá de contactar igualmente con un servidor. Pero lo que tengo claro es que no tiene porqué ser ni más bonito, ni más usable, ni mejor. Yo no uso GMail no porque reniege de lo nativo, vaya, sino porque con GMail tengo más que suficiente... e incluso mucho más de lo que utilizo.

¡Hola a todos!

¡Contestaré sólo a estos puntos porque tengo caliente la cena! Habrá que definir "mucho más rápido" Mario. Hace años, tal vez, con ordenadores menos potentes... pero hoy día no es raro encontrar teléfonos con más de 2GB de RAM... y que además tienen sus "WebBrowsers" muy optimizados, ofreciendo respuestas verdaderamente sorprendentes, en algunos casos, equiparables a "lo nativo", porque, en efecto, si lo nativo tiene que comunicar con un servidor para traer datos... ya no estará sólo ante el peligro y tardará en mostrar los datos contando con lo que tarde el servidor en enviarlos.

¿Consumen las aplicaciones "no nativas" menos recursos? Es posible, pero, volvemos a lo mismo, vamos a poner esto en perspectiva. Cada vez los dispositivos son más potentes, más optimizados, en fin, esto es (más o menos) como cuando pretendíamos que nuestros programas en Delphi ocuparan lo menos posible, ¿os acordáis? ¿Quién comprime hoy sus programas con UPX para ahorra espacio? ¿A quién le preocupa si su programa ocupa 1 ó 20 MB hoy en día? No es lo normal, puesto que hoy día 20 MB son... menos que 1 MB antaño. ¡Y esto no se va a quedar parado aquí!

Por otro lado, creo que hay cierta insistencia en que las aplicaciones luzcan "nativas". Volviendo al ejemplo de GMail, ¿se parece GMail a una aplicación de Windows? ¿De Mac OS? ¿Tiene GMail alguna necesidad, para ser atractivo y útil, de parecerse a ninguna otra cosa? Lo que tiene que tener GMail, y por supuesto tiene, son "tablas" para mostrar información, "casillas" para introducir datos, "botones" para pulsarlos (claro está) y así sucesivamente. De hecho, GMail tiene una ventaja, desde mi punto de vista: será el mismo en todas y cada una de las plataformas, no se parecerá a nada, y siempre usarás el mismo GMail estés donde estés.

A mí esto no me parece mal...

¡Hola a todos!

¡Vamos a seguir con tu última respuesta Mario!

Yo creo que, para empezar, una aplicación no tiene que pretender nada más que resultar de utilidad. No se trata de "querer ser nativa", sino de ofrecer algo útil. A veces, en efecto, por varias razones que podrán ser más o menos discutidas, el desarrollo nativo acaso sea la mejor opción. Pero, sin despreciar otras posibilidades tampoco, sin cerrarnos en banda, vamos. :)


Una persona que domine HTML, Javascript y CSS (y algún otro lenguaje y base de datos en el servidor) puede ponerse a construir una aplicación web. Dicha aplicación podría correr en Android, iOS, Windows y en otras plataformas soportadas por Apache Cordova (si seguimos hablando del mismo), por no mencionar la plataforma principal: cualquier navegador en cualquier dispositivo.

Yo creo que el perfil de la persona que refiero arriba está mucho más cercano a la realidad de una posible persona que dominase el desarrollo nativo en Android, iOS, Windows, otras posibles plataformas y además en cualquier navegador en cualquier dispositivo. ¿No te parece a ti que de lo que se trata de buscar una "plataforma universal", mejor que diferentes personas para diferentes plataformas?

¿Qué desarrollo será más económico? ¿Aquél que necesite una persona o el que necesite dos, tres o cuatro? ¿Por qué tiene que ser necesariamente más barato un desarrollador HTML, Javascript y CSS? ¡Eso serán los malos, digo yo! Que un programador sea malo o bueno no creo yo que tenga que ver en absoluto con el lenguaje o entornos que esté utilizando.


Yo también hablo de verdaderas aplicaciones y no de meros documentos HTML. Y has dado en el clavo: personamente, en lugar de adaptar una aplicación para cada plataforma... prefiero que la misma aplicación (si es posible) se ejecute y luzca más o menos igual (y eso hoy día es posible gracias a que las plataformas soportan cada vez mejor HTML, CSS, etc.) en cualquier lugar.


¡Si es estupendo! En efecto, aquí nadie vamos a poder sentar cátedra de una vez por todas. De hecho estaríamos equivocados, porque, ¡cada aplicación es un mundo! Vale... quizás no tanto, pero, la idea es que aquí lo importante es la aplicación, qué se necesita, y, en función de eso, utilizar la herramienta que nos parezca más adecuada en función de nuestros conocimientos y experiencia.

¡Claro que "React-Native" puede estar bien! A veces será preferible a Apache Cordova... o viceversa... todo dependerá de lo que vayamos a hacer.

Buenas. Muy buen hilo. Me interesa mucho este debate, aunque no tengo argumentos para comentar, al menos de momento, pero estaré pendiente de lo que vayais contando. ^\||/:)

¡Hola a todos!

¡Gracias Paco! :)

Que tal,
Tengo que decirles que herramientas como esta (Apache Cordova) y en mi caso usando ionic y angular, para gente que viene del desarrollo "tradicional" de escritorio, son un mundo completamente nuevo, fascinante y con grandes espectativas.
Recuerdo aquellos días donde programar la apertura y toma de fotos con una camara, eran dias de investigacion y desarrollo, ahora simplemente con incluir un plugin y unas cuantas lineas de codigo, ya estás accediendo a casi cualquier dispositivo.
Esto sin duda tiene sus bemoles, pero no deja de sorprenderme lo que hoy día está disponible en la web, tanto para desarrollo en moviles como para sitios reactivos y responsivos.
Saludos.