Jueves 12 de enero de 2011

Hola de nuevo a todos. Voy a pasar a contaros un poco donde me encuentro actualmente y hacia donde voy. Tambien creo que es un buen momento para mostrar algunos de los diagramas de análisis y diseño en los que estoy trabajando relacionados con el desarrollo. Como sabéis me he quedado desarrollando la parte de contactos. La idea es que desde la gestión de los grupos, de alguna forma, la aplicación enlace con los participantes (contactos). Inicialmente mi idea era proporcionar una doble funcionalidad, de forma que los participantes pudieran obtenerse tanto de la agenda del terminal como manualmente mediante la introducción de la información necesaria. La introducción manual del participante de momento la voy a aparcar hasta la V2 de IF. Bien, pues dicho lo dicho, me puse con el asunto de los contactos. El primer asunto a resolver es sobre la diferenciación entre dos entidades que parecen lo mismo pero que no lo son. Me refiero a las entidades que representan por un lado un contacto de un grupo dentro de IF y por otro un contacto con origen en el terminal (a traves del Proveedor de contenidos). Bien pues dicho y presentadas ambas entidades ya tengo medianamente terminada la capa de persistencia de ambas. Esta capa queda resuelta mediante dos nuevas clases con sus correspondientes Interfaces, que son:

      • ContactosDAO : capa de persistencia para los contactos de un grupo.
      • ContactosAgendaDAO : capa de persistencia para los contactos con origen en el terminal (Content Provider).
      • IOperacionesContactoDAO
      • IOperacionesContactoAgendaDAO
Por lo tanto y por el momento la capa de persistencia la tengo como a continuación podeis apreciar:

Actualmente, a parte de que estoy un poco off, tengo un inconveniente que no me ha dejado continuar al ritmo inicial. En inconveniente es que no termino de entender cómo recuperar cierta información de un contacto, en mi caso, necesito recuperar los datos (teléfonos moviles, direcciones de mail) de contacto de un contacto. De hecho la funcionalidad a implementar durante la seleccion de un contacto tiene que pasar por:

      1. Un contacto (futuro participante) solo aparece en la lista de contactos seleccionables si existe para él alguna forma de contacto válida.
      2. Una vez se selecciona un contacto, IF debe mostrar una lista donde el usuario pueda seleccionar la forma de contacto preferida para él, bien sea un teléfono móvil para el envío de un SMS o bien una dirección de mail para el envío del consiguiente correo. En cualquiera de los casos si el contacto tiene diversas posibilidades el sistema debe dar al usuario la posibilidad de seleccionarlo.
Para la implementación de esta funcionalidad estoy entrando por el proveedor de contenido, el que se supone que me da una entrada por cada uno de los contactos existentes, al margen de la información que tengan. El asunto es que por el momento no he encontrado la forma de navegar desde el contacto que ya recupero a sus datos de contacto, xD.
También he estado investigando el acceso RAW a los contactos, pero parece que esta pensado para operaciones a mas bajo nivel, y para IF no me gusta, así que de momento me voy a quedar con los proveedores.

Retomando un poco sobre el asunto de la arquitectura que vimos en su día cuando planteabamos el proyecto, quiero mostraros un ejemplo de aquella idea. En este diagrama podemos apreciar cómo estoy realizando el control desde la capa de presentacion hasta la capa de datos: Como podeis apreciar en este diagrama de secuencia las entidades que aparecen son:

      • act_Grupos: Act_Grupos -> Se corresponde con la propia actividad que muestra los grupos existentes y da acceso a las operaciones CRUD de los grupos
      • act_NuevoGripo: Act_NuevoGrupo -> Elemento de negocio que representa un grupo en IF
      • gruposDAO: GruposDAO -> Objeto/Clase ya perteneciente a la capa de persistencia de IF y que gestiona las operaciones físicas relacionadas con grupos.
      • objetosGlobales:ObjetosGlobales -> Clase global de apoyo.
Sobre el diagrama, una sola nota: La caja inferior que como podéis ver agrupa mensajes sobre lineas de vida se denomina Fragmento Combinado.

Jueves 5 de enero de 2011

Hola de nuevo, hoy no me voy a enrollar demasiado con el texto debido a que todavía no tengo lista toda la documentación e implementación que quiero subir de una tacada. Después de unos días liadete con la familia principalmente debido a las fiestas de navidad, hoy he sacado un rato y me he puesto de nuevo con el asunto. Hoy he dejado enlazada la actividad de grupos con la agenda del terminal. Por el momento no me ha dado tiempo a dejarlo del todo ajustado y ademas me faltan muchas funcionalidades relacionadas con la implementación en la que estoy trabajando, así que hoy no es buen día para subir nada. Esperaré a tener completa la implementación de los participantes para los grupos para subir una nueva versión de IF y nueva documentación técnica del desarrollo. Pienso que en un par de días podría tenerlo concluido el desarrollo y en unos días mas la documentación del mismo. Un saludo a todos y Feliz 2012.

Lunes 26/Martes 27 de diciembre de 2011 (Deprecated)

Bueno, pues hoy inauguro la lista de Bug Fixes identificados por mí. Justamente estaba esta mañana probando la pantalla de grupos y en una de las operaciones me he percatado de un problema, asi que nada, lo dejo solucionado y prosigo con el asunto de la asociación de contactos a los grupos:

      • id 1: 26 de diciembre de 2011.Descripción: Teniendo un grupo seleccionado en la actividad de gestión de grupos, si se selecciona el mismo grupo se produce un null pointer. Solución: no siempre existe un cliente para los eventos de los controles personalizados. Hay que validar que existe suscriptor antes del reenvío del evento. (Solucionado)
      • id 2: 14 de febrero de 2012. Descripción: Se puede eliminar un grupo existente en el sistema estando relacionado con un evento todavía existente. El problema es que después de dicha eliminación la actividad de gestión de eventos queda inservible debido al error de integridad producido. Solución: como sabéis, y si no lo sabéis yo os lo digo, SQLite no incorpora por el momento mecanismos automáticos de integridad, y por lo tanto hay que implementarlos. He implementado integridad a nivel de capa DAO. Para mas información podéis consultar la entrada del log de desarrollo de 14 de febrero de 2012. (Solucionado)
      • id 3: 3 de marzo de 2012. Descripción: Si en un grupo tenemos un contacto pepito y lo agregamos de nuevo, se produce una excepcion. Solución: En la lista de contactos de agenda solo deben aparecer los contactos no existentes ya en el grupo. (Solucionado)
      • id 4: 3 de marzo de 2012. Descripción: Si el nombre del contacto es muy largo, con el terminal en modo vertical se dejan de ver los iconos de la zona derecha del layout. En modo horizontal se soluciona si el nombre del contacto no es tan largo como para exceder la linea, en otro caso pasa lo mismo. Solución: Para nombres largos hay que hacer una especie de resumen algo así como NOMBRE_MUY_MUY_LARGO______…. (Investigar)
      • id 5: 3 de marzo de 2012. Descripción: El icono para añadir elementos en todos los layouts se desplaza a la derecha debido al contenido de los elementos inferiores. Debemos controlar los anchos máximos de las columnas de los mantenimientos. (Investigar)
      • id 6: 27 de septiembre de 2012. Descripción: Las fechas en los mensajes de notificación son incorrectas. Relacionado con id 8.
      • id 7: 01 de octubre de 2012. Descripción: En la actividad de gestión de eventos, el frontal permite el borrado de un evento aunque dicho evento haya ya sido sorteado. A bajo nivel el sistema esta funcionando correctamente por que el evento, aunque desaparece del interfaz, no se esta borrando de la bbdd. Por lo tanto hay que solucionar el control en dicho formulario.
      • id 8: 01 de octubre de 2012. Descripción: La grabación de la fecha de evento seleccionada por el usuario a la hora de la creación del mismo se realiza de forma incorrecta. Me he dado cuenta ahora en el momento de ver las notificaciones de las fechas de los mismos.
Al margen de la nueva lista, hoy de la que he pillado el lejanías he estado pensando un rato en el asunto de los contactos y su asociación a los grupos. La idea es aprovechar al máximo las actividades que ya tengo diseñadas por dos motivos principalmente:
  1. Dotar a la aplicación de un formato lo mas uniforme posible.
  2. Rehusar el código/conocimiento ya adquirido.
En este orden de cosas la primera de las ideas que me conseguido cerrar es la siguiente:
En la zona de la izquierda se puede apreciar la gestión de grupos, que ya esta completada. Esa gestión a través del icono correspondiente da acceso a la gestión de contactos para ese grupo (evento click del icono). La siguiente actividad presenta una estructura similar a las ya creadas. Mostrara una lista de los contactos de la agenda ya relacionados con el grupo. Para añadir un contacto al grupo, pulsaremos el signo + de la parte superior de la actividad lo que a su vez nos abrirá un listado de los contactos existentes para poder seleccionar otro que será agregado a la lista de contactos relacionados con el grupo. Se implementara al igual que en anteriores actividades el borrado en grupo e individual.
Con respecto a este planteamiento tengo un pequeño inconveniente, ¿que pasa si asigno contacto a un grupo y posteriormente vacío el teléfono y vuelvo a recuperar la agenda?…Bueno, no lo he probado de momento, pero supongo que los id de los contactos no tienen por que ser los mismos, así que a modo de historial seria interesante no solo guardar los id de los contactos relacionados, sino también su nombre completo y por lo menos la forma de contacto usada….bueno, esto lo dejo para mas adelante, por el momento me quiero centrar en las operaciones CRUD a este nivel. Bueno por si acaso, el problema y la solucion la dejo apuntada en la misma hoja…para acordarme para la version 2 de IF.

Como ya he comentado, y despues de solucionar los pequeños problemas encontrados, hoy comienzo con el asunto de la asignación de contactos a grupos….Voy a aprovechar para ir dejando el esquema de bbdd en el que estoy trabajando y que poco a poco ira tomando forma. Hoy he agregado la parte relativa a contactos de los grupos:   Ojo con las tablas por que para nosotros la importante es la de la relación entre grupos y contactos. La tabla de contactos, aunque la he dibujado en el esquema, no es nuestra responsabilidad. Esta tabla sera proporcionada por el sistema a través de un proveedor de contenidos. Yo la he dibujado para tener mas claro el modelo físico. Aquí os dejo el código relativo a la creación de la bbdd existente en el SQL Helper de la aplicación: String[] sqlCreate = new String[] { "CREATE TABLE Grupo (_id INTEGER PRIMARY KEY AUTOINCREMENT, nombre TEXT NOT NULL)", "CREATE TABLE Evento " + "(_id INTEGER PRIMARY KEY AUTOINCREMENT," + "nombreVisible TEXT NOT NULL, nombreInterno TEXT NOT NULL, descripcion TEXT," + "grupoid INTEGER REFERENCES Grupo(_id)," + "cantidad INTEGER NOT NULL," + "fechahora TEXT NOT NULL)", "CREATE TABLE Grupo_has_Contacto " + "(Grupo_id INTEGER NOT NULL REFERENCES Grupo(_id), Contacto_id INTEGER NOT NULL, " + " PRIMARY KEY (Grupo_id,Contacto_id))"}; Pues ya dicho esto, y preparadas las bases de las nuevas actividades, mañana continuaremos con la labor, si mi familia me lo permite, claro.

Martes 20/Miercoles 21 de diciembre de 2011

Tareas atacadas hoy:

      • Actualización de los DAOs de Grupos y de Eventos para el lanzamiento de excepciones en los métodos add. La antigua implementación usando los métodos insert () ha sido modificada para usar los métodos insertOrThrow () de forma que ahora se realiza un control de la inserción usando Excepciones.
      • Modificación de las clases cliente de los DAOs de Grupos y Eventos para el tratamiento correcto de las nuevas excepciones lanzadas por los DAO. Se ha eliminado la validación «guarrera» inicialmente planteada para dar paso a una nueva implementación en la que se captura y se tratan las posibles causas de excepción de los DAOs de orden inferior.
      • Validación del nuevo control de grupos.
Tareas pendientes:
  • Estudiar los ContentProvider para dar solución a la asignación de los contactos a los grupos
  • Definición de las interfaces de usuario anteriores
  • Revisión de la gestión de eventos. El alta de los campos date no se esta ejecutando correctamente.
  • Definición de la interfaz de usuario para la modificación de eventos.

Lunes 19/Martes 20 de diciembre de 2011

Después de unos días en los que no he podido dedicar nada de tiempo al asunto, hoy me he puesto de nuevo con el control personalizado. A falta de algunos detalles de usabilidad, parece que ha quedado funcionando. El control como entidad esta formado por:

  • Clase java
    • ExtEditText_Grupo.java: esta clase extiende de LinearLayout e incluye atributos privados para cada uno de los listeners a los que el cliente se puede suscribir para recibir los eventos.
  • InterfacesJava
    • OnCancelarListener: evento que genera el control cuando se pincha en el botón cancelar del mismo.
    • OnGrupoListener: evento que genera el control cuando se pincha en el texto del grupo que contiene.
    • OnSalvarListener: evento que genera el control cuando se pincha en el botón salvar del mismo.
  • Layout
    • extedittext_entidad.xml: esta claro que es el fichero xml que define el contenido gráfico del control.
  • Varios recursos gráficos: algunos iconos.

Desde un punto de vista técnico, dentro del control personalizado, lo unico que se hace es capturar el evento sobre uno de los elementos que contiene, y enviarlo de nuevo al objeto que esta esperando ese evento (observador). Por ejemplo en el caso de que el usuario haga click en el EditText de nombre de grupo que contiene el control, el control internamente lo que hace es:

nombreGrupo.setOnClickListener(new OnClickListener() {
/* (non-Javadoc) * @see android.view.View.OnClickListener#onClick(android.view.View)*/
  @Override public void onClick(View v) {onGrupoListener.OnGrupoListener();}
});

Por supuesto onGrupoListener no es mas que esto: private OnGrupoListener onGrupoListener = null; Y el detalle de la Interfaz OnGrupoListener es: package com.eloymp.invisiblefriend.controlespersonalizados.grupos; public interface OnGrupoListener { void OnGrupoListener(); } En cuanto a la funcionalidad implementada hasta el momento, aquí dejo un mapa de comportamiento del control. Como digo, muchos aspectos faltan por limar, pero poco a poco:   La versión de la aplicación a fecha de hoy la podeis descargar aquí (solo .apk) [download id=»39″]

Miercoles 14/Jueves 15 de diciembre de 2011

Supongo que no seré el único al que le pase….si soy el único por favor no dudéis en decírmelo para hacérmelo mirar lo antes posible, me pongo con una lista de pendientes como la que traía de la semana pasada (refactorización de la capa de DAO entre otras cosas) y viendo la aplicación me empiezan a rondar por la cabeza mil ideas sobre la misma y no puedo dejar de pensar en ellas por miedo posiblemente a perderlas…..esto debe ser lo que siente un músico o un escritor cuando le viene algo a la cabeza…en seguida se tiene que poner con ello, por que si se te va ya no vas a poder recuperarlo mas….bueno pues eso me pasa cuando me pongo manos a la obra. Intentaba comenzar con el asunto de la refactorizacion, pero me venia a la cabeza otro pendiente que me tiene loco, y es el asunto de las modificaciones de los nombres de los grupos ya creados y de los nombres de los eventos. No me ha quedado mas remedio que ponerme con ello, porque tuve una idea para simplificar esta operativa que no podia quitarmela de la chota…. Inicialmente el planteamiento que habia propuesto era el siguiente: Paso a explicar un poco el dibujo por que sino nadie se va a enterar excepto yo mismo:

  1. En la parte mas a la izquierda partimos de la actividad principal, que nos lleva a la actividad de gestión de los grupos.
  2. A continuación (centro) vemos la actividad de gestión de grupos tal y como se habia planteado inicialmente. Cada linea de detalle de la actividad da acceso tanto al borrado del grupo concreto, como a la modificación (icono intermedio) como a la gestión de los miembros (icono de la derecha). La gestión de miembros de momento no la tengo resuelta, de hecho no la tengo ni pensada. Con respecto a la modificación del grupo (nombre del grupo, se entiende), yo habia pensado inicialmente en una nueva actividad (la tenemos en la parte derecha del diagrama) que solicitase el nuevo nombre. Una vez el usuario introduce el nuevo nombre, actualizo la bbdd y salgo de la actividad de modificación del nombre de grupo y refresco la vista anterior.
Bien, hasta aquí la idea original, ahora lo que se me ocurrió. El esquema del nuevo diseño es el siguiente:
Paso a comentar el nuevo esquema:
  1. La idea es reconvertir lo que antes era un texto asociado a un checkbox a un campo de texto (EditText) y ademas asociados a ese texto un par de iconos, uno para guardar los cambios introducidos en el text y otro para cancelarlos y recuperar la informacion del grupo original.
  2. Por lo tanto el funcionamiento de esos elementos es:
    1. El nombre del grupo aparece en el campo editable. Cuando el usuario selecciona el campo y realiza alguna modificación, aparecen los iconos relacionados de salvar y cancelar.
    2. Si el usuario cambia el valor del nombre del grupo y salva, ocultamos los iconos y guardamos el cambio. La vista creo que no hay que refrescarla, por que la fila ya tiene la información actualizada (ya se vera por que no lo se).
    3. Si el usuario cancela con el icono asociado, se recupera el nombre del grupo en el campo de texto y se ocultan los iconos. Creo que tampoco seria necesario refrescar la vista
Bueno, el nuevo esquema tiene la ventaja de que en la misma actividad voy a poder hacerlo todo y ademas me ahorro la actividad del cambio de nombre que inicialmente había pensado.
En cuanto a las desventajas, pues hombre, el desarrollo se complica un poco, pero bueno, nada que no sea insalvable, pienso yo.
Por otro lado, se complica un poco mas, por que estoy realizando un componente personalizado que va implementar la lógica del texto y los iconos asociados. Ahora mismo estoy con el asunto y la verdad es que no tengo ni idea de cuanto tiempo me va a llevar. Pero bueno, como el componente ya lo tengo medianamente avanzado aunque solo sea a nivel de frontal, os puedo enseñar un poco la pinta que tendra el mantenimiento de los grupos en un futuro:

Todavía me queda mucho trabajo para cerrar el componente, así que las tareas que traía de la semena pasada, de momento las dejo apartadas hasta ver finalizado el componente.

Martes 13 de diciembre de 2011

Pequeña actualización del gráfico de arquitectura general de Invisible Friend:

Lunes 12 de diciembre de 2011

Bueno después de unos días de reposo obligado volvemos a la carga.Teníaa idea de ponerme a currar de nuevo el Viernes 9 pero mis hijos que llevan con catarro toda su vida, finalmente decidieron pasarme cada uno de ellos un catarro distinto y he estado jodido el fin de semana. Nada mejor que un poco de reposo para volver con ánimos renovados. Volviendo al asunto que dirige esta zona de la página, hoy me he sentado delante del PC con el firme propósito de escribir un poco de documentación técnica relativa a la situación actual del desarrollo. Como primer elemento me gustaria presentaros lo que es (lo que creo que será) a nivel general la arquitectura de la aplicacion: Las distintas zonas coloreadas del gráfico anterior son los distintos layers de Invisible Friend, que hasta el momento se corresponden con simples paquetes Java. La descripción de los paquetes es la siguiente:

  • Persistencia: todos los elementos relacionados con el acceso a los datos. posiblemente este paquete en un futuro se subdivida dependiendo de la naturaleza de esos elementos. Por ejemplo no es lo mismo el DAO de grupos que la clase auxiliar montada para la creación de la bbdd de la aplicación en el arranque de la misma. Una de estas entidades esta enfocada claramente a la solución de un problema de persistencia de la aplicacion y la otra es necesaria por la propia naturaleza del sistema donde reside.
  • Negocio: Paquete destinado a todas las entidades propias del negocio, por ejemplo grupos, sorteos, logs, eventos, etc.
  • Global: Paquete destinado a las clases de uso general o clases auxiliares.
  • Actividad: Paquete destinado a las clases que implementan la lógica de las actividades. Si el asunto se complica mucho posiblemente este paquete tambien sea un buen candidato a disgregarse en varios….tiempo al tiempo.
  • Res: Paquete del propio sistema. Sin comentarios y mostrados únicamente con el propósito de no olvidar que estamos desarrollando para Android.
    • Layout
    • Values
A nivel de depencias de paquetes el grafico queda de la siguiente forma:
Pues de momento asi esta el asunto. Para esta semana me gustaría comenzar a refactorizar la capa de DAOS, pues hasta el momento no he hecho uso de las excepciones y me gustaria controlar la ejecución con ellas. Por otro lado tengo que terminar tanto la modificación de los grupos como la de los eventos y a parte, el CRUD completo de eventos, pues la semana pasada solo deje funcionando el alta.
Si alguno de los lectores tiene algo que comentar sobre el asunto, pues nada, ya sabéis que estoy disponible para lo que queráis…..

Jueves 8 de diciembre de 2011

Estos días no me han sido demasiado productivos. Como ya comente hace unos días me puse con el DAO de los eventos y me falta probarlo. Una vez termine con el DAO me puse con las nuevas actividades de dichos eventos, el problema que he tenido es que me he encontrado con diversos controles que nunca habia manejado. Bueno despues de unos dias de lucha ya tengo por fin cerradas a nivel gŕafico las actividades nuevas y la navegación entre las mismas. Aqui dejo el mapa de actividades tal y como lo tengo a fecha de hoy: Hoy me gustaría enlazar la capa de actividades nueva con el acceso a datos, pero viendo la hora que es no se si me dará tiempo aunque solo sea por ver el alta….no se. Tengo otro problema pendiente en la actividad de nuevo evento, y es que he usado un Spinner a modo de combobox para cargar los grupos, ahora lo que me falta tambien es investigar a ver cómo voy a obtener el seleccionado dentro del spinner para a la hora de dar de alta el evento, asociarlo al grupo seleccionado. Una vez termine la interfaz básica de los eventos, pararé unos días, pues querría publicar algo de documentación de diseño de la aplicación, pero para ello, primero tengo que ponerme a actualizar la que tengo. Un rato mas tarde, 2:40 am… Bueno, parece que al final la noche me ha dado un respiro y me ha permitido acabar con el alta. Quedan muchas cosas que ver en detalle, por ejemplo el asunto de las fechas, que me esta guardando en bbdd lo que le da la gana…..menudo cachondeo tenemos. El diagrama de actividades hasta ahora queda de la siguiente forma: La aplicación a fecha de hoy la podéis descargar aquí [download id=»38″]. Esta versión solo contiene la gestión de grupos y la de eventos. Ojo con los eventos que solo he probado el alta y sin tocarle mucho las narices….

Lunes 5 de diciembre de 2011

Hoy he preparado el icono de la aplicación. Lo teneis en la parte superior de la página, a ver que os parece. Yo no soy muy ducho en estas cosas, vamos que tengo el gusto en el culo, asi que me he basado en una web de iconos gratuitos. He añadido un espacio en esta misma página para los enlaces que estoy usando, asi tambien es una forma de agradecer tanto la información obtenida como los recursos usados. Ayer deje prácticamente listo el DAO de los eventos, pero claro, solo a nivel de desarrollo. Cuando termine las actividades asociadas ya veremos a ver si funciona o no, xD, probablemente no….jajajaja. Bueno, por otro lado tengo pendiente una pequeña modificación del DAO de grupos que ya había acabado, y ademas terminar la funcionalidad de modificación de grupos…a ver esta noche cómo se nos da la cosa.

Domingo 4 de diciembre de 2011

Hoy voy a continuar con el desarrollo. Me parece que me voy a poner con la gestión de los eventos. Tengo pendiente el asunto de la gestión de los contactos de los grupos, pero antes de ponerme con el asunto me gustaría leer un poco más sobre los ContentProvider de Android, por que aunque ahora mismo tengo una ligera idea, quiero leer un poco mas para tenerlo un poco mas claro. Posiblemente en un par de semanas lo tenga claro como para proceder a la implementación.

Jueves 1 de diciembre de 2011

Hoy he llegado bastante cansado de trabajar y la verdad es que no he sacado tiempo para avanzar en el desarrollo.

Miercoles 30 de noviembre de 2011

Después de una noche muy productiva prácticamente he acabado con la gestión de grupos. Ya he conseguido que las altas y las bajas se reflejen de forma dinamica en el formulario. También me ha dado tiempo a programar las acciones de borrado en lote. El proyecto tal y como esta a fecha de hoy es el siguiente (solo .apk) InvisibleFriend 20111030 Aquí se pueden ver unas capturas de la aplicación en ejecución: Arriba a la izquierda el icono de la aplicación. Como se puede apreciar todavía no tengo un logo dibujado, pero ya lo tengo dando vueltas por la cabeza…Como tampoco soy demasiado aventajado con el programa de dibujo la verdad es que me da un poco de pereza ponerme con él. Por otro lado todavía me queda mucho trabajo duro por hacer, así que por el momento no le voy a prestar demasiada atención. La aplicacion en ejecución. Por el momento solo funciona la primera de las opciones, que es la de gestión de grupos: Si entramos en la gestion de grupos, el formulario sin ningún grupo creado presenta el siguiente aspecto. El signo + de la parte superior sirve para dar de alta un nuevo grupo. El icono de borrado de su derecha sirve para los borrados en lote. Layout de la aplicación en horizontal:

Lunes 28 de noviembre de 2011

Finalmente y después de dar solución al problema de la persistencia basada en un fichero .xml, y no estando conforme con la solución planteada, me decanto por reconducir el desarrollo usando una BBDD, en concreto la disponible en la plataforma Android SQLite. Me he picado una capa DAO para los grupos, por que por el momento no conozco ningún ORM. Por otro lado me he preparado una capa de utilidad….y he montado el SVN para controlar el desarrollo…..seguimos avanzando…

Miércoles 16 de noviembre de 2011

Después de leer y leer sobre asuntos de persistencia en Android, decido usar un fichero .xml como almacén de datos. Los problemas derivados de esta selección los podeis consultar en el artículo [intlink id=»2427″ type=»post»]siguiente[/intlink].

Lunes 14 de noviembre de 2011

Comienzo mi periplo por Android…

You must be logged in to post a comment.