Llegamos a ustedes gracias a:



Columnas de opinión

¿Cómo llevar a cabo correctamente el desarrollo móvil?

Por: Martin Heller, editor y colaborador de InfoWorld

[31/10/2017] Hace mucho tiempo, en una galaxia muy, muy lejana, había una compañía que finalmente estaba haciendo negocios en la web. Sus desarrolladores estaban agotados luego de haber pasado años aprendiendo HTML, CSS, JavaScript y jQuery, y lidiando con todos los diferentes navegadores que los socios y clientes de la empresa querían utilizar en lugar del estándar de oro de la compañía, Internet Explorer 6.

Podría pensar que todos estaban agradecidos, ya que no había la necesidad de instalar aplicación de Windows NT de la compañía. Pero, ¡no! No la dirección, los empleados, los socios, ni siquiera los clientes.

¿Qué era lo que realmente esperaba esa gente absurda? ¡Querían hacer negocios desde su teléfono!

Ya era hora de traer de vuelta a los consultores que habían establecido las estrategias de desarrollo anteriores. ¿Sabe lo que los consultores dijeron? Despidan a todos los desarrolladores web y contraten a un montón chicos de 20 y tantos innovadores para crear aplicaciones nativas para el iPhone.

El director financiero pensó que era una gran idea: Los desarrolladores web tenían la edad suficiente para ser caros. Recursos Humanos no estaba tan seguro acerca de los despidos: ¿Qué pasa con el reciclaje laboral? El CIO había oído que a los millennials no les gustan las empresas estructuradas y no quieren trabajar duro, pero quieren lograr cosas de relevancia social. ¿Eso no sería difícil de manejar?

En un dilema, mi viejo amigo, el CTO, me llamó e invitó a comer sushi. Durante la sopa de miso, me actualizó sobre la situación y su posición, y me preguntó qué pensaba que debía hacer.

Por suerte ya había pasado mi sorbo de té y dejado mi tasa, o hubiese rociado el mantel de color verde.

Esto es lo que le dije.

No todas las aplicaciones móviles son iguales

En primer lugar, el iPhone no es el único tipo de teléfono. En segundo lugar, un teléfono no es el único tipo de dispositivo móvil que sus empleados, socios y clientes quieren utilizar. Y, en tercer lugar, las aplicaciones nativas no son el único tipo de aplicación móvil. Así que hablemos sobre el panorama completo de aplicaciones móviles.

Para hacerlo simple, vamos a empezar con lo que se ejecuta en el dispositivo. Luego, lo enlazaré con lo que debe suceder en sus servidores para soportar el dispositivo.

En un iPhone o iPad -sí, son diferentes, pero puede crear aplicaciones que pueden ejecutarse en ambos- una aplicación nativa generalmente está escrita en Objective-C, Swift, y/o C++. Se desarrolla en una Mac -sí, ya sé que está estandarizado en Windows, pero ya llegaré a eso-, se publica en una app store, y finalmente es descargada en un iPhone o iPad.

Note que dije "una" app store. En su mayoría, las aplicaciones de consumo se encuentran en la (A mayúscula) App Store de Apple; a menudo las aplicaciones empresariales están en (A minúscula) app stores o repositorios privados. A veces, su compañía de gestión móvil es responsable de la app store -pero me estoy adelantando.

En un teléfono o tableta Android, generalmente una aplicación nativa es escrita en Java y/o C++. La gente tiende a utilizar C++ para las bibliotecas independientes del sistema cuando están creando aplicaciones o juegos para iOS y Android. Las tiendas de aplicaciones son prácticamente lo mismo en Android y Apple, aunque es más fácil y rápido conseguir una aplicación en la tienda de Google Play.

Note que dije "generalmente" al hablar de lenguajes. Las tiendas acérrimas de Windows escriben aplicaciones portátiles parecidas a las nativas en C# con Visual Studio y Xamarin. Pero no regrese a su oficina todavía, pues hay más opciones para su tienda. Por cierto, todavía necesita Macs para construir y depurar aplicaciones para iOS, aunque puede diseñar y codificarlas -y ahora probarlas- en Windows.

Aunque las aplicaciones nativas se ejecutan más rápido, usan de la mejor manera el hardware del dispositivo, y se comportan lo más suave posible, también son las que más se demoran y más cuestan desarrollar, y las más difíciles de actualizar. El costo típico de una aplicación de iOS o Android de tamaño mediano, construida con el kit de desarrollo de software nativo, es de 100 mil dólares, y la adición de otra plataforma significa volver a implementar todo el código, aunque la mayoría del diseño puede ser preservado. Esas bibliotecas de C++ también ayudan a evitar la reimplementación del código para el segundo sistema.

Las aplicaciones web móviles son mucho más baratas de desarrollar -alrededor de 20 a 25% del costo de una aplicación nativa- y serían una mejor opción para las habilidades que sus desarrolladores web tienen, pero hay algunas trampas. Se ejecutan más lentamente, el uso del hardware del dispositivo es reducido al máximo, y la mayoría son propensas a un comportamiento volátil e irregular. En el lado positivo, son triviales para actualizar en el campo -simplemente revise su sitio web.

Hay otras deficiencias en las aplicaciones web móviles que se deben considerar. Por un lado, pueden no conservar el estado luego de un cambio de contexto o el reinicio del dispositivo, a menos que guarde y cargue explícitamente el estado en el dispositivo. El resultado de un comportamiento volátil, como el desplazamiento desigual, se puede arreglan con widgets JavaScript cuidadosamente escritos, y con el uso de marcos de alto rendimiento de JavaScript. Por último, las aplicaciones web no pueden utilizar la mayoría de los sensores de lujo del dispositivo móvil, salvo el GPS.

Las aplicaciones móviles híbridas pueden curar ese problema. La construcción de una envoltura nativa para cada dispositivo compatible mediante PhoneGap o su fundación de código abierto, Apache Cordova, hará que obtenga acceso a las capacidades del dispositivo, y permite que la aplicación retenga el estado en caso de un cambio de contexto, o el reinicio del dispositivo sin necesidad de programación especial. Hacer una aplicación PhoneGap, una vez más, lo fuerza a entrar a las tiendas de aplicaciones, pero puede pasar por alto una gran cantidad de actividad de actualización descargando la mayor parte del contenido de su sitio, y presentándolo en lo que esencialmente sería una ventana del navegador alojada dentro de la cáscara nativa.

Existen un montón de plataformas de desarrollo de aplicaciones móviles que puede utilizar. Por ejemplo, es posible que desee considerar los 11 proveedores "significativos", citados por Forrester en la "ola" de este año: Alfa Software, Appian, Capriza, i-exceed, K2, Kony, Magic Software, Mendix, Oracle, OutSystems, y Salesforce. O podría gustarle una plataforma prometedora de desarrollo móvil basado en la nube, como EachScape, QuickBase y ViziApps.

Algunos de estos generan aplicaciones nativas; algunos, aplicaciones híbridas, aplicaciones web; y otros le dan la opción de todo lo anterior. Algunos implican menos trabajo para los desarrolladores que otros, y algunos son más fáciles de aprender que otros. Algunos funcionan en la nube, y otros en el escritorio. Algunos son gratuitos, al menos hasta desplegarse, y otros harán que su departamento de compras negocie una licencia anual de seis cifras el primer día.

Las aplicaciones móviles requieren backends móviles

Todavía no hemos llegado a hablar sobre los backends. Ha centralizado las bases de datos detrás de todos sus sistemas de registro, ¿verdad? Sus aplicaciones móviles deberían utilizar esas bases de datos, aunque no necesariamente de manera directa.

Estoy bastante seguro de que sus administradores de bases de datos estarían dispuestos a exportar algunos puntos de vista, para que su personal de ventas los utilice en sus teléfonos y tabletas, como catálogos de productos. Hasta podrían estar dispuestos a aceptar transacciones entrantes como pedidos, siempre y cuando hayan pasado por las mismas revisiones y logística de negocio que los otros sistemas de toma pedidos. Sin embargo, es probable que no quieran tener que gestionar credenciales de bases de datos de lectura-escritura para los dispositivos móviles.

Lo que la gente hace gran parte del tiempo es utilizar una capa intermedia para las vistas de las bases de datos móviles -a menudo una base de datos NoSQL como MongoDB o Couchbase Server. En muchos casos MBaaS lo lleva a cabo, sirviendo como backend móvil como servicio. Todo es código común, y sus desarrolladores no deberían tener que gastar mucho tiempo desarrollándolo para cada aplicación.

Potencialmente, un MBaaS puede necesitar otra licencia anual, a menos que utilice una plataforma de desarrollo de aplicaciones móviles que incluya su propio backend como servicio -sí, algunas lo hacen (como Appery.io), y otras no. Algunas opciones de MBaaS son pay-as-you-go, que es bueno si su uso será bajo, pero no si va a crear una aplicación popular empresa-consumidor.

[Soluciones MBaaS: 5 nubes para construir apps móviles]

Más allá de un backend de base de datos de registro, MBaaS podría proporcionar lo necesario para la lógica empresarial de servicios de fondo, código de backend programado, un almacén de clave-valor de JSON para ser usado por la aplicación del cliente, enlaces de autorización de LDAP y Active Directory, y soporte Beacon. También podría proveer una manera fácil de conectarse a la mensajería push a través de los servicios de mensajería de la nube de Google y Apple.

Algunos proveedores de MBaaS exponen sus APIs a través de kits de herramientas del lado del cliente, y marcos populares de JavaScript, por conveniencia de programación. Casi todos ofrecen una API REST que se puede invocar a través de solicitudes HTTPS desde cualquier lenguaje del cliente.

La sincronización de datos offline es uno de los problemas más difíciles de resolver en cuanto a aplicaciones empresariales móviles. ¿Por qué no simplemente depender del servidor de datos? Tiene que estar bromeando.

Supongamos que un técnico de servicio de campo está inspeccionando el sitio del cliente. Entra dentro de un armario de servidor que no tiene conexión Wi-Fi ni recepción celular, pero aun así tiene que tomar fotos de una lista de elementos en la sala de servidores y escribir un reporte. Idealmente, descargó los datos del trabajo antes de llegar al sitio; luego, añade sus comentarios a los registros de la página web del cliente a medida que los hace, con el teléfono offline y almacenando información a nivel local.

Mientras tanto, en la sede central, un gerente de cuenta se da cuenta de que su orden de trabajo tiene una falta de ortografía y lo arregla. Cuando el técnico termina con el armario de servidor y regresa a un área con servicio celular, su aplicación reconoce la conexión y sube su media hora de inspecciones. Cuando llega a la base de datos, una bandera se alza debido al conflicto entre el nombre de ubicación mal escrito que descargó y el nombre corregido en el servidor.

Si la política de resolución de conflictos es "el servidor gana", como pasa la mayoría de veces cuando los programadores y CTOs son flojos, entonces la media hora de trabajo completa se pierde. Si eso sucede en un lugar a una hora desde el sitio web, entonces tiene que conducir de vuelta, y habrá perdido más de dos horas de tiempo del técnico. Esa no es manera de manejar un negocio.

Tampoco se puede confiar en una política de "cliente gana". Para llevar acabo correctamente la resolución de conflictos, alguien tiene que poder mirar todos los datos y sus marcas de tiempo para decidir qué llevar en una base de campo por campo.

¿Cuáles son las necesidades de sus aplicaciones móviles?

Ahora pensemos en las necesidades de sus aplicaciones móviles. ¿Quiere que su sitio web de ventas públicas sea una aplicación? Le puedo garantizar que los consumidores querrán que la aplicación se vea y se sienta nativa, y no van a tolerar ninguna pausa a medida que la app descarga los datos desde su sitio por una conexión lenta. Probablemente está buscando aplicaciones nativas para iPhone y Android, además de una aplicación móvil web o híbrida para los teléfonos menos populares, tales como Windows Phones y BlackBerrys. Con un poco de suerte, podrá crear un backend común para el sitio y las aplicaciones, y también podrá escribir bibliotecas de código de cliente comunes para compartir entre iOS y Android.

[25 sencillas herramientas para crear apps móviles rápidamente]

¿Qué hay de su aplicación de almacén? A los trabajadores del almacén no les importa cómo se ve su aplicación -solo quieren poder acceder a la base de datos de inventario y leer códigos de barras-, así que no necesitan aplicaciones nativas. Pero también desean que sus datos permanezcan cuando contestan sus teléfonos, por lo que las aplicaciones móviles no serán lo suficientemente buenas. Pienso que la aplicación de almacén debe ser híbrida. Y sería bueno si soportara beacons, para que la aplicación pueda saber dónde está el teléfono en el almacén, ya que el GPS no funciona allí. También podría querer comprobar la cobertura Wi-Fi en el almacén -si no es 100%, entonces la aplicación va a necesitar sincronización de datos online/offline.

Por último, ¿qué pasa con las aplicaciones de gestión y de colaboración? Si las hace bien, van a funcionar de manera correcta como aplicaciones web móviles -ni los socios ni los administradores tendrán que preocuparse por actualizar sus aplicaciones.

¿Quiere el último pastelillo mochi? Camarero, ¿nos puede traer la cuenta, por favor?

Martin Heller es editor y colaborador de InfoWorld. Anteriormente fue consultor de programación en Windows y networking, desarrollando bases de datos, software y sitios web desde su oficina en Andover, Massachusetts, de 1986 a 2010. Más recientemente, se desempeñó como vicepresidente de tecnología y educación en Alpha Software y presidente de Tubifi.