Técnicas para un desarrollo rápido de soluciones móviles

Un enfoque de cumplimiento progresivo para los equipos de diseño y de desarrollo

Los sistemas de archivos y de gestión de contenidos convencionales no satisfacen las necesidades de acceso a datos de los usuarios móviles de las empresas ni tampoco las necesidades de compartir. Afortunadamente, una implementación rápida de una solución de acceso a contenido de dispositivos múltiples está fácilmente al alcance, incluso para equipos pequeños de diseño y desarrollo interno, mediante un proceso de desarrollo eficiente que nivela las tecnologías re utilizables. Descubra cómo el equipo de innovación móvil del laboratorio del Director de informática de IBM puso a prueba rápidamente una solución interna que mejora la productividad de los usuarios al proporcionarles la posibilidad de compartir archivos de forma fácil y flexible a través de todas sus plataformas aprobadas.

Tom Cook, Senior Technical Staff, IBM

Thomas Cook es un miembro jefe del Personal Técnico en IBM que es responsable de liderar los equipos de diseñadores y desarrolladores en la creación de soluciones móviles innovadoras. Su trabajo en IBM incluyó soluciones móviles, sistemas integrados, sistemas de juegos, mundos virtuales y sistemas operativos.



Charisse Lu, Software Engineer, IBM

Charisse Lu ha trabajado en tecnologías web y en espacios virtuales en 3D — y, recientemente, — como líder del equipo técnico del área "IBM CIO Lab Mobile Innovation" para la creación de soluciones móviles para los empleados de IBM.



John Reddin, Software Engineer, IBM

John Reddin es un ingeniero de software que ha trabajado en IBM desde el verano del 2009. Se unió a IBM como uno de los internos de Extreme Blue, luego trabajó en las conexiones de IBM y ahora es Director de Informática en innovaciones móviles. John estudió Ciencias Informáticas en Trinity College Dublin. Sus intereses principales se basan en arquitecturas de software escalables, el desarrollo móvil y la música informática, un área en la que ha realizado publicaciones.



Emil Varga, Software Engineer, IBM

Emil Varga es ingeniero de software en IBM Dublin desde 2008. Trabajó en el equipo Lotus Connections Wikis enLotus Connections 2.5 y 3.0 antes de unirse al Laboratorio de Innovaciones Móviles como jefe de informática a comienzos del 2012. Realizó un Máster y una Licenciatura en Ciencias e Ingeniería Informática en la Universidad de Belgrade, Serbia. Ama el aprendizaje automático, Linux, el desarrollo web y los lenguajes de programación funcionales.



24-09-2012

El equipo de innovaciones móviles del laboratorio del Director de informática en IBM desarrolla soluciones internas para ayudar a los empleados de IBM a ser más productivos y a estar seguros al utilizar sus dispositivos móviles. A finales de 2010, los empleados tenían dificultades para compartir archivos en sus computadoras portátiles, teléfonos celulares y tablets. El acceso desde dispositivos móviles a los sistemas de gestión de contenido o a los sistemas que comparten archivos era limitado y engorroso. Sin un complemento completo de plugins, ciertos archivos no se mostrarían ni funcionarían al transferirlos. Además, los archivos no podrían pasarse con facilidad desde dispositivos móviles a dispositivos de escritorio.

Nuestro equipo necesitó proporcionarle a los empleados una solución portátil para acceder al contenido interno de IBM mediante dispositivos aprobados. Decidimos desarrollar una solución piloto que actuara como una ventana hacia sus datos totales y también proporcionara un pequeño caché de datos transferibles. Los datos transferibles se transformarían en formatos compatibles para ayudar a los usuarios a consumir mejor contenidos en varias plataformas. El proyecto se denomina MyMobileHub. Con solo un pequeño equipo y unos pocos meses, tuvimos que mostrar una prueba del concepto con habilitación en plataformas de Android, BlackBerry e iOS. Algunos meses más tarde, necesitaríamos una prueba funcional nativa.

Muchos de los conceptos de desarrollo rápido que utilizamos en la prueba piloto y discutimos en este artículo son conocidos en el espacio de desarrollo móvil. Revise cómo los unimos para desarrollar una solución interna de extremo a extremo y para dispositivos múltiples, y puede obtener una idea de cuan rápido puede hacer lo mismo para su próxima prueba o proyecto móvil.

Planeamiento de una prueba piloto de desarrollo rápido

Generalmente, las pruebas piloto de innovación son un proceso iterativo: desarrollan con rapidez una solución utilizables y la comparten con un conjunto de colegas cercanos y adoptantes tempranos. Luego, expanden la funcionalidad junto con la base de usuarios al tomar los comentarios y las sugerencias como ayudas de navegación. Esto es un protocolo común para explorar una nueva solución.

Para tener éxito en una prueba piloto de la industria móvil en rápida evolución, necesitamos un enfoque decididamente diferente para el desarrollo. Exploramos un número de tecnologías reutilizables que podrían ayudarnos. Elegimos una combinación de tecnologías de fuentes abiertas y herramientas internas de IBM que cumplan con los criterios del desarrollo rápido, el sustento de la plataforma cruzada y capacidades de avanzada.

Con respecto al servidor, elegimos el marco de trabajo Play, un marco de trabajo Java sin estado de RESTful basado en conceptos del Modelo-Vista-Controlador (MVC) de "Ruby on Rails". Para el desarrollo del cliente, elegimos PhoneGap, Dojo y Dojo Mobile para obtener un estilo consistente y experiencia del usuario a través de todos los clientes. (Ver Recursos más abajo para obtener los vínculos).

Dado que un pequeño caché de archivos que planeamos transformar necesitarían agruparse, decidimos utilizar una base de datos simples en lugar de un sistema de archivos. Seleccionamos Apache CouchDB, una base de datos sin SQL y sin esquemas orientada a los documentos que soporta el almacenamiento de los documentos con un ejemplo y vistas rápidas según MapReduce.

CouchDB y Play funcionan bien juntos y nos permiten movernos rápidamente. Utilizamos Apache ActiveMQ para administrar varios mensajes y tareas que implican una tubería de conversión de documentos. Finalmente, el servidor Apache HTTP no proporcionó controles adicionales y un equilibrio de carga. Nuevamente, en esta prueba piloto, estamos explorando la viabilidad de la solución así como ganando un entendimiento de los requisitos del usuario y los patrones de uso. Los componentes clave, conceptos y diseños que podríamos querer reutilizar se trasladan fácilmente a otras plataformas cuando están listos para la producción.

Para mantenerse actualizado con el conjunto de dispositivos móviles en constante expansión, nivelamos una herramienta interna para que nos ayude a identificar las especificaciones de dispositivos móviles desde el proyecto WURFL (ver Recursos para un vínculo), un repositorio donde se encuentra disponible información como la funcionalidad del smartphone y el tamaño de pantalla. La herramienta nos ayudó a determinar fácilmente la mejor manera de mostrar el contenido de la aplicación para encajar con las capacidades del dispositivo.

El valor que obtuvimos de nuestra prueba piloto no solo fue el producto interno general (código) en sí, sino un entendimiento de cómo la gente utiliza nuestra prueba piloto. Lo más importante es que ganamos experiencia en la resolución de problemas para los usuarios móviles y familiarizados con la tecnología. Nuestros adoptantes tempranos no tienen vergüenza en decirnos si resolvimos o no un problema determinados, si coincidimos con su flujo de trabajo o si cumplimos con sus expectativas para el uso fácil y la productividad. Si no cumplíamos con nuestra misión de hacer más productivos y seguros a los usuarios, reinventamos la solución para enfrentar el problema desde un nuevo ángulo.


MyMobileHub en pocas palabras

Nuestra solución proporciona una forma sencilla para los usuarios para compartir archivos con sigo mismos. En lugar de auto enviarse correos electrónicos con los archivos que quieren abrir en los dispositivos móviles, pueden arrastrar y soltar los archivos desde su escritorio en sus navegadores con MyMobileHub. Cargamos el archivo en nuestro servidor mediante el navegador. Un usuario puede conectarse al mismo servidor desde un dispositivo móvil, — pero los presentamos con una interfaz de usuario diferentes, donde pueden visualizar el archivo sin importar su formato original. También tomamos ventaja de la cámara móvil y de las capacidades de voz para permitirle a los usuarios crear con facilidad y cargar contenido multimedia.

Vista en computadoras portátiles y de escritorio

Para el espacio de las computadoras portátiles y de escritorio, solo tenemos compatibilidad con navegadores con capacidad de arrastrar y soltar. Los usuarios arrastran marcadores, documentos u otros archivos en la ventana del navegador, como lo muestra la Ilustración 1. Para los documentos cuyos formatos podemos entender, proporcionamos vistas preliminares y creamos versiones en PDF que son fáciles de leer en dispositivos móviles. Tenemos planes de convertir otros tipos de archivos, como convertir archivos de audio a archivos de texto.

Ilustración 1 Características de MyMobileHub
Ilustración 1 Características de MyMobileHub

Los navegadores de escritorio proporcionan una forma conveniente para cargar y organizar archivos. Se genera de forma automática una imagen de vista previa para cada archivo. Los usuarios pueden seleccionar una lista de elementos o una grilla para administrar sus archivos visualmente. Las etiquetas dinámicas codificadas a color los ayudan a organizar sus archivos sin la molestia de una jerarquía clásica de sistema a archivo. Los filtros de archivos y de etiquetas, junto con la característica de función instantánea hace que encontrar los archivos sea rápido y fácil.

Aplicaciones web móviles

Los navegadores en smartphones y tablets son bastante avanzados. Al utilizar Dojo Mobile y JavaScript, puede suministrarse una aplicación rica a través del navegador. Los servicios internos de identificación del dispositivo controlan el tipo de dispositivo y nos ayudan a seleccionar la combinación reutilizable adecuada de código, HTML y CSS para descargar el dispositivo. Dependiendo de las capacidades del dispositivo, suministramos la página que es mejor para la visualización. En un dispositivo como el iPad, la página de la aplicación web es muy similar a la página de aplicación web para el navegador de escritorio, por lo tanto proporciona al usuario una experiencia sin dificultades. Como puede observar a partir de la Ilustración 2, la experiencia del usuario es más parecida a una aplicación que a una página web. Los usuarios pueden solicitar la descargar del archivo, que se descargue la versión en PDF para su visualización y la inserción en la biblioteca o el lanzamiento de una marca para una página web.

Ilustración 2 Aplicación web móvil MyMobileHub
Ilustración 2 Aplicación web móvil MyMobileHub

Aplicaciones móviles nativas

Las aplicaciones nativas MyMobileHub se ven similar a las aplicaciones web que se ejecutan en el navegador móvil, pero tienen la capacidad agregada de cargar el contenido generado desde el dispositivo mismo. Los usuarios pueden grabar audios o videos, tomar una imagen o seleccionar una desde su galería. Todo puede cargarse directamente desde MyMobileHub.

Ilustración 3 Aplicación nativa de MyMobileHub
Ilustración 3 Aplicación nativa de MyMobileHub

Donde comienza la eficiencia: Metodología, enfoque y diseño

Antes de realizar cualquier trabajo de codificación, investigamos varias tecnologías. La selección de herramientas fue un proceso cuidadoso que nos inició en el camino correcto. Juntamos a los diseñadores de experiencia del usuario y de interfaz del usuario. También unimos a los desarrolladores (ambos). Trajimos a nuestro desarrollador web experto (que vive en Brasil). Cada grupo era responsable de educar a los demás sobre la eficiencia de los variados conjuntos de herramientas, como el diseño de gráficos, HTML5, CSS, aparatos de interfaz de usuario y capacidades del servidor. Al educar a otros, compartimos los puntos de débiles y las tecnologías de eficiencia.

También tomamos algunas decisiones como no tener compatibilidad con ciertos niveles de sistemas operativos y niveles del navegador. Al focalizarnos en suministrar navegadores con capacidad HTML5, podemos simplificar nuestro proceso de desarrollo. Dejó de reconocer las tendencias importantes de tecnología y anticipar su crecimiento en software y hardware. Por ejemplo, aproximadamente tres meses después decidimos focalizarnos en los navegadores con capacidad HTM5, todos los dispositivos móviles eran compatibles con HTM5.

Datos únicos / CSS múltiple

Una de nuestras primeras decisiones más importantes desde una perspectiva móvil consistió en proporcionar la mayor cantidad posible de interfaces de usuario y elementos de formato a CSS y a HTML5. Al hacer esto, no ganamos solo simplificación del código, sino también unificación del código a través de todas las plataformas móviles.

Necesitamos tener compatibilidad con iPhone, iPod Touch, iPad, BlackBerry y con teléfonos y tablets de tamaño medio o total Android, así como también con escritorios Mac, Linux y Windows. Cada línea de código personalizado que se expande en cada plataforma aumenta la exposición de confiabilidad y la complejidad. Nuestro modelo de datos únicos / CSS múltiple nos permitió utilizar la misma fuente de datos de JavaScript Object Notation (JSON) para crear interfaces de usuarios completamente diferentes para estas plataformas con solo un subconjunto de CSS personalizado para cada uno.

Para lograr esto, escribimos módulos personalizados de CSS para cada una de nuestras plataformas. En el caso de las aplicaciones web, cuando un dispositivo solicita HTML de nuestro servidor, detectamos qué clase de dispositivo es y cargamos de forma dinámica el módulo CSS personalizado adecuado. Para las aplicaciones nativas, ya conocemos el tipo de plataforma que puede cargar la aplicación, entonces podemos limitar nuestras personalizaciones a cosas como el tamaño de la pantalla y la versión del sistema operativo. Un ejemplo de esto son la aplicaciones de iPhone y de iPad, que comparten cerca de un 99,9 por ciento del mismo código, pero — gracias al poder del CSS dinámico — tienen la apariencia correcta para el tamaño de la pantalla.

El Listado 1 muestra el módulo CSS para iPhone y iPad:

Listado 1 Módulo CSS para iPhone y para iPad
.loginScreen {
    background-image: url(../images/splashBG.png);
    background-repeat: no-repeat;
    background-size: 320px;
}

.loginScreeniPad {
    background-image: url(../images/splashBGiPad.png);
    background-repeat: no-repeat;
    background-size: 768px;
}

Adición de un nivel de eficiencia con PhoneGap

Nuestro amplio equipo incluyó desarrolladores que son expertos en desarrollar aplicaciones personalizadas para la mayoría de las plataformas móviles. Generalmente, podríamos solicitarle a cada experto en plataformas móviles que se involucre y desarrolle una aplicación personalizada. Sin embargo, dado nuestro breve marco de tiempo y las interfaces del usuario relativamente simples que visualizamos, tomamos un enfoque diferente. Al trabajar de forma diligente para incluir todo lo que se pueda de la función de las aplicaciones web en HTML5 y en CSS, pudimos utilizar PhoneGap incluir HTML5 y CSS en aplicaciones nativas.

Herramientas como PhoneGap son simples en concepto. Comienza con una aplicación web escrita con tecnologías JavaScript, HTML y CSS. PhoneGap luego la agrupa como una aplicación nativa cuya primera tarea es lanzar un navegador interno para visualizar solo la aplicación web (una WebView). Ahora puede accederse a las API nativas,— como aquellas para las cámaras de los dispositivos,— con llamadas JavaScript que unen la aplicación web con el código nativo. El código JavaScript para acceder a la cámara es el mismo en todos los dispositivos, nuevamente fortaleciendo el objetivo de una base de código único para varias plataformas. El recorte del código en el Listado 2 muestra cómo puede capturarse una imagen en un dispositivo utilizando solo la función JavaScript:

Listado 2 Captura de una imagen utilizando una función simple de JavaScript
mmh.phonegapActions.captureImage = function() {
    navigator.device.capture.captureImage(
		dojo.partial(mmh.phonegapActions._captureSuccess, "image"), 
            mmh.phonegapActions._captureError, {limit: 1});
};

La utilización de una herramienta como PhoneGap tiene ciertas desventajas. Definitivamente, no es tan eficiente ni tiene una ejecución más rápida que una aplicación escrita en código nativo. Las mismas tareas de ejecución pesada, como las animaciones complejas de gráficos, requerirían de ejecuciones nativas sensibles. Las herramientas de depuración y de prueba aún se encuentran en su primera etapa de desarrollo, aunque esta situación está mejorando con la emergencia de herramientas como Ripple y WEINRE (ver Recursos). No tiene el control de las capas de hardware que tendría con la aplicación nativa de fábrica. (Puede superar esta desventaja al escribir plugins personalizados de PhoneGap. Muchos plugins están disponibles para tareas específicas). Sin embargo, en nuestro caso, los beneficios de la re utilización significativa sobrepasa las desventajas de PhoneGap.

Otra consideración para utilizar PhoneGap es que el diseño de la aplicación deberían ser nativo. El conocimiento de diferentes plataformas móviles ayuda a los desarrolladores de aplicaciones a alcanzar la apariencia nativa son escribir el código nativo. En nuestro ciclo de innovación actual, la velocidad en la que tomamos las aplicaciones web bien diseñadas y las trasladamos aplicaciones nativas está funcionando lo suficientemente bien. Al utilizar PhoneGap, convertimos la aplicación web de Android en una aplicación nativa compatible con grabación de audio, video e imagen, la ventana de notificación nativa y los botones menú, atrás e inicio del hardware en menos de dos días. También pudimos reutilizar ese código para BlackBerry.

La conexión en cascada cambia eficientemente

A veces, incluso si realizó un buen trabajo con los diseñadores de experiencia de usuario y los diseñadores de interfaz de usuario para alcanzar lo que cree que es la mejor interfaz del usuario, los usuarios se quejan de que no pueden descifrar cómo realizar una tarea simple. (¿Cómo se lo perdió?).

Entonces, resulta en un cambio que simplifica la experiencia del usuario, y ahora necesita propagarlo a todas las aplicaciones web y nativas. Sin un nivel elevado de reutilización a través de las plataformas, sus desarrolladores deben tocar cada plataforma específica y realizar el cambio muchas veces. Multiplica eso por el número de casos de prueba que debe volver a ejecutar y los cambios pequeños se convierten en cambios monstruosos. Nuevamente, al aprender sobre el formato HTML5 y CSS, puede realizar la mayoría de los cambios en un nivel inferior. Los cambios en la codificación con los datos únicos / CSS múltiples la dirección pasa a ser menos disruptiva. Después de que se prueban las aplicaciones web, puede movilizar los cambios en las soluciones de aplicaciones nativas de PhoneGap y listo.

Un ejemplo que encontramos es la inclusión del botón Refresh para proporcionarles a los clientes confianza de que pueden re escanear los datos que podrían creer están desincronizados. Desarrollamos y probamos esta función en Android y luego reutilizamos el mismo código en todas las plataformas con un alto grado de confianza. Las pequeñas lesiones de CSS ayudaron a obtener la apariencia correcta en los dispositivos y la función está terminada.

Al utilizar este método de re utilización, estimamos que toma aproximadamente un 10 por ciento del tiempo de desarrollo para tener un nuevo trabajo de función en todas las plataformas después del 90 por ciento inicial de desarrollo de la característica. Evidentemente, este no sería el caso si la misma característica tuviera que ser re escrita con diferentes API, lenguajes y marcos de trabajo para cada plataforma nativa.

Este método de reutilización también se aplica a correcciones de fallas. Si se encuentra una falla en la interfaz del usuario de la aplicación web de iPhone, probablemente exista la misma falla en las aplicaciones para iPad, Android y BlackBerry, dado que comparten el 99 por ciento del mismo código. Al solucionar la falla en una sola plataforma, se solucionan en todas las aplicaciones web. Además, es fácil precisar la fuente de las fallas en las versiones nativas.

También tenemos un conjunto de sprites para todos los gráficos, pero con algunos CSS y Dojo Mobile, tenemos la apariencia correcta para el dispositivo sin demasiado trabajo adicional.

No es un proceso perfecto

Continuamos desarrollando y optimizando nuestro proceso, de ese modo, necesitamos realizar menos personalizaciones con un mejor soporte en todas las plataformas. Un ejemplo de este se encuentra en la navegación nativa a través de dispositivos. los dispositivos iOS no incluyen botones de hardware Atrás o Menú, mientras que los dispositivos Blackberry y Android (al menos hasta Android 4.0) sí los tienen. Además, los botones de menú de BlackBerry y de Android funcionan de formas diferentes. Para enfrentar esta disparidad, separamos nuestro código JavaScript en aparatos que pueden insertarse o modificarse para encajar con cada plataforma con poca o sin disrupción para el resto del código. No solo es importante separar el código desde CSS, sino también modular los componentes para que el código pueda volver a utilizarse o remplazarse fácilmente.

Hemos logrado minimizar la cantidad de codificación de casos específicos al seguir nuestra política de datos únicos / CSS múltiple.

Aplicaciones web frente a aplicaciones nativas

¿Es mejor implementar aplicaciones web o aplicaciones nativas? En nuestra experiencia en el área de Innovación Móvil del Laboratorio del Director de Informática, la respuesta es: ambos. Gracias a los avances recientes de los navegadores de smartphones y tablet, las aplicaciones web funcionan bien en los dispositivos móviles. En este momento, las aplicaciones nativas proporcionan más acceso a características nativas del hardware.

Sin embargo, la decisión no es solo acerca de qué es lo mejor. Descubrimos que usuarios que están probando nuestras soluciones están ansiosos esperando poder instalar una aplicación nativa. Simplemente, algunos no están listos para comprometerse con nuestra solución. Antes de instalar una aplicación nativa, quieren probarla. Las aplicaciones nativas requieren mantenimiento y actualizaciones.

Al ser compatible con aplicaciones web y nativas, podemos mantener una política de cero instalación para nuestra innovación. Además, los usuarios ciclan a través de más dispositivos de los que cree. Cuando obtienen un dispositivo nuevo, primero lo prueba con nuestra aplicación web antes de instalar una aplicación nativa. Siempre hay ventajas y desventajas en las funciones, el diseño y el tiempo de implementación.


Conclusión

Probar una solución utilizando el modelo que describimos ayuda a equipos como los nuestros a explorar el valor central de sus ideas. El proceso comienza con una investigación minuciosa sobre la fuente abierta de las mejores herramientas— internas — disponibles para solucionar el problema. Así, puede analizar las ventajas y las desventajas del funcionamiento y del diseño. A veces, conocer el valor de la velocidad del mercado frente a la totalidad de la función podría ser lo que se necesita para lograr una prueba exitosa. Después de que el valor central se articula a través de los comentarios de los usuarios y la adopción, puede iniciarse el proceso de convertir una prueba piloto en un servicio de producción o en un producto.

Esperamos que este artículo le proporcione algunas técnicas para su próximo proyecto que ayudará a su equipo — y, finalmente, ya los usuarios de su solución — a ser más efectivos y productivos. Nuestra prueba piloto incluye muchos cambios en los requisitos de los usuarios, pero estamos seguros de que nuestro pequeño equipo puede mantenerse al ritmo de las solicitudes de cambio de los usuarios. Hemos simplificado el diseño y desarrollado un proceso que cicla todas las semanas gracias a la eficiencia de la metodología que seleccionamos al comienzo.

Recursos

Aprender

Obtener los productos y tecnologías

  • Evalúe los productos de IBM de la forma que más le convenga: Descargue pruebas de productos, pruebe un producto en línea, utilice un producto en el contexto de la nube o pase algunas ora en SOA Sandbox para aprender a implementar eficientemente arquitectura orientada al servicio.

Comentar

  • Participe en la comunidad de developerWorks y conéctese con otros usuarios de developerWorks mientras visita blogs, foros, grupos y wikis de los desarrolladores.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Desarrollo móvil
ArticleID=836596
ArticleTitle=Técnicas para un desarrollo rápido de soluciones móviles
publish-date=09242012