Miércoles 3 de octubre de 2012 17:33

Continuando con lo que comentábamos el lunes de la semana pasada, he estado dándole vueltas a la actividad de gestión de sorteos. La primera idea es la siguiente:

La idea es que una primera actividad de acceso a una actividad de segundo nivel en forma de tab que nos permita desplazarnos por Lista de participantes <-> Log de sorteo <-> CRUD.

No lo he visto claro por varios motivos

1. Cada vez que queremos seleccionar un sorteo nuevo debemos irnos a la actividad superior, acción que es un poco coñazo. No seria muy problemático por que IF no esta pensado ( o yo no lo pienso) para que una sola persona gestione en su terminal muchos sorteos.
2. El mantenimiento de los sorteos, es algo general y no asociado a ninguno de ellos, y por lo tanto no tiene por que caer debajo de la actividad de la selección del sorteo, lo que me obligaría a sacarlo fuera.

Lunes 1 de octubre de 2012 12:30

Hoy me he parado un poquito a pensar sobre la gestión de los sorteos. Como funcionalidad a implementar estoy considerando:

• Baja de sorteos, para poder lanzar de nuevo un sorteo en caso necesario.
• Acceso a los participantes de un sorteo realizado a modo informativo.
• Acceso a las re-notificaciones por participante de un sorteo, por si las moscas tenemos algún despistado que ha borrado la notificación.
• Y no se si algún tipo de log, accesible mediante algún tipo de elemento de seguridad, para que los participantes puedan consultar su AI en el propio terminal.

Sobre la lista de bug identificados, ya era hora de hacer una limpia. Aquí esta la lista actualizada:

Lunes 24 de septiembre de 2012 17:00

Continuando con el asunto, esta semana he estado trabajando en el sorteo. Como ya comenté hace varios días  el frontal para la realización del sorteo quedó concluido. He estado liado con el asunto de las notificaciones. Uno de los principales problemas con los que me he encontrado con respecto a las notificaciones por correo-e es la siguiente. Yo envio la notificación y apunto dicho envio en la tabla designada al respecto. Ahora bien, si nos paramos a pensar un poco, entre que yo indico al sistema que envíe las notificaciones y el momento en el que realmente se envían puede pasar o no un rato, pero el apunte del envio ya esta hecho en la bbdd. El problema ha sido ¿como logro que el sistema me avise cuando terminen los intentos de envio de las notificaciones?¿como hago para actualizar el estado de los apuntes que ya he realizado en el modelo de datos?. Bueno pues ya lo he solucionado. La solución a grandes rasgos ha sido la siguiente:

• Implementado el envío de mensajes mediante una tarea asíncrona.
• Cada una de las notificaciones por email las lanzó en una de estas tareas y en ese momento apunto dicha notificación en la bbdd.
• Cuando la tarea finaliza la labor programada valida su retorno y en base al mismo si ha habido algun error actualiza el modelo de datos en consecuencia. Esto lo he realizado en onPostExecute().

Lunes 17 de septiembre de 2012 17:00

Continuamos con el desarrollo. La semana pasada había identificado un nuevo campo en la tabla de contactos. Error mio no haberlo llevado a la tabla de participantes, concretamente a la de la relación. El modelo de bbdd a fecha de hoy queda como sigue: Ya he modificado los DAOs correspondientes y la capa de servicios. En cuanto a la actividad del sorteo estoy con ella. La lógica necesaria para la realización de los sorteos ya la tengo implementada, incluso con su persistencia. Lo que me falta de esta capa es:

• Uso del subsistema de mails que ya tengo implementado (gmail)
  • En este caso me faltan un par de cosas mas:
  • Cifrado de los datos de la cuenta que usa la aplicación para el almacén de esa información.
  • Sistema de preferencias o similar para dar de alta dichos datos.
• Uso del subsistema de SMS que me falta por mirar e implementar.

Viernes 14 de septiembre de 2012 17:00

Continuamos con las labores de IF. Hoy he realizado las modificaciones necesarias en el desarrollo para que la actividad principal controle cuando debe habilitar el acceso a las distintas funcionalidades de la aplicación. Estos asuntos los teníamos además desde hace bastante tiempo en la lista de pendientes. En concreto ahora la actividad realiza dos validaciones antes de renderizarse:

• Si existen grupos válidos (con miembros) en el sistema habilita el acceso a la gestión de eventos. En otro caso deshabilita dicha funcionalidad, no permitiendo al usuario el acceso a la misma.
• Si no existen eventos válidos (no sorteados) en el sistema la aplicación deshabilita la funcionalidad de sorteo, no permitiendo el acceso a la misma.

Una vez se da de alta un grupo con participantes la actividad principal modifica en tiempo de ejecución el acceso a la funcionalidad de eventos, lo mismo que sucede con el binomio eventos/sorteos:   Cambiando un poco de tercio, arrastraba un problema desde el inicio que he solventado hoy. El problema es que levanto las formas de contacto de cada uno de los contactos como texto, y tal cual las selecciona el usuario las persistía. El problema surge a la hora de notificar a los participantes una vez realizado el sorteo. Si solo apunto la forma de contacto, sin apuntar su tipo (sms o mail), cuando me pongo a notificar tengo que parsear ese texto para concluir el tipo de la forma de contacto. Pensando en este asunto, parece claro que si estoy accediendo a la lista de teléfonos para conseguir los numeros de movil y a la lista de direcciones de mail para conseguirlas, pues a la vez que levanto esa informacion podria levantar el tipo. De esta forma he creado una clase denominada FormasContacto que encapsula tanto la forma de contacto propiamente dicha como el tipo. De esta forma la capa de DAOs y por supuesto la capa de servicios dejan de «mover» Strings para comenzar a mover FormasContacto. Ya he realizado la modificación pertinente en el desarrollo y ya lo tengo funcionando. Para poderlo llevar a cabo he tenido que realizar una pequeña modificación en el modelo de datos. Se ha agregado el tipo de la forma de contacto en la tabla de contactos y ya se han realizado todas las modificaciones en las capas tanto de negocio como de servicios y de acceso a datos. El modelo de datos a fecha 14 de Septiembre de 2012 es el siguiente:  

Miércoles 12 de septiembre de 2012 17:00

Sobre las notas de ayer paso a explicar un poco el formulario. Hay veces que de las notas rápidas que hago ni yo las entiendo. El formulario tiene como objetivo la ejecución de la lógica necesaria para la realización del sorteo propiamente dicho. Para ello lo único que nos hace falta es el evento que queremos sortear. Por supuesto si un evento ya ha sido sorteado, no debiera aparecer como seleccionable en el formulario. Por otra parte, si no existen eventos creados en la aplicación susceptibles de sorteo, tampoco se debiera poder entrar en el formulario. Lo que muestra la hoja de notas de ayer es simplemente un spinner en la parte superior para seleccionar el evento a sortear, y un botón que lanza dicho sorteo, poco mas tiene el formulario. Realmente este formulario tiene mas lógica de negocio que UI. El formulario es el siguiente:

Martes 11 de septiembre de 2012 17:00

Volvamos al asunto de la interfaz que nos falta por definir para el caso de uso de realización de los sorteos, en concreto y usando la numeración definida el caso de uso CU03_01 Realizar sorteo. Tal y como indique en post anteriores, habia decidido separar esta funcionalidad de la de histórico, respetando de esta forma la definición inicial de casos de uso, aunque para el usuario pueda ser mas engorroso a nivel de gestión de formularios. La primera idea sobre este formulario es la siguiente:

Martes 3 de julio de 2012 02:35

Volvemos a la carga con el asunto. Hoy he continuado con la capa de los DAOs de las nuevas entidades de bbdd identificadas la semana pasada. Parece que ya tengo la primera implementación de los mismos completa, a falta de ir tirando lineas de las capas superiores para ir completando algún método faltante. El siguiente paso sera ponerme ya con las actividades e iré completando implementación hacia capas inferiores. Por otro lado, como ya comenté la semana pasada, había estado trabajando en el envío de mails desde el terminal. Esto fue el 20 de junio pasado. La cosa es que lo había dejado funcionando en el emulador, que actualmente lo tengo ejecutando Android 2.3. Hace unos días me dio por probar la funcionalidad desde mi flamante S2, que está ejecutando Android 4.0.1. Curioso fue cuando probando el envío de dichos mensajes la aplicación daba un error y se cerraba. El problema es que ejecutando en mi terminal no puedo depurar la aplicación, así que por aquel entonces lo dejé así. Hoy he retomado el asunto preparando un emulador con Android 4.0.3 para intentar reproducir el error. Efectivamente es un «problema» con Android, nuevas versiones incorporan nuevos controles de cara a desarrollo, me explico: En Android todas las llamadas y los ciclos de eventos tienen habitualmente lugar en el hilo principal «UI thread» dicho de otra forma, en la zona en la que se controla la interfaz de usuario. Este comportamiento realmente funciona casi siempre correctamente. La gente de google que la verdad es que son unos putos cracks le han dado una vuelta de tuerca y con razón. ¿Que pasaria si en ese hilo principal intentamos enviar un mail por ejemplo?¿o que pasaria si en ese mismo hilo nos ponemos a mover una animación?…Pues el problema es que el frontal de la aplicación pierde la agilidad que Google busca en los dispositivos. El ejemplo del mail es muy claro, tal y como funciona el asunto de las comunicaciones, es posible que a la hora de enviar el mail nos encontremos con multitud de problemas, a saber, no estamos conectados, no tenemos contacto con el proveedor del servicio, la red va lenta, en fin, como podéis ver un sin fin de posibilidades que harían que la aplicación dejase de responder muy posiblemente. Volviendo a mi problema, como digo hace un par de semanas, con el objeto de probar el codigo de envio del mail inclui dicho envio en un boton de la interfaz. El código de dicha funcionalidad era el siguiente:

imgbtn_Sorteo.setOnClickListener(new OnClickListener() {
 @Override public void onClick(View v) {
  MailSender ms = new MailSender();
  String[] destinos = {"emierp@gmail.com"};
  try {
    ms.SendMail("emierp@gmail.com", "xxxxxxxxxxxx", destinos, "Mail de IF v1.0", "Prueba de envio de mail");
  } catch (SendMailException e) { e.printStackTrace(); } } });

Fijaos que efectivamente en mi caso el envío de mail se realiza de forma síncrona desde el hilo principal de la aplicación. Es por ello que en Android 2.3 funciona sin problema al no incorporar dichas validaciones y en Android 4 no lo hace. A modo de cultura general estas validaciones Google las ha denominado modo estricto (StricMode) y se pueden habilitar o deshabilitar mediante código. Ya para concluir simplemente comentaros un par de cosas adicionales.

1. He incluido enlaces de interés respecto al modo estricto al final de la página, donde siempre.
2. La solución que le he dado para IF v1 ha sido embeber el envío del mal en una tarea asíncrona que lanzo desde el botón anterior, de momento para las pruebas es suficiente.
3. El casquetazo que me escupía IF al intentar ejecutar la aplicación en Android 4 era este:

WARN/System.err(390):android.os.NetworkOnMainThreadException</code> <code>WARN/System.err(390):at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(StrictMode.java:1069)...

Sábado 23 de junio de 2012 23:45

Hola a todos de nuevo. Ayer comencé el desarrollo de la capa de DAOs de las nuevas entidades identificadas. Cuando llegue a la zona de participantes del sorteo, pensando encontré un pequeño inconveniente en la estructura de la bbdd. Hoy he revisado la estructura de las tablas y el modelo a fecha de hoy queda como sigue:   A grandes rasgos cabe destacar las siguientes características incorporadas:

• En un futuro, un participante común a varios sorteos va a poder contar para cada uno de ellos con una forma de contacto distinta. En IF v 1 esto no será así, puesto que es una limitación ya indicada en la zona de los contactos de la agenda. Esto no quita para que ya que me he puesto, dejé el modelo de datos preparado para la ocasión.
• Ahora con la nueva estructura, cada participante común a varios sorteos puede tener para cada uno de ellos un amigo invisible distinto sin duplicar la información (tupla) en la tabla de Participante.

Jueves 21 de junio de 2012 23:45

Hoy no me apetece ponerme a tirar líneas. Me queda todavía casi toda la capa DAO por hacer, así que voy a actualizar el diagrama de arquitectura de la aplicación. Lo tenéis a continuación:

Miércoles 20 de junio de 2012 23:00

Estoy avanzando en el desarrollo, ya me he picado las entidades nuevas identificadas en la capa de negocio. Ahora me he liado con las interfaces de los DAOS y un poco mas tarde a ver si me da tiempo a picarme algunos DAOS. La capas de la aplicación quedan por el momento del siguiente modo: Si esta noche Google Docs me lo permite actualizare el gráfico de arquitectura…pero no se si podré por que ahora mismo me esta dando un error y no me permite abrir el gráfico.

Miércoles 20 de junio de 2012 22:00

Bueno, la situación de IF tal y como la deje es que el sistema esta listo para realizar el sorteo. Es en el propio proceso de la realización del sorteo donde debemos poblar las tablas que definimos y modelamos la semana pasada, me refiero a las tablas de sorteos, notificaciones y participantes de sorteo. Le he estado dando una vuelta a las definiciones que había hecho en UML para intentar mezclar en una sola actividad la funcionalidad de la realización del sorteo junto con la funcionalidad de consulta de históricos. No he encontrado una solución que me satisfaga, debe ser debido a que no estoy muy ducho con los interfaces de usuario. Por lo tanto voy a dividir la lógica, tal y como se había planteado en los modelos de Casos de Uso. En la pantalla principal de la aplicación voy a habilitar una imagen para la realización de los sorteos y otro imagen distinta para la consulta de los históricos. Por otro lado y sabiendo que debía avanzar en el asunto de las comunicaciones, he avanzado sobre la funcionalidad de envío de mails desde la aplicación. Me parece cuanto menos curioso que en Android no exista un servicio para realizar este tipo de comunicación sin usar la actividad por definida en el sistema. Como recordatorio cuando se lanza el sorteo, los participantes en los que el método de contacto elegido ha sido email deben ser informados mediante este medio, pero no tiene sentido abrir la actividad de mail del terminal para que el usuario de IF tenga que lanzar los mails de forma individual. Bueno, buscando, buscando, he encontrado una solución basada en una portabilidad de javamail a Android. Tenéis el enlace al final de esta mega página. Ya he realizado la codificación usando la librería y la tengo funcionando, solo me queda organizarlo un poco.

Lunes 18 de junio de 2012 02:08

Acabo de terminar el HelperSQL que tengo implementado en IF. Ya le he agregado todas las tablas que hasta el momento tengo identificadas. Si alguien esta interesado en usarlo como ejemplo para sus desarrollos lo podéis descargar desde aquí [download id=»46″].

Lunes 18 de junio de 2012 01:19

Hola a todos de nuevo. Bueno pues proseguimos con el desarrollo, a ver si me da tiempo a tenerlo listo antes de navidad….jajaja, no se a que me suena esto. Bueno acabo de revisar un poco el esquema de la bbdd, para homogeneizar un pelín los nombres de las claves que habíamos visto en la versión anterior. El nuevo esquema relacionado con la funcionalidad que resta por implementar es este: A continuación me he puesto a agregar a las clases de utilidad los nuevos atributos de acceso a las tablas y a modificar la clase SQLHelper implementada en IF para que ya construya las nuevas tablas identificadas. Espero tener disponibles estas clases esta misma noche. Para la gente que este peleándose con Android, publicare el SQLHelper para que lo pueda tomar como base en sus desarrollos, espero que sea de vuestro interés- Un saludete a todos.

Martes 22 de mayo de 2012 00:05

Hola a todos de nuevo. Perdonad por que tengo este desarrollo un poco abandonado. La verdad es que llevo un par de meses que entre el trabajo y un par de cursos que he estado haciendo no tengo tiempo para continuar con IF. Estoy terminando el segundo de los cursos de título «Ingeniería de aplicaciones Web», solo me faltan dos semanas mas y concluyo. Espero para entonces poder retomar IF en el estado en el que lo deje. Si no me surge ninguna incidencia adicional y si Guild Wars 2 no sale hasta dentro de unos meses, espero que IF esté disponible para que este año podamos, por lo menos yo, hacer el sorteo con la aplicación. Un saludete a todos.

Jueves 29 de marzo de 2012 21:55

Hoy vamos a frenar un poquito con el asunto del desarrollo, porque en un proyecto de software no todo lo que debemos hacer es tirar líneas como tontos. Voy a aprovechar la huelga de hoy para yo poder hacer huelga  a nivel de implementación y vamos a pararnos un poco a pensar mas a nivel funcional. El último y único diagrama de casos de uso que existe en el log de desarrollo de IF es realmente un poco guarro, así que voy a aprovechar hoy para avanzar un poco en esta tarea no menos importante que la propia implementación:

Nueva versión de casos de uso IF

• Diagrama de casos de uso de primer nivel:

• CU01 Gestión de eventos en IF
• CU01 Primer nivel

• CU01_01 Alta evento

• CU01_02 Baja evento

• CU01_03 Modificar evento

• CU01_04 Selección grupo asociado

• CU02 Gestión de grupos IF

• CU02_01 Alta grupo

• CU02_02 Baja grupo

• CU02_03 Gestión contactos (Conceptual)
• CU02_04 Agregar contacto

• CU02_05 Selección contacto agenda

• CU02_06 Seleccionar forma contacto

• CU02_07 Borrar contacto

• CU02_08 Modificación grupo
• CU03 Sorteos

• CU03 Primer nivel

• CU03 _01 Realizar sorteo

• CU03 _02 Consulta datos propios sorteo (para v2)
• CU03 _03 Consulta sorteo (Conceptual)
• CU03 _04 Consulta datos generales

• CU03 _05 Consulta participantes

• CU03 _06 Renotificar participante

• CU04 Notificaciones

• CU04 Primer nivel

• CU04_01 Notificación
• CU04_02 Notificación mail
• CU04_03 Notificación sms

Martes 27 de marzo de 2012 23:55

Pues por aqui sigo dedicando al proyecto el tiempo que puedo. Hoy me he puesto  a pensar sobre la funcionalidad que me gustaria ver en la parte relacionada a los sorteos. Las funcionalidades son:

• Deseo un formulario donde poder consultar la información general de cada uno de los sorteos realizados en mi terminal.
• Información general se refiere a:
  • Datos generales del sorteo (evento sorteado, fecha de realización del sorteo).
  • Lista de participantes usados en el sorteo, a ser posible con la información utilizada en el mismo.
  • Posibilidad dentro de esta misma pantalla de re notificar a uno de los participantes. Todos tenemos el típico amigo/familiar despistado.

Martes 20 de marzo de 2012 23:55

La curiosidad podia conmigo y no me dejaba pegar ojo…jajajaja, ¿funcionara mi querido IF en ICS?….primeras imagenes corriendo sin problema en ICS…..ni una sola linea de codigo he tenido que modificar…. Pantalla de inicio Creación de grupos Contactos de grupos     Y eventos

Lunes 19 de marzo de 2012 00:30

Hola a todos de nuevo. Hoy no tengo muchas ganas de trabajar, así que me he sentado a solucionar alguno de los problemas que tenía pendientes. Hoy he modificado la actividad de eventos de forma que solo se muestran en la actividad aquellos grupos que tienen contactos asociados. Hasta el día de hoy en la actividad de eventos salían todos los grupos.

Martes 14 de marzo de 2012 00:40

Por aquí andamos de nuevo al ataque….ya nos queda poco para poder cerrar la aplicación. Concretamente lo que falta es el asunto de los sorteos. En este caso la lógica necesaria para el sorteo se podria considerar una chorrada y realmente si nos paramos a pensarlo lo es claramente. ¿Que tenemos que hacer?…mezclar una serie de contactos y asociarlos de alguna forma entre ellos de manera que quede montado el amigo invisible. Bien, pues avanzando el modelo de datos hoy llego al siguiente esquema: La tabla Sorteo es clara, es una tabla que va a almacenar los sorteos realiazados en el terminal. El dato mas importante es la fecha de realizacion y por supuesto el enlace del propio sorteo con el evento relacionado. La tabla de notificaciones: bueno, la funcionalidad de la notificación consiste en el envio de un mail o bien un sms a cada uno de los contactos que existe en el grupo relacionado con el evento del sorteo. Esta información se almacena en esta tabla con el objeto que si en el futuro cercano el administrador desea validar los datos enviados por el terminal, pueda hacerlo. La tabla de histórico es simplemente un registro de las operaciones realizadas por la actividad del sorteo durante el mismo, dicho de otra forma, un simple log interno de la aplicación.   Ya se que he estado unos días al margen del desarrollo, pero estoy haciendo a la vez un curso de Python y la verdad es que me deja poco tiempo….Un saludo y hasta la próxima. (Por cierto ya tengo pensado el siguiente proyecto Android…jajajaja, me da un ataque a la patata…! no tengo manos ¡)

Martes 6 de marzo de 2012 00:00

Hola de nuevo. A medida que nos metemos en harina salen cosas, muchas cosas. Hoy retomo el asunto de la documentación. Por el momento no he tenido tiempo de actualizar los diagramas mas formales de la aplicación, ya lo haré. Hoy traigo bajo el brazo el gráfico de arquitectura revisado. Entre las novedades que introduzco en esta versión podemos encontrar:

1. Como podréis apreciar en la capa intermedia aparece un nuevo elemento denominado Controles personalizados. Este elemento de arquitectura aparece debido a la necesidad que tengo de crear componentes personalizados para mi aplicación. Por el momento solo tengo 2, uno de ellos es el control que vimos en su día relativo a los grupos, y el otro es un checkbox extendido. Supongo que a medida que crezca la aplicación, estos controles se irán extendiendo. De hecho todavía le estoy dando vueltas a la cabeza para poder generalizarlos lo máximo posible.
2. El segundo de los puntos importantes son los cambios realizados en la capa de persistencia. Inicialmente una simple capa de DAO fué lo que pensé. El problema es que a medida que he ido avanzando con el desarrollo esta capa ha ido tomando cierto peso de negocio y la verdad es que no me gustaba la pinta que esta tomando. Esta misma semana he decidido descomponer en dos capas distintas la persistencia.
   1. Primera capa de servicios: el objetivo principal de esta capa es gestionar el acceso a los datos incluyendo la lógica necesaria para llevar a buen termino ese acceso. Por ejemplo, esta capa es la que valida que para borrar un grupo no existe un evento que lo tenga relacionado. Una vez que ha realizado las verificaciones pertinentes, procede con una simple llamada a la capa inferior (DAO).
   2. Capa de DAOs puros: el objetivo principal de esta capa es el acceso al dato propiamente dicho. Sin mas, sin lógica y sin dependencias.

Con respecto a los desarrollos que tenia pendientes, los terminé ayer por la noche. Ahora al borrar un grupo, se hace una validación para cada uno de los contactos del grupo. En el caso de que sean contactos huérfanos se eliminan de la tabla de contactos de IF. Por otro lado, la aplicación, a la hora de seleccionar un contacto de la agenda, elimina de la lista aquellos contactos que ya tenemos en el grupo. Ambas funcionalidades las deje hechas ayer. La última versión de IF la tenéis disponible aquí [download id=»44″]

Domingo 4 de marzo de 2012 23:00

Como ya he comentado, he medio terminado la parte de contactos de grupos. Aqui podeis apreciar la bbdd de SQLite que da soporte al desarrollo en su estado actual: Ahora me voy a poner un rato con el asunto del borrado de grupos, a ver si con suerte lo puedo dejar acabado.

Sábado 3 de marzo de 2012 23:00

Aquí tenéis la versión actual de IF para quien la quiera ir viendo. Por supuesto que todos aquellos que la probéis podéis ir indicándome cómo veis el asunto. Admito sugerencias, petición de nuevas funcionalidades o mejoras de las existentes, en fin, que ya que nos ponemos escucho todo lo que me tengáis que decir. La descarga desde aquí [download id=»43″]

Sábado 3 de marzo de 2012 01:23

Después de unos días de trabajo, he terminado la gestión de contactos para los grupos. Me faltan por cerrar ciertos detalles, sobre todo lo relacionado con integridad referencial  a nivel de datos. Como ya supongo que sabreis, SQLite no gestiona como debiera la integridad referencial. Como yo no estoy demasiado cómodo a nivel de triggers de bbdd decidi subir dichas validaciones a nivel de DAO. El asunto es que el control de la integridad del dato complica demasiado la capa DAO. Por otro lado, y en un alarde de gilipollez, pensé en dar un poco de lógica a la capa DAO, decisión que nunca debí tomar. Todo por ahorrarme una posible capa de servicios entre los DAO y las actividades. De momento lo voy a dejar así, pero en un futuro me va a tocar refactorizar todo el DAO. Aquí os dejo los mapas de las actividades que ya tengo listas:   Estos mismos gráficos los publico en pdf para que podáis echar un vistazo mas tranquilamente cuando queráis. La descarga la tenéis aquí [download id=»42″] En breve haré la actualización de los diagramas de arquitectura de la aplicación. A ver si el lunes puedo subir los nuevos con todas las actualizaciones realizadas y las nuevas entidades.

Martes 14 de febrero de 2012 23:20

Retomando el asunto de los contactos que comentábamos  a finales de Diciembre y en base al borrador de aquella época hoy dejo aquí un esquema no concluido del funcionamiento de los contactos. Hasta hoy he llegado a mostrar los contactos del terminal en la actividad correspondiente de gestion, dentro de la actividad de grupos:  

Tengo pendientes sobre esta nueva actividad un par de problemas que arrastro desde hace tiempo. El mas importante es el duplicado de las entradas debido al acceso raw del DAO. Debo darle una vuelta a ver como puedo de alguna forma unir los contactos para que no aparezca múltiples veces. Por otro lado, tal y como ya he comentado anteriormente, en esta actividad se selecciona un contacto y de forma automática se retorna a la anterior. Pienso que la actividad va a ser la primera que desarrolle con retorno de información a la actividad originante, concepto que aunque no es complicado, requiere remangarse y ponerse con ello. Ya veremos a ver cómo nos apañamos para retornar la información que considere pertinente.

Martes 14 de febrero de 2012 01:05

Hola de nuevo a todos. Ha pasado un mes desde mi última entrada relacionada con IF. Ya se que es demasiado tiempo, pero lo primero es el trabajo y luego el placer. Hoy he retomado el asunto. Los últimos días de Enero había detectado un pequeño problema en la capa de datos relacionado con la integridad referencial. Bien, después de leer un poco y realizar una serie de consultas a diversos compañeros, veo que SQLite no incorpora mecanismos de integridad de datos…por lo tanto nos toca hacerlo a nosotros. He implementado integridad de grupos en la capa DAO. Ahora el interfaz de GruposDAO queda del siguiente modo:

package com.eloymp.invisiblefriend.persistencia;
import java.sql.SQLIntegrityConstraintViolationException;
import java.util.ArrayList;import com.eloymp.invisiblefriend.excepcion.NoRecordFound;
import com.eloymp.invisiblefriend.negocio.Grupo;
public interface IOperacionesGrupoBBDD {
  public boolean anadirGrupo (String nombreGrupo);
  public boolean borrarGrupo (String nombreGrupo) throws SQLIntegrityConstraintViolationException;
  public boolean borrarGrupo (Integer idGrupo) throws SQLIntegrityConstraintViolationException;
  public boolean actualizaGrupo (String nombreGrupo, String nuevoNombre);
  public Grupo obtenerGrupo (String nombreGrupo);
  public Grupo obtenerGrupo (Integer idGrupo);
  public ArrayList obtenerGrupos () throws NoRecordFound;
}

Fijaos que ahora a la hora de borrar un grupo se valida que el mismo no exista en los eventos. La capa de DAO de eventos también ha sido actualizada quedando de la siguiente forma:

package com.eloymp.invisiblefriend.persistencia;
import java.util.ArrayList;
import java.util.Date;
import android.database.SQLException;
import com.eloymp.invisiblefriend.excepcion.NoRecordFound;
import com.eloymp.invisiblefriend.excepcion.RecordFound;
import com.eloymp.invisiblefriend.negocio.Evento;
import com.eloymp.invisiblefriend.negocio.Grupo;
public interface IOperacionesEventoBBDD {
  public boolean anadirEvento (String nombreEvento, String descripcion, Grupo grupoEvento, Integer cantidad, Date fechahora) throws SQLException;
  public boolean borrarEvento (String nombreEvento);
  public boolean borrarEvento (Integer idEvento);
  public boolean actualizaEvento (String nombreEvento, String descripcion, Grupo grupoEvento, Integer cantidad, Date fechahora);
  public Evento obtenerEvento (String nombreEvento);
  public Evento obtenerEvento (Integer idEvento); // Validación de que no existe un grupo en los eventos, para mantener IR
  public void noExisteGrupo (Integer idGrupo) throws NoRecordFound, RecordFound; public ArrayList obtenerEventos ();
}

Fijaos en el DAO de eventos que acabo de incluir que se ha añadido al mismo un método para la validación de grupos en los eventos. Método que es invocado desde el DAO de grupos para realizar el control. Del mismo modo ha sido modificado el interfaz gŕafico para que ahora haga el control antes de los borrados, no realizando la actualización de la interfaz si las operaciones de orden inferior no retornan el resultado esperado.