MÉTODO Y SISTEMA PARA GENERAR Y GESTIONAR APLICACIONES NATIVAS.

Método y sistema para generar y gestionar aplicaciones nativas.

El método comprende:

a) crear, un desarrollador de aplicaciones, una aplicación genérica basada en un tiempo de ejecución;

b) generar una pluralidad de aplicaciones nativas para diferentes sistemas operativos correspondientes agrupando dicha aplicación genérica con un tiempo de ejecución para cada sistema operativo soportado, u OS, manejando dichos tiempos de ejecución API de OS/dispositivo y API de red; y

c) gestionar dichas aplicaciones nativas mediante al menos su almacenamiento en una base de datos y/o su distribución a dispositivos informáticos,

comprendiendo el sistema medios para realizar dichas etapas b) y c) del método de la invención.

Método y sistema para generar y gestionar aplicaciones nativas Campo de la técnica La presente invención se refiere, en general, en un primer aspecto, a un método para generar y gestionar aplicaciones nativas, basado en el agrupamiento de una aplicación genérica con tiempos de ejecución adecuados, y más particularmente a un método que comprende usar tiempos de ejecución que manejan API de red.

Un segundo aspecto de la invención se refiere a un sistema para generar y gestionar aplicaciones nativas adaptado para implementar el método del primer aspecto.

Estado de la técnica anterior

El desarrollo de aplicaciones para dispositivos móviles era una tarea que requería mucho tiempo porque los desarrolladores necesitaban crear múltiples versiones de la misma aplicación para diferentes dispositivos y/o sistemas operativos (figura 1) .

Debido a esta situación, se creó el concepto de tiempo de ejecución de dispositivo cruzado u OS cruzado. Un tiempo de ejecución permite desarrollar la misma aplicación una vez y desplegarla en múltiples OS/dispositivos siempre que esté disponible el tiempo de ejecución apropiado en los dispositivos objetivo (figura 2) .

Sin embargo, el paradigma que fue promocionado por JavaME [1] en primer lugar y ahora por WAC [2] ha experimentado algunos problemas prácticos:

-No todos los dispositivos disponen del tiempo de ejecución apropiado.

-Los tiempos de ejecución suministrados por diferentes ISV u OEM se implementan de diferentes maneras.

Debido a estos factores, cuando un desarrollador creaba una aplicación para un tiempo de ejecución, no estaba seguro de si la aplicación iba a ejecutarse en el dispositivo objetivo debido a la ausencia del tiempo de ejecución o a diferencias con el tiempo de ejecución con el que sometió a prueba y verificó la aplicación.

Con el fin de evitar estos problemas, se han creado algunas iniciativas con el fin de agrupar la aplicación con el tiempo de ejecución requerido (por ejemplo Phonegap [3]) y crear (basándose en una única aplicación de desarrollador) múltiples aplicaciones nativas (una por plataforma) . Al suministrar un paquete que incluye los dos componentes, el desarrollador garantiza que la aplicación se ejecutará en el dispositivo independientemente del OS, el modelo y la disponibilidad del WRT (Web Runtime, tiempo de ejecución web) (figura 3) .

Aunque la solución ilustrada en la figura 3 podría parecer un buen enfoque, vuelve a llevar de nuevo al desarrollador al problema de la heterogeneidad de OS y dispositivos: los desarrolladores necesitan usar diferentes versiones del tiempo de ejecución para cada OS y dispositivo.

Con el fin de paliar ese problema, PhoneGap ha creado otra iteración denominada “Phonegap Build” [4] (figura 4) . Los desarrolladores pueden presentar simplemente su aplicación creada para el tiempo de ejecución, y esa aplicación se convertirá y empaquetará para los diferentes sistemas operativos.

Problemas con las soluciones existentes:

Aunque los desarrolladores pueden obtener ahora apps nativas basándose en una única aplicación de tiempo de ejecución, las soluciones actuales sólo están considerando la inclusión de tiempos de ejecución que abstraen la heterogeneidad de las API de dispositivo. Sin embargo, los desarrolladores no sólo están interesados en una capa de abstracción en esa área, sino en algunas otras tales como:

-API de red: la utilización de recursos disponibles en la red es una de las características en las que también están interesados los desarrolladores (por ejemplo facturación dentro de la aplicación (in-app billing) , identidad de usuario…) . En este caso, el manejo de la seguridad (autenticación y autorización) es especialmente crítico, ya que los flujos pueden ser sensibles a la seguridad, complejos y extremadamente difíciles de gestionar por los desarrolladores.

-Seguridad: Los diferentes OS tienen diferentes modelos de seguridad, y algunos de ellos no son suficientemente seguros para satisfacer las necesidades de los usuarios. Ninguna de las soluciones actuales proporciona una experiencia de seguridad común en diferentes OS.

Descripción de la invención Es necesario ofrecer una alternativa al estado de la técnica que cubra las lagunas encontradas en el mismo, particularmente las que existen en los tiempos de ejecución usados para generar aplicaciones nativas con respecto a las capas de abstracción que no se incluyeron en las propuestas mencionadas anteriormente.

Con ese propósito, la presente invención se refiere, en un primer aspecto, a un método para generar y gestionar aplicaciones nativas, que comprende:

a) crear, un desarrollador de aplicaciones, una aplicación genérica basada en un tiempo de ejecución;

b) generar una pluralidad de aplicaciones nativas para diferentes sistemas operativos correspondientes agrupando dicha aplicación genérica con un tiempo de ejecución para cada sistema operativo soportado, u OS, manejando dichos tiempos de ejecución API de OS/dispositivo; y

c) gestionar dichas aplicaciones nativas mediante al menos su almacenamiento en una base de datos y/o su distribución a dispositivos informáticos.

En el método del primer aspecto de la invención, a diferencia de las propuestas conocidas, dicha etapa b) comprende además agrupar dicha aplicación genérica con un tiempo de ejecución que maneja API de red y generar cada una de dichas aplicaciones nativas con manejo de seguridad realizando para ello al menos una de las siguientes acciones:

- añadir una estructura de seguridad para restringir el acceso a dichas API de OS/dispositivo;

- añadir una estructura de seguridad para controlar la autenticación y autorización de la utilización de dicha API de red; y

- aplicar al menos una de un conjunto de reglas de transformación que incluyen: firmado de aplicaciones e incrustación de las credenciales del desarrollador para la utilización de API de red.

Otras realizaciones del método del primer aspecto de la invención se describen con referencia a las reivindicaciones 3 a 9 adjuntas, y en una sección posterior relativa a la descripción detallada de varias realizaciones.

Un segundo aspecto de la invención se refiere a un sistema para generar y gestionar aplicaciones nativas, que comprende medios para realizar al menos las etapas b) y c) del método del primer aspecto Algunas realizaciones del sistema del segundo aspecto de la invención se describen con referencia a las reivindicaciones 11 y 12 adjuntas, y en una sección posterior relativa a la descripción detallada de varias realizaciones.

Breve descripción de los dibujos Las anteriores y otras ventajas y características se entenderán más completamente a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos, que deben considerarse de manera ilustrativa y no limitativa, en los que:

la figura 1 muestra un mecanismo de la técnica anterior con respecto al desarrollo de apps nativas en el que se crean originariamente múltiples versiones de la misma aplicación;

la figura 2 muestra otra propuesta de la técnica anterior relativa al desarrollo de apps de tiempo de ejecución en la que se proporcionan tiempos de ejecución en los dispositivos objetivo;

la figura 3 ilustra otro escenario de la técnica anterior en el que los tiempos de ejecución se incrustan con la aplicación por parte del desarrollador;

la figura 4 muestra esquemáticamente un sistema de la técnica anterior que difiere del de la figura 3 en que la incrustación de tiempos de ejecución se realiza por medio de un generador de aplicaciones que recibe la aplicación del desarrollador;

la figura 5 muestra, a nivel esquemático, la arquitectura del sistema del segundo aspecto de la invención usado para implementar el método del primer aspecto, en una realización;

la figura 6 muestra a flujo de trabajo de alto nivel representativo de una realización del método del primer aspecto de la invención;

las figuras 7 a 11 muestran secuencialmente las etapas 1 a 5 de un proceso de generación de aplicaciones según el método del primer aspecto de la invención, en una realización, que termina, en la etapa 5 de la figura 11, con la creación de una aplicación nativa;

la figura 12 muestra esquemáticamente la aplicación nativa creada una vez instalada en el dispositivo/OS tras haber seguido un proceso de descarga de aplicaciones según una realización del método de la invención;

la figura 13 muestra la configuración de seguridad mostrada al usuario del dispositivo cuando se ejecuta la aplicación por primera vez,...

1. Método para generar y gestionar aplicaciones nativas, que comprende:

a) crear, un desarrollador de aplicaciones, una aplicación genérica basada en un tiempo de ejecución;

b) generar una pluralidad de aplicaciones nativas para diferentes sistemas operativos correspondientes agrupando dicha aplicación genérica con un tiempo de ejecución para cada sistema operativo soportado, u OS, manejando dichos tiempos de ejecución API de OS/dispositivo; y

c) gestionar dichas aplicaciones nativas mediante al menos su almacenamiento en una base de datos y/o su distribución a dispositivos informáticos;

estando el método caracterizado porque dicha etapa b) comprende además:

- agrupar dicha aplicación genérica con un tiempo de ejecución que maneja API de red; y

- generar cada una de dichas aplicaciones nativas con manejo de seguridad realizando para ello al menos una de las siguientes acciones:

o añadir una estructura de seguridad para restringir el acceso a dichas API de OS/dispositivo;

o añadir una estructura de seguridad para controlar la autenticación y autorización de la utilización de dichas API de red; y/o

o aplicar al menos una de un conjunto de reglas de transformación que incluyen: firmado de aplicaciones e incrustación de las credenciales del desarrollador para utilización de API de red.

2. Método según la reivindicación 1, que comprende además comprobar la validez de dicha aplicación genérica antes y como condición o inicio de dicha etapa b) .

3. Método según cualquiera de las reivindicaciones anteriores, que comprende, para la generación de cada una de dichas aplicaciones nativas, realizar dicha etapa b) para llevar a cabo dicho agrupamiento de tiempos de ejecución o dicho agrupamiento de tiempos de ejecución y acciones adicionales, según un flujo de trabajo.

4. Método según la reivindicación 3, que comprende iniciar dicho flujo de trabajo leyendo un perfil de desarrollador suministrado, los OS soportados, los tiempos de ejecución y los parámetros de seguridad, y basándose en eso, determinar cuál es el flujo de trabajo por el que debe pasar la aplicación genérica, incluyendo dicha determinación la selección de los tiempos de ejecución, las estructuras de seguridad y las reglas de transformación que van a aplicarse, a partir de una pluralidad de tiempos de ejecución, estructuras de seguridad y reglas de transformación, y el orden en el que se realizan.

5. Método según la reivindicación 4, que comprende adaptar/personalizar dichas estructuras de seguridad dependiendo de las elecciones de dispositivos informáticos por parte del usuario final.

6. Método según la reivindicación 1, que comprende, una vez almacenada dicha aplicación nativa en dicha memoria de dispositivo informático, ejecutar por primera vez la aplicación nativa, proporcionando dicha ejecución la notificación que notifica al usuario del dispositivo informático acerca de las API de dispositivo y red que va a usar la aplicación.

7. Método según la reivindicación 6, en el que dicha primera ejecución también proporciona al usuario del dispositivo informático medios para permitirle personalizar el régimen de interacción asociado a las API de dispositivo y red.

8. Método según la reivindicación 7, que comprende cuando la aplicación nativa intenta usar una API de dispositivo, comprobar si es necesaria una interacción, y en caso afirmativo, la estructura de seguridad de RT de API de dispositivo pide al usuario una autorización, y en caso de que lo permita o no sea necesaria una interacción, se autorizará la utilización de la API y se concederá y usará la capacidad nativa.

9. Método según la reivindicación 8, que comprende cuando la aplicación nativa intenta usar una API de red, comprobar, la estructura de seguridad, si la utilización de esa API se ha autorizado antes por el usuario final, y:

i) si la utilización se ha autorizado antes, conociendo ya la estructura de seguridad un testigo de desarrollador así como un testigo de autorización, incluir ambos en una petición de red que se crea basándose en la llamada de desarrollador original;

ii) si la utilización no se ha autorizado o la autorización ha expirado, comprobar, la estructura de seguridad, la autorización de utilización de las API para dicho usuario, y si la autorización no es satisfactoria rechazar la petición para acceder a las API de red, y si es satisfactoria, la petición del desarrollador se procesa adicionalmente tal como se especifica en i) .

10. Sistema para generar y gestionar aplicaciones nativas, que comprende medios para realizar al menos 5 dichas etapas b) y c) del método según cualquiera de las reivindicaciones anteriores.

11. Sistema según la reivindicación 10, que comprende al menos una de las siguientes bases de datos para gestionar diferente información necesaria para implementar el método:

o Base de datos de tiempos de ejecución, en la que están disponibles dichos tiempos de ejecución;

o Base de datos de reglas, en la que están disponibles las reglas de transformación;

o Base de datos de dispositivos, en la que está almacenada información acerca de los OS y dispositivos soportados;

o Base de datos de desarrolladores, en la que están disponibles la información y las credenciales de los desarrolladores; y

o Base de datos de aplicaciones, en la que están disponibles las aplicaciones genéricas y nativas.

12. Sistema según la reivindicación 11, que comprende además una unidad de traductor de aplicaciones para realizar dicho flujo de trabajo del método según la reivindicación 4.