![Extensibilidad en Smart Devices ,[object Object],[object Object],[object Object],#GX2428](https://image.slidesharecdn.com/gx21-extensibilidadensmartdevices-110915093528-phpapp02/85/GX21-Extensibilidad-en-Smart-Devices-1-320.jpg)
![¿ Qué se puede extender ? ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Extensibilidad en Smart Devices: User Controls y External Objects
Ähnlich wie Extensibilidad en Smart Devices: User Controls y External Objects (20)
Extensibilidad en Smart Devices: User Controls y External Objects
- 8. User Controls: Como se hacen
- 13. External Objects
- 16. External Objects: Como se hacen
Hinweis der Redaktion
- Buenas tardes, mi nombre es Marcos Crispino, soy integrante del equipo de desarrollo de Artech. Estoy trabajando principalmente en el generador para iOS. Antes de empezar la charla, ¿quiénes han desarrollado user controls o external objects para web en la Evolution 1? Bien. Los que hayan estado trabajado con algo de esto van a encontrar varias cosas que son similares. Obviamente también hay diferencias, porque hay muchas cosas que dependen de la plataforma, pero intentamos hacerlo lo más parecido posible a lo que ya había en versiones anteriores. La idea de la charla es contarles cuales son los distintos puntos de extensibilidad con que cuentan los generadores para Smart Devices en la Evolution 2, y darles un panorama general de lo que implica cada uno de estos mecanismos. Qué se puede hacer, y a grandes rasgos, cómo se hace.
- Veamos primero cuales son las cosas que podemos extender. Básicamente hay dos puntos de extensibilidad. Se puede extender el generador agregando nuevos componentes de interfaz de usuario, o se puede extender el comportamiento agregando componentes que interactúen con el dispositivo. Para la interfaz de usuario, tenemos los user controls, y podríamos considerar también los temas como puntos de extensibilidad. Para la interacción con el dispositivo tenemos los external objects.
- ¿Cuáles son los motivos por los cuales quisiera extender los generadores? Primero que nada, porque tengo una buena idea… Porque se me ocurrió alguna cosa que no está contemplada en las clases estándar de GeneXus. En los generadores estamos intentando tener contemplados la mayor cantidad posible de casos de uso, pero seguramente a alguien se le pueda ocurrir algo que no está, y está bueno que esa funcionalidad se pueda agregar de forma simple. Puedo querer crear una extensión como un modelo de negocio. Si tengo una extensión que hice, la puedo comercializar en el marketplace de GeneXus como se hace hoy con los user controls web, y obtener un beneficio económico. También podría querer extender el generador como una forma de diferenciar mi aplicación. Hoy en día en cualquiera de los mercados de las tres plataformas que estamos generando, hay cientos de miles de aplicaciones. Es decir, que para crear una aplicación que se destaque, puede ser que no me alcance con los controles estándar. Y por último porque la cantidad de potenciales beneficiarios es muy grande. El desarrollo de la extensión lo va a hacer un desarrollador, o un grupo pequeño, pero los potenciales usuarios son todos los usuarios de GeneXus y todos los usuarios de las aplicaciones generadas que es un número muy grande. Es decir, con poco trabajo, potencialmente estamos mejorando la experiencia de uso de muchos.
- Pasemos ahora a ver un poco más en detalle los user controls
- Para empezar quería mostrarles algunos ejemplos. Estos son ejemplos de user controls que están incluidos dentro de la funcionalidad estándar de GeneXus, pero lo que quiero destacar es que se desarrollaron usando los mismos mecanismos de extensibilidad que tienen disponibles ustedes. Estos los desarrollamos nosotros porque parecen ser lo bastante genéricos para incluirlos en la funcionalidad estándar, pero los podría haber hecho un tercero de la misma forma. El primer ejemplo es la galería de imágenes. Este control permite mostrar un conjunto de imágenes de una forma visualmente más atractiva que lo que permitiría por ejemplo una lista. Además tiene funcionalidad adicional, por ejemplo cuando selecciono una imagen la muestra a pantalla completa con una descripción, y permite moverse a la imagen anterior y a la siguiente. El segundo ejemplo es el mapa, que permite mostrar un conjunto de puntos dados por campos de tipo Geolocation. Otra vez, esta información se podría mostrar en una lista, mostrando las coordenadas de cada item, pero el mapa es mucho más fácil de visualizar. Además permite interacción, nos podemos acercar o alejar, seleccionando un punto nos muestra un globito con el detalle, etc. El tercer ejemplo que quería mostrar es el Star Rating, que muestra un valor numérico como un conjunto de estrellas. Esto es muy útil cuando se quiere pedir al usuario que califique algo, por ejemplo una película en una aplicación de cartelera.
- Acá hay algunos otros ejemplos de user controls que ya están hechos. El primero es el control chart que permite hacer gráficas. Los datos que muestra deben ser numéricos, y puede mostrar varias series de datos con distintos tipos de gráficas. El segundo se llama «linear gauge», mustra un valor numérico en una escala y permite definir secciones con colores distintos. El último es el «wheel control» que permite mostrar un valor numérico o un enumerado usando una ruedita. En este caso lo que muestra es un número de dos dígitos con un decimal. Y seguramente en el futuro vayan a haber muchos controles más, algunos desarrollados por nosotros y otros desarrollados por ustedes.
- En la versión beta 4 que se está liberando en este evento, tenemos dos tipos de user controls. El primero son las listas. Tengo un conjunto de datos que quiero mostrar, por ejemplo registros de una tabla, y lo voy a mostrar de una forma distinta a la lista que se muestra por defecto. Los ejemplos son la galería de imágenes y el mapa que mostré en la diapositiva anterior. Le llamamos «lista» porque la forma por defecto de mostrarlo es en una lista, pero en realidad son controles que van sobre un conjunto de registros. El otro tipo de user controls que tenemos son para controles individuales. Estos controles se usan para mostrar un único valor, por ejemplo el contenido de un atributo o de una variable. El ejemplo de esto es el star rating o la ruedita. En un futuro, queremos tener otros tipos de user controls, que no están todavía porque el caso de uso es más difícil de visualizar. El primero de estos son las acciones, que hoy solo se pueden mostrar con un botón, pero podría querer mostrarlo de otra forma. Por ejemplo un toggle button, que se prenda o se apague cuando se selecciona, además de disparar la acción asociada. El otro tipo de user controls que queremos tener a futuro es para formularios completos. Cuando voy a mostrar un registro de una transacción por ejemplo, podría querer mostrarlo de alguna forma que no sea un formulario. No tengo un caso de uso claro para esto, pero seguramente a alguien se le va a ocurrir… El último caso es para dashboards, es decir la pantalla de inicio de la aplicación. Hoy en día ya se puede ver de varias formas: como lista, como grilla o con tabs. Pero podría haber alguien que lo quiera mostrar de alguna otra forma, y tenemos que darle el mecanismo para hacerlo.
- Pasemos ahora a ver un poco como es que se hacen nuevos user controls. El proceso tiene básicamente tres grandes pasos, que son: una etapa de definición, donde le decimos que tipo de control es, para que tipos de datos sirve, que propiedades va a tener, y ese tipo de cosas; luego viene la implementación, que se hace por plataforma con las particularidades que cada una de estas tiene; y por último la distribución del user control donde se juntan ambas cosas y se agregan a GeneXus. Vamos a ver cada uno de estos puntos con un poco más de detalle.
- La definición de user controls para smart devices es muy parecida a la definición de los user controls para web. Para los que ya han desarrollado user controls web, los user controls para smart devices usan los mismos archivos con extensión .control, que es básicamente un archivo XML donde se definen varias cosas del user control. Una diferencia que tienen con los user controls para web, es que en este caso se le debe indicar que la plataforma del control es Smart Devices, porque por defecto asume que es web. Además se le debe indicar el control type, para el caso de las listas, porque por defecto asume que es para controles individuales. Lo otro que le debemos indicar al control, es cuales son los archivos donde está la implementación y los archivos de recursos, además del nombre de la clase que lo implementa, por plataforma. Para esto hay propiedades que son específicas para cada plataforma. Básicamente eso es todo lo que tenemos que definirle al control. Si se quiere que el control tenga además propiedades, se definen en otro archivo XML cuales va a tener. Por ejemplo, la galería de imágenes tiene una propiedad para saber cual es el atributo con la imagen y cual es el que tiene la descripción. Para el mapa, tenemos por ejemplo cual es la imagen que se tiene que usar para mostrar el pin. Y lo otro que se necesita, es tener la implementación del control, es decir, los archivos binarios y de recursos. Estos archivos son los mismos que se declaran en el .control como decía antes, y tienen que distribuirse con el control para que puedan ser copiados al proyecto compilado cuando se ejecuta la aplicación desde GeneXus.
- Acá tenemos un ejemplo las propiedades del user control Star Rating. Como ven el control define dos propiedades que son el valor máximo y el «step» que dice cuanto vale cada estrella. El archivo de propiedades es el siguiente. Es un XML, que tiene algunos tags y por ahí tiene la definición de las propiedades que es bastante directo el mapeo entre lo que se ve en el ambiente de desarrollo y lo que se define en el archivo. Cada propiedad tiene un identificador, un nombre, de que tipo es, en este caso enteros y puede tener un valor por defecto. Como ven es algo bastante sencillo.
- Con respecto a la implementación del control, se hace por plataforma ya que todas las plataformas son distintas. Aunque lo mejor es que esté disponible para todas las plataformas, esto no es estrictamente requerido y se podría hacer un user control que funcione en una sola plataforma. Si tengo un user control que no está disponible en una plataforma, pero el desarrollador lo usa, lo que va a pasar es que va a usar el control por defecto. Por ejemplo, si la galería de imágenes estuviera solo disponible para Android, y genero mi KB para iOS, lo que vería sería la galería en Android y una lista en iOS. Con respecto a los requerimientos, no se precisa mucho más que lo que se necesita para poder compilar en cada plataforma. En Android y BlackBerry se programa en Java, y si se quiere, la plataforma más complicada en este sentido es iOS que se requiere tener una Mac y se desarrolla en Objective-C. La implementación como decía depende de la plataforma, pero hay cosas que son comunes: en todos los casos un user control tiene que cumplir con una interfaz determinada e implementar ciertos métodos. Estos son los métodos que implementa el Star Rating en iOS, para que vean que no hay nada demasiado complicado. Les cuento como se lee cada declaración de método: el símbolo de menos al principio declara el método como un método de instancia, luego viene el tipo de retorno del método entre paréntesis, en este caso void. Lo que sigue es el nombre del método, y por último el parámetro, que se compone del tipo y del nombre. El primer método, loadEntityData, se llama cuando se le quiere setear el valor al control, el entity data que recibe por parámetro tiene el valor que se le debe asignar al control. Si el control es editable, cuando cambie el valor lo tiene que modificar en el entity data, para que se pueda salvar. Los otros tres son bastante descriptivos, se puede setear el control como solo de lectura o editable, se le puede agregar una clase del tema para cambiar el dibujado y se le avisa cuando debe cambiar de tamaño. En Android y BlackBerry los métodos que hay que implementar seguramente se llaman distinto, pero la complejidad es la misma. Si alguien quiere desarrollar un user control, hay información más detallada en el wiki de la comunidad.
- La distribución de los user controls para usarlos desde GeneXus, es exactamente igual que para los user controls web. Básicamente debajo de la instalación de GeneXus hay una carpeta UserControls, ahí se crea una carpeta nueva con el nombre del control y se copia la definición del user control, los archivos binarios o los fuentes según corresponda, y los archivos de recursos como por ejemplo imágenes que se precisen. Con eso, al darle F5 en GeneXus para ejecutar, si la aplicación usa el user control, se va a copiar todo lo necesario al proyecto y va a quedar incluido en la aplicación. Incluso más fácil, si el user control está en el marketplace de GeneXus, entonces ni siquiera necesitamos hacer la copia de la carpeta, se hace automáticamente desde el IDE cuando le pedimos que instale el control.
- Bien, veamos ahora los external objects, que permiten extender la interacción con los dispositivos.
- Igual que con los user controls, hay varios external objects que ya vienen con la funcionalidad estándar de GeneXus, pero que se desarrollaron usando los mismos mecanismos de extensibilidad que tienen ustedes disponibles. Ejemplos hay varios, el primero de ellos es la API de geolocation, que permite hacer cosas como obtener la ubicación actual, hacer un seguimiento de por donde pasa el usuario, o convertir una coordenada a una dirección (si es que existe) o al revés, de una dirección obtener las coordenadas. Otro ejemplo es el external object que permite interactuar con los contactos del dispositivo, que permite agregar, eliminar y ver información de un determinado contacto. También se tiene un external object para interactuar con la agenda del dispositivo, pudiendo agentar un evento en el calendario. ¿Qué tipo de cosas podría querer agregar usando este esquema? Bueno, se me ocurre por ejemplo, si tengo un aparato que se conecta al dispositivo que lea la presión sanguínea, podría desarrollar un external object para interactuar con esto y poder leer los datos.
- Los external objects en la versión beta 4 que se está liberando ahora, están un poco más verdes que los user controls. El proceso para integrarlos a GeneXus no está tan automatizado como con los user controls. De todas formas, la idea es que para la versión release sea igual de fácil que para los user controls.
- Los pasos para hacer un external object son a grandes rasgos los mismos que para un user control: se tiene una definición, luego una etapa de implementación, y por último está la etapa donde se distribuye el external object para usarlo con GeneXus. Lo que sí cambia un poco es lo que hay que hacer en cada uno de estos pasos.
- Vamos a ver un ejemplo. Para desarrollar un external object, lo primero es crearlo en GeneXus. Esto se hace como con cualquier otro objeto. En la definición del external object se le dice qué métodos va a tener y los parámetros del mismo. Acá en la foto estamos viendo el external object AddressBook que comentaba antes, que tiene tres métodos: AddContact, RemoveContact y ViewContact. Luego que se tiene esta definición, se debe hacer la implementación, que tiene los mismos requisitos que para desarrollar user controls. Acá se ve como es la declaración de los métodos en Android. Explico un poco lo que estamos viendo: el «public static» quiere decir que son métodos de clase públicos, luego viene el tipo de datos de retorno, en este caso boolean, luego el nombre del método que en este caso coincide con los nombres en el external object, pero no es estrictamente necesario, porque se hace un mapeo entre los nombres del external object y la implementación, y luego los parámetros que si se fijan, salvo un «context» por ahí, son los mismos que se tienen en la definición del external object. El «context» es información de contexto que se le pasa al método y que podría llegar a necesitar. Por último debería venir la etapa de distribución, que hoy en día en la beta 4 es manual, no está automatizado como para los user controls. Para la versión release sí va a ser automático igual que para los user controls.
- Bueno, eso era lo que quería contarles. Para cerrar con el eslogan del evento les digo que es fácil, usen las extensiones disponibles, desarrollen extensiones nuevas. Las extensiones que hagamos nosotros seguramente van a ir incluidas con las clases estándar. Las de terceros las van a encontrar seguramente en el marketplace. Y para los que vayan a desarrollar extensiones para los generadores, hay más información en este link que les dejo, pueden consultar en los foros, y si alguien se va a meter con este tema quedo a disposición para ayudar en lo que pueda.
- Muchas gracias. No se si hay alguna pregunta, si no cualquier cosa me preguntan ahora a la salida o si no por mail.