Introducción

Este es otro proyecto realizado en HPRunner, pero orientado a utilizarse especialmente en móvil.

La idea, muy simple pero eficiente es de mi amigo Raúl Plaza y surgió de la forma más simple que paso a describir.

Somos un grupo de compeñeros que tomamos el desayuno juntos y en vez de pagar cada uno su desayuno decidimos que cada día paga uno el de todos.

Esto es muy habitual en España y sobre todo en Madrid, por lo que es muy usual el hecho de pagar «rondas». Según la RAE la rondas es «Invitación a comer o a beber que a su costa hace uno de los participantes en una reunión«.

Si en todas las ocasiones fuesemos el mismo número de compañeros, no se generaría ningún problema, pero por reuniones y otras actividades, no siempre es posible estar los mismos y de ahí surje la necesidad del aplicativo para tener en cuenta los días que eres invitado y los días e oinvotados que pagas.

Requisitos

Estos requisitos son muy generales y el aplicativo se puede adaptar a otros.

• Todos los participantes del grupo tienen acceso al aplicativo.
• El sistema debe de esttar preparado para más de un grupo. Por ejemplo, el grupo del desayuno, el de «las cañas de los viernes», etc.
• En principio todas las invitaciones de las rondas tienen el mismo valor.
• Sólo paga uno en cada ronda.
• Para que exista ronda debe haber al menos un invitado.
• Se debe orientar a funcionar en un Smartphone, aunque funcionará en calquier navegador.
• Las credenciales de cada usuario es a través de login y password.
• Al usuario se le identifica con una foto.

Decisiones técnicas

Está claro que los grupos de las rondas tienen un número distinto de miembros de ahí que las operaciones de creación y actualización de información es en múltiples registros.

Según es modelo de datos se aprecia de que por cada ronda existe:

• Un registro de qu_fecha que agrupa todos los registros de participantes del grupo qp_usuariofecha

Las validaciones de entrada de los datos de la reunión se deben hacer en el conjunto de todos los registros. Cómo se ha resuelto la entrada de los datos de Toma y Paga, a través de la funcionalidad de AJAX de actualizar un campo de tipo check, tenemos que esas operaciones a nivel de miembro son «atómicas» individualmente, por lo que cuando se da el botón de guardar a nivel del registro de qp_fecha es cuando se realizan las validaciones pero eso no impide que se salga sin pulsar ese botón.

Una nueva versión del aplicativo he conseguido -eliminando previamente la actualziación de los check con Ajax- poner el registro de fecha en Edición y todos los registros dependientes -hijos- «qp_usuariofecha» también en edit, por lo que el botón de «guardar» hace las actualizaciones de los registros dependientes a la vez y se pueden completar en ese momento todas las validaciones del conjunto de información.

Esto se hace con el código de javascript:

function OnPageLoad(pageObj,pageid,proxy,inlineRow)
…..
$(«input[id^=chooseAll]»).trigger(‘click’);
$(«#edit_selected2»).trigger(‘click’);

Lo que hace es la selección del check de «todos los registros dependientes» y después el hacer clic en el botón de «Edición».

Esta solución es muy potente y atractiva.

Imágenes de la aplicación

Cuando el usuario se conecta el sistema le facilita los grupos a los que pertenece y debe seleccionar uno mediante un clic en la imagen del grupo.

El resto de operaciones se realizará para ese grupo.

 

Al seleccionar el grupo o en cualquier consulta de saldo aparece todos los miembros del grupo -sus fotos- y el número de invitaciones que «deben» o han pagado de más.

Para registrar una nueva ronda sólo hay que hacer clic sobre cualquier foto de los miembros del grupo.

En esta consulta, el que sale primero en la lista es el que la aplicación ha seleccionado para que pague esta nueva ronda.