Ir al contenido principal

Dos "tips" básicos prototipando para SD

Hay dos errores que he cometido varias veces cuando prototipo para SD (ios, android, bb): le erro de layout y me olvido del caché. La ultima vez me costaron algo de enojo y media hora de trabajo, así que, aunque son medio obvios, los escribo acá para no olvidarlos y por si le aporta a alguien.


Seleccionar el layout correcto


En Genexus Evolution 2 se pueden desarrollar aplicaciones para diferentes dispositivos (Teléfonos y Tablets), diferentes S.O. (android, IOS, BB), etc.

En este sentido se puede usar un layout comun que funcione sirva para todos o se pueden tener multiples layout (form), de modo de ajustar el mismo para cada plataforma (dispositivo, orientación, S.O, etc). Puede leer más aqui

En resumen: hay un layout "any platform" que aplica a cualquier plataforma que NO tenga un layout especifico definido. Así pues, si se está trabajando, por ejemplo, con Android y se tiene un layout especifico para el mismo, las modificaciones al "any platform" no aplicarán.

Moraleja: siempre revise que esté editando el layout correcto

Tip: si aparece el nombre del layout en "negritas" es que hay un layout definido para esa plataforma. En esta imagen se muestra que hay un layout especifico para Android y para IOS, no para BB:


Recuerde el caching


El caching es una feature notable. Ahora, cuando se está "prototipando" puede jugar malas pasadas porque se basa en "si los datos de la DB no cambian no se ejecuta el Data Provider que los retorna".

De este modo, si se modifica código que termina siendo un DP y los datos no cambiaron, ese DP no se ejecuta y por ende las modificaciones al código no se toman en cuenta.

En mi caso estaba cambiando la asignación a una variable, algo como:

Event Load
&ThumbVideoName=ArtistaVideo.VideoName
EndEvent

 

lo ejecutaba y la variable no se cargaba con el valor correcto.  El problema era que como no había modificado datos, el DP no era necesario ejecutarlo y la asignación no se producía.

Moraleja: si se está prototipando considere el caching, eventualmente apaguelo durante la prototipación.

Comentarios

Entradas más populares de este blog

Abrir links con aplicaciones nativas y no el browser (deeplinking)

El problema que tengo con algunas aplicaciones Android/iOS es que cuando recibo un link por algún medio (mail, tweet, etc) al abrirlo me lo abre con el browser, en lugar de abrirlo con una aplicación nativa asociada a ese “contenido”. Por ejemplo, si recibo un link a un tweet espero que lo abra con alguna aplicación de twitter que tenga instalada y no con el browser. De modo análogo si recibo un mail con una nota de prensa de un medio X y tengo la aplicación de ese medio X instalada, espero que el link lo abra con la aplicación nativa y no con el browser. Lo mismo quisiera con mi aplicación de "banking" o cualquiera que tenga instalada y sepa manejar ese "contenido" (link). Los motivos son bastante obvios pero los resumo en: la experiencia de usuario es mucho mejor en la aplicación nativa que en el navegador. Parte importante del tema es que el mismo link sea válido tanto para ver el contenido en el browser como para verlo en la aplicación, porque como prove

¡A la salud de mi KB!

Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud". En este sentido KBDoctor  es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB. También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices. A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server". En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".

Rocha:Constantes tipo fecha

En la Rocha se soportan constantes del tipo fecha o fecha-hora con formato ANSI/ISO (AAAA-MM-DD HH:MM:SS).  Tecnicamente (Sintáxis): <date>::=    [0-9]{1,4}"/"[0-9]{1,2}"/"[0-9]{1,2} | [0-9]{1,4}"."[0-9]{1,2}"."[0-9]{1,2} | [0-9]{1,4}"-"[0-9]{1,2}"-"[0-9]{1,2} <hms>::=    [0-9]{1,2}[ap] | [0-9]{1,2}":"[0-9]{1,2}[ap]? | [0-9]{1,2}":"[0-9]{1,2}":"[0-9]{1,2}[ap]? <constant> ::=   "#"<date>"#" | "#"<date> <hms>"#" | "#"<hms>"#" Funcionalmente Se pueden utilizar esas constantes en las reglas, eventos, propiedades, etc (todo lugar donde se utilice el parser): Algunos ejemplos básicos: &FechaInicial=#2007-01-01# &FechaHoraInicial=#07-1-1 11:15a# &HoraInicial=#11a# Me parece bueno no tener que escribir funciones (CTOD, TTOC) sobre constantes tipo char para lograr una fecha y mucho mejor aun en