Propuesta Inicial del proyecto

Funcionalidad principal

Desarrollar una aplicación de fútbol basada en la Liga Española, donde los usuarios puedan crear sus propios equipos de fútbol virtuales con jugadores reales de la liga. Los equipos acumularán puntos basados en su desempeño en competiciones y torneos virtuales simulados. Además, la aplicación proporcionará actualizaciones en tiempo real de los partidos así como noticias relevantes, y permitirá la gestión de equipos en un mercado de fichajes virtual.

En este proyecto de desarrollo de una aplicación móvil, es importante destacar que no incluiremos requisitos relacionados con la necesidad de que la aplicación sea online ni cuente con funcionalidades de usuarios en línea. La razón principal es que actualmente no poseemos los conocimientos necesarios para llevar a cabo estas características y están fuera del alcance de este proyecto universitario. Tampoco las aprenderemos en ASEE, por lo que consideramos que está fuera de los límites.

Nuestro enfoque se centrará en crear una aplicación móvil sólida y eficiente dentro de nuestros límites de conocimiento técnico y recursos disponibles, pero resultará imposible implementar esas características.

Público objetivo

Aficionados al fútbol que desean combinar su pasión por el deporte con la toma de decisiones estratégicas, participando en una experiencia de juego que involucra crear y gestionar equipos virtuales basados en el rendimiento real de los jugadores en la Liga Española.

Target Potencial

Demografía:

• Edad: 18-45 años.
• Género: Todos los géneros.
• Ubicación: Global, con un enfoque en áreas donde la Liga Española tiene una fuerte presencia o seguimiento (España, Latinoamérica, etc.).
• Educación: Sin restricciones específicas.
• Ingresos: Desde bajos hasta altos, ya que la aplicación podría ofrecer diferentes niveles de participación (gratuita, premium, etc.).

Personalidad y Actitudes:

• Apasionados por el fútbol.
• Interesados en juegos estratégicos y de gestión.
• Competitivos y/o sociales en plataformas en línea.

Valores:

• Valoran la autenticidad (datos y estadísticas reales de jugadores y equipos).
• Buscan entretenimiento y engagement en sus actividades de ocio.

Estilo de Vida:

• Activos en redes sociales y comunidades en línea relacionadas con el fútbol y los juegos.
• Probablemente consumen contenido relacionado con el fútbol, como noticias, partidos en vivo, podcasts, y blogs.

Comportamiento:

• Usuarios activos durante la temporada de fútbol, posiblemente con picos de actividad durante eventos y partidos importantes.

Nombre de la app

Para nombrar la app se realizó un “brainstorming” por parte de todo el equipo en el que salieron propuestas como: Offside, BeFootball… y trás el cual se decidió que el nombre final de la aplicación será TuOnce ya que creemos que se adapta correctamente al propósito de la aplicación.

Diseño de la interfaz de usuario

El mapa de navegación de la aplicación se incluye en la entrega. Además, se incluye aquí una copia del mismo. Nuestra aplicación cuenta con una pantalla de login, desde la que se accede a la Home de la aplicación, donde se puede navegar con una bottom navigation bar a todas las secciones. La que aparece de primera pantalla en la Home es la de “Mis ligas”, pero con la bottom navigation bar nos podemos ir a cualquiera de las demás en todo momento. Tenemos algunas pantallas de item collection (como la de clasificación o la de plantilla, mercado u actividad), o dentro de la de equipo encontramos dos pestañas, en forma de navegación por tabs, para acceder a la alineación y a la plantilla del equipo. En el Mock-up a continuación se puede ver con detalle cada una de ellas.

Mapa de navegación de la aplicación

El mapa de navegación de la aplicación se incluye en la entrega. Además, se incluye aquí una copia del mismo. Nuestra aplicación cuenta con una pantalla de login, desde la que se accede a la Home de la aplicación, donde se puede navegar con una bottom navigation bar a todas las secciones. La que aparece de primera pantalla en la Home es la de “Mis ligas”, pero con la bottom navigation bar nos podemos ir a cualquiera de las demás en todo momento. Tenemos algunas pantallas de item collection (como la de clasificación o la de plantilla, mercado u actividad), o dentro de la de equipo encontramos dos pestañas, en forma de navegación por tabs, para acceder a la alineación y a la plantilla del equipo. En el Mock-up a continuación se puede ver con detalle cada una de ellas.

Mock-up de la aplicación

El Mock-up está disponible en formato PNG en la entrega, para verlo mejor que aquí incrustado. La pantalla principal es la de Login, y de ahí, como se ha comentado anteriormente, se va a “Mis ligas”, que dispone de la bottom navigation bar para acceder a cualquier punto de la aplicación.

Estado del proyecto en la reunión seguimiento y decisiones tomadas

En la propuesta de proyecto se nos dijo que la aplicación contaría con demasiados datos (muchas relaciones con claves externas en la base de datos, y por parte de GPS que eran demasiadas historias de usuario (27 frente al mínimo, que son 16). Los cambios realizados a la idea de la aplicación desde entonces, respecto a las historias de usuarios y las ramas son las siguientes:

• Al establecer un sistema de actualización continuo de la puntuación del usuario, se ajusta la descripción, indicando que la actualización de puntos solo ocurre después de ejecutar y simular la liga, por simplificar la gestión.
• Hemos modificado el Requisito 3 - Engagement del Usuario: Se elimina el sistema de notificaciones en tiempo real y se incorpora el uso de una ToolBar para mejorar la experiencia del usuario. Se detallan los cambios en las historias de usuario HU12 y HU13. Esto es así porque las notificaciones no las hemos visto en la asignatura hasta el momento de la implementación, por lo que es algo que cambia desde la propuesta de proyecto.
• Se actualizan las tareas relacionadas con la HU13, que se añade al sprint 4 junto con sus tareas para realizar toda la ToolBar de manera conjunta. La ToolBar se ha detallado más que en el mock-up porque no habíamos incluido en él las pantallas de configuración o settings, por lo que es una parte importante de la aplicación.
• e plantea la necesidad de conectar el equipo con el mercado para evitar que los jugadores salgan del mercado, lo cual no estaba reflejado en el mock-up.
• El hecho de que en la propuesta de proyecto quisiéramos crear ligas privadas lo hemos reemplazado por recibir noticias de la liga en la pantalla de actividades. Esto es así porque crear ligas privadas era algo demasiado grande (como se nos indicó al principio)
• Se establece una aclaración sobre la gestión de jugadores en el mercado y la simulación de los partidos en una pantalla preferencias, no incluida en la propuesta de proyecto ni en el mock-up.
• Hemos añadido varios filtros que no habíamos planeado en el mock-up ni en la propuesta: Filtrar por nombre de jugadores en el mercado, ordenar por puntuación en la plantilla u ordenar por precio de jugador, entre otras.

Resumen de las principales decisiones tomadas hasta aquí.

Como resumen, hemos implementado lo especificado en el product backlog (excepto las partes de pruebas y testing, que son de la segunda parte de la entrega). Además, hemos incluido otras funcionalidades que hemos ido necesitando o viendo interesantes para la aplicación, como una barra de búsqueda por nombre de los jugadores del mercado (lo cual no estaba en el mock-up ni en el product backlog), filtros varios del estilo del anterior y nuevas gestiones (en equipo y simulación de ligas en especial), como las posiciones de los jugadores del equipo (que no planificamos realizar) o la simulación inteligente de las jornadas de la liga teniendo en cuenta los 11 jugadores que el usuario ha elegido en su alineación. Por otra parte, también hemos eliminado otras tareas que no hemos podido implementar porque no se han visto en la asignatura, como un sistema de notificaciones en tiempo real. En general, no nos hemos salido de la planificación y hemos cumplido con la inmensa mayoría de los requisitos planificados e incluyendo otros nuevos. Las decisiones tomadas en el proyecto han seguido la planificación de GPS, en la que cada uno de nosotros se ha encargado de implementar sus tareas correspondientes en las ramas que se necesitan y hemos ido haciendo merges y pulls con develop para quedar ahí las últimas versiones de las ramas al terminar las historias de usuarios (que cuentan con las tareas de varios de nosotros).

Breve revisión de las principales características del proyecto final.

Este documento ofrece un análisis detallado de todas las características implementadas en el proyecto originalmente propuesto. La aplicación en cuestión es una simulación interactiva de fútbol, tomando inspiración de la conocida plataforma "Fantasy Football." Su enfoque se concentra en la Liga Española, brindando a los usuarios la capacidad de crear y gestionar sus equipos virtuales, compuestos por jugadores reales de esta liga. El objetivo principal es fusionar la emoción del fútbol real con la estrategia y la administración de un equipo virtual.

A continuación se explicara todas las características realizada en el proyecto, el proyecto se trata de una simulación de la aplicación del fantasy. El proyecto consta de varias partes que se explicara a continuación que son:

• Login/Registro
• MisLigas
• Clasificación
• Equipo
• Mercado
• Actividad
• Ajuste

Login/Registro

La sección de inicio de sesión estará claramente marcada y será de fácil acceso. Los usuarios que ya tengan una cuenta podrán ingresar su correo electrónico y contraseña para acceder a sus equipos y a la plataforma. La interfaz incluirá:

• Nombre del usuario
• Contraseña

• Login

Para los nuevos usuarios, la sección de registro estará destacada con una invitación a unirse a la comunidad de la aplicación. El proceso de registro será sencillo, promoviendo una experiencia de usuario sin fricciones. Esta sección incluirá:

• Nombre del Usuario
• Contraseña
• Comprobar Contraseña

• Registro

Mis Ligas

En la presente interfaz, nos encontramos en la página de inicio de la aplicación. Aquí, se exhibe una sección dedicada a noticias deportivas en tiempo real, proporcionándote información actualizada sobre tus deportes favoritos y eventos relevantes. Además de esta fuente de noticias en constante actualización, también te ofrecemos la posibilidad de crear una liga deportiva personalizada. Este botón te brinda la oportunidad de configurar tus propia liga.

• Inicio

• Crear Liga Personalizada

En esta pantalla, te proporcionamos la oportunidad de crear tu propia liga personalizada. Aquí, en esta página dedicada a la configuración de ligas deportivas, puedes definir el nombre que deseas asignar a tu liga única y decidir cuántas jornadas quieres que tenga.

Una vez creada la liga, la pantalla de inicio presenta un botón de simulación de jornadas, lo que permite a los usuarios llevar a cabo la competición de manera virtual.

Clasificación

En esta interfaz, los usuarios pueden consultar la clasificación de la liga que han creado. Esta clasificación se basa en la suma de puntuaciones obtenidas por los equipos durante las simulaciones de partidos. Ofrece una visión general de qué equipos están liderando la liga en función de su rendimiento.

Equipo

En esta interfaz se divide en 2 pantallas, en una se encuentra la Alineación que se trata de la alineación que tiene el equipo del usuario, ademas en esta puedes cambiar el equipo de tu nombre.

• **Alineación ** Aquí, los usuarios pueden ver la alineación actual de su equipo virtual. También tienen la opción de cambiar el nombre de su equipo. Esta pantalla proporciona una visión general de cómo se compone el equipo para los próximos partidos.

• Plantilla

En esta pantalla, se encuentran todos los jugadores disponibles en el equipo del usuario. Se proporciona una función de filtro que permite a los usuarios buscar jugadores según su posición o puntuación. Los usuarios pueden realizar tres acciones principales en esta pantalla:

En esta pantalla puedes realizar 3 acciones que son:

• Vender : Vende el jugador que has pulsado y se ingresa el dinero de lo que cuesta ese jugador al equipo.
• Al 11: Mueve el jugador a la alineación, para ello tienes que elegir al jugador que deseas sustituirle (Debe ser de la misma posición), a continuacion se mostrara la interfaz de cambio de jugador.

• Ver las estadísticas del jugador, pulsando encima del jugador.

En esta pantalla se ofrece para crear tu propia liga y en esta pagina tienes que colocar el nombre de la liga personalizada y los numeros de jornadas que quieres que tenga la liga.

Mercado

Esta interfaz ofrece un mercado de jugadores disponibles para fichar. Los jugadores en el mercado están disponibles de forma aleatoria. Los usuarios pueden comprar jugadores para su equipo aquí. Si un usuario vende un jugador, este podría volver a aparecer en el mercado en el futuro.

La parte superior de la pantalla incluye un botón de filtro para clasificar jugadores por puntuación, lo que facilita la búsqueda de jugadores que puedan aportar más puntos al equipo. Al igual que en la pantalla de "Equipo," los usuarios pueden hacer clic en un jugador para ver sus estadísticas.

Actividad

Esta pantalla proporciona un registro de todas las actividades e interacciones realizadas por los usuarios en la aplicación. Esto incluye acciones como comenzar una liga, comprar y vender jugadores, simular jornadas, entre otras. Sirve como un historial completo de la actividad del usuario en la plataforma.

Ajustes

En esta interfaz se trata de una interfaz en la que puedes guardar sesión para que se autocomplete automáticamente la siguiente vez que entres en la aplicación con los datos que ofrezcas en "Nombre Usuario" y "Contraseña".

Además se puede acceder pulsando en "preguntas frecuentes" las preguntas que más frecuente de los usuarios.

Información clara sobre la aplicación de patrones de arquitectura: diagrama de "componentes" y explicación de los mismos.

Introducción

En este apartado se incluye el diagrama de componentes de nuestra aplicación, así como los patrones de arquitectura usados y su implementación.

Diagrama de componentes

En el diagrama podemos ver, separados en capas, los distintos componentes de nuestra aplicación. Cada componente es un paquete dentro de nuestra aplicación que contiene el resto de clases de la misma, de forma que, por ejemplo, el componente "fragments" contiene a todas las clases de tipo "Fragment", está en la capa de "View" y usa los adapters y los viewModels para su implementación. De esta forma, quedan definidos los componentes que usa nuestra aplicación (además de estar divididos en capas) y las relaciones entre ellos.

A continuación se explican los patrones aplicados en la aplicación.

Patrón ModelViewViewModel.

El patrón Model-View-ViewModel (MVVM) es una arquitectura de diseño de software que se utiliza comúnmente en el desarrollo de aplicaciones de interfaz de usuario. Este patrón separa claramente las responsabilidades y roles de los componentes principales de una aplicación. Aquí te explico cada uno de los componentes del patrón MVVM:

-Model (Modelo):

Representa los datos y la lógica de negocio de la aplicación. El modelo no tiene conocimiento de la interfaz de usuario y se centra en la manipulación de datos y la implementación de reglas empresariales. Gestiona los datos y las operaciones relacionadas con la lógica de negocio. El modelo lo hemos incluido en el paquete model, en la raíz de nuestro paquete de aplicación. Contiene todas las clases de datos necesarias para la gestión de la aplicación y la base de datos con sus atributos necesarios, y se incluyen en la siguiente imagen.

En el subpaquete Api, se ven las clases necesarias para el modelo en relación con la API y los datos que se recuperan de la misma que, como se explica en el patrón Repository, se deben guardar también en la base de datos.

-View (Vista):

Representa la interfaz de usuario y su estructura visual. En el contexto de una aplicación para el usuario final, la vista es la pantalla que presenta la información y recibe las interacciones del usuario. Trata de mostrar la información al usuario y reaccionar a las acciones del usuario, pero no contiene lógica de negocio. La vista de nuestra aplicación la incluimos en el paquete view de la misma, y dentro de ella encontramos, ordenadas por sus correspondientes subpaquetes, las diferentes implementaciones que necesitamos, como son:

• activities
• adapters
• fragments

La vista general de la parte View de nuestro proyecto es la que se aprecia en la siguiente imagen.

-ViewModel:

Actúa como un intermediario entre la vista y el modelo. Es responsable de exponer datos desde el modelo a la vista y manejar las interacciones del usuario en la vista para actualizar el modelo. Sus principales responsabilidades son convertir datos del modelo en un formato que pueda ser mostrado por la vista, gestionar la interacción del usuario y actualizar el modelo en consecuencia.

Cómo funciona este patrón:

La vista observa y se enlaza a propiedades y comandos proporcionados por el ViewModel. El ViewModel interactúa con el Modelo para obtener o modificar datos. Cuando el Modelo se actualiza, el ViewModel notifica a la vista a través de la notificación de cambios (por ejemplo, mediante el uso de observables). La vista actualiza su interfaz de usuario según los cambios notificados por el ViewModel.

Lo referente a los viewmodels, uno para cada fragmento y activity, está en el paquete view.viewmodels, de forma que ahí se encuentran todos y se puede acceder a ellos desde los fragmentos, ya que están vinculados, mediante una variable de clase.

Patrón DAO.

El patrón DAO (Data Access Object) es un enfoque en el desarrollo de software que apunta a mantener la lógica de acceso a datos separada de la lógica de negocio. Este patrón se presenta con varios elementos clave.

Primero, está la Interfaz DAO, que establece los métodos para operaciones básicas como crear, leer, actualizar y eliminar (CRUD) en objetos de dominio. Luego, se tienen las Implementaciones concretas del DAO, que ofrecen la implementación real de esos métodos para una fuente de datos específica, como una base de datos relacional.

Los Objetos de Dominio representan las entidades de la aplicación que se almacenan en la base de datos. Normalmente, estos objetos se alinean directamente con las tablas de la base de datos. La Lógica de Negocio (Cliente) utiliza la interfaz del DAO para interactuar con la base de datos, manteniéndose ajena a los detalles específicos de implementación. Esto permite cambiar la fuente de datos sin tocar el código del cliente.

Opcionalmente, el patrón DAO puede incluir una Factoría que facilita la obtención de instancias concretas de DAO. Esto posibilita cambiar la fuente de datos subyacente sin alterar el código del cliente.

Entre las ventajas del patrón DAO, se destaca la clara separación de responsabilidades entre la lógica de acceso a datos y la lógica de negocio. Esto mejora la mantenibilidad, la reutilización de código y la flexibilidad al permitir cambios en la implementación de la base de datos sin afectar otras partes de la aplicación. Además, el patrón DAO facilita las pruebas unitarias al posibilitar la creación de implementaciones de DAO de prueba sin depender de una base de datos real.

Esta implementación la hemos realizado con Room en nuestro proyecto, estando las interfaces de acceso a la base de datos en el paquete uex.aseegps.ga03.tuonce.database, en el que se incluyen las clases ActividadDao, EquipoDao, etc. cada una con el código Room necesario para acceder a la base de datos mediante las consultas especificadas en las etiquetas. Desde el repositorio, como se explicará a continuación, accederemos a estas interfaces.

Asimismo, en este paquete encontramos TuOnceDatabase, que es una clase abstracta necesaria para acceder a la base de datos de la aplicación. En ella se detallan las funciones del DAO a las que se podrá llamar, así como las entidades que tendrá la base de datos, implementando un patrón Singleton

Los objetos del dominio se explicarán en el apartado de ModelViewViewModel, ya que son parte del modelo de datos.

Patrón Repository.

El patrón Repository, o Repositorio, es una estrategia de diseño de software que se utiliza para facilitar la gestión de la persistencia de objetos. Su enfoque principal es ofrecer una interfaz simplificada para trabajar con objetos en una fuente de datos, como una base de datos. La idea es que el cliente que utiliza esta interfaz no necesite conocer los detalles específicos sobre cómo se almacenan o recuperan los datos.

En este patrón, se establece una Interfaz Repository que define los métodos necesarios para realizar operaciones básicas como crear, leer, actualizar y eliminar (CRUD) en los objetos almacenados. Luego, hay una Implementación concreta del Repository que se encarga de proporcionar la implementación real de estos métodos para una fuente de datos específica, como una base de datos relacional.

Los Objetos de Dominio son esenciales en este contexto, ya que representan los objetos de la aplicación que se almacenan o recuperan mediante el Repository. Estos objetos suelen mapearse directamente a las entidades de la fuente de datos.

El cliente (es decir, lo que llamamos la lógica de negocio de nuestra aplicación, implementada en los ViewModel, como se comentará más adelante) es el componente que utiliza la interfaz del Repository para interactuar con los objetos de dominio, sin la necesidad de comprender los pormenores de cómo se gestionan los datos en la fuente subyacente. En otras palabras, la lógica de negocio se comunica con los objetos de dominio a través del Repository, manteniendo así una separación limpia de responsabilidades.

En términos de ventajas, el patrón Repository proporciona una capa de abstracción que simplifica el acceso a datos y permite que la lógica de negocio trabaje con los objetos de una manera más intuitiva. Además, esta abstracción facilita la reutilización de código y la adaptación a diferentes fuentes de datos sin cambiar la lógica de negocio. En resumen, el patrón Repository es una herramienta valiosa para simplificar la gestión de datos en una aplicación.

El patrón Repository lo hemos incluido como una clase en el paquete uex.aseegps.ga03.tuonce.model, y en él se detallan todos los elementos que hacen falta para que los ViewModel accedan a él y recuperen los datos correctamente.

hay varias variables LiveData y filtros que se utilizan para observar y obtener datos específicos de estas fuentes de datos. Aquí está la explicación de las variables y cómo algunas dependen de los filtros correspondientes:

Variables de DAO:

userDao, ligaDao, futbolistaDao, equipoDao, actividadDao: Son instancias de DAO (Data Access Objects) que proporcionan métodos para acceder a datos relacionados con usuarios, ligas, futbolistas, equipos y actividades respectivamente.

Filtros:

userFilter, equipoFilter, ligaFilter: Son variables LiveData que actúan como filtros. Estos filtros se utilizan para cambiar dinámicamente las consultas y obtener datos específicos basados en ciertos criterios, como el ID de usuario, el ID de equipo o el ID de liga.

Variables LiveData para Usuarios Conectados:

userName: Variable LiveData que contiene el nombre de usuario actual. usuarioConectado: LiveData que observa el cambio en el nombre de usuario y recupera los detalles del usuario conectado desde userDao.

Variables LiveData para Futbolistas:

futbolistas: LiveData que observa los cambios en la base de datos de futbolistas y obtiene la lista completa de futbolistas.

Variables LiveData para Actividades:

actividades: LiveData que observa los cambios en el filtro de usuario y recupera la lista de actividades asociadas a ese usuario.

Variables LiveData para Equipos y Ligas de Usuario:

equipoUsuario: LiveData que observa el filtro de usuario y obtiene el equipo asociado a ese usuario. ligaUsuario: LiveData que observa el filtro de usuario y obtiene la liga asociada a ese usuario.

Variables LiveData para Usuarios en una Liga:

usuariosLiga: LiveData que observa el filtro de liga y obtiene la lista de usuarios asociados a esa liga.

Variables LiveData y Filtros para Bots y sus Equipos y Futbolistas:

bot1, bot2, bot3: LiveData que contiene información de usuarios específicos (bots)

equipoBot1, equipoBot2, equipoBot3: LiveData que observa los cambios en la información del bot y recupera el equipo asociado a ese bot.

futbolistasEquipoBot1, futbolistasEquipoBot2, futbolistasEquipoBot3: LiveData que observa los cambios en la información del equipo del bot y obtiene la lista de futbolistas asociados a ese equipo.

Funciones del Repository:

• actualizarFutbolista actualiza un futbolista en la base de datos utilizando el método update de futbolistaDao con el futbolista proporcionado como parámetro.

• actualizarEquipo actualiza un equipo en la base de datos utilizando el método update de equipoDao con el equipo opcional proporcionado como parámetro.

• venderFutbolistaDelequipo realiza varias operaciones al vender un futbolista de un equipo. Primero, actualiza el valor del equipo sumándole el valor del futbolista vendido mediante actualizarValorEquipoSumar. Luego, actualiza el futbolista vendido quitándole el equipo asignado mediante actualizarFutbolistaSinEquipo. Finalmente, marca la actividad de venta con el usuario y el nombre del jugador mediante marcarActividadVenta.

• eliminarUsuario elimina un usuario de la base de datos utilizando el método delete de userDao con el ID proporcionado como parámetro.

• eliminarEquipo elimina un equipo de la base de datos utilizando el método delete de equipoDao con el equipo proporcionado como parámetro.

• eliminarLiga elimina la liga de la base de datos utilizando el método eliminarLiga de ligaDao.

• eliminarFutbolistaDelMercado realiza varias operaciones al eliminar un futbolista del mercado. Primero, actualiza el valor del equipo restando el valor del futbolista comprado mediante actualizarValorEquipo. Luego, actualiza el equipo del futbolista comprado asignándole el equipo del usuario mediante actualizarEquipoDelFutbolista. Finalmente, marca la actividad de compra con el usuario y el nombre del jugador mediante marcarActividadCompra.

• actualizarFutbolistaSinEquipo quita el equipo asignado a un futbolista estableciendo su equipoId a null y luego lo actualiza en la base de datos mediante el método update de futbolistaDao.

• actualizarEquipoDelFutbolista asigna un nuevo equipo a un futbolista estableciendo su equipoId al equipoUsuario proporcionado y luego lo actualiza en la base de datos mediante el método update de futbolistaDao.

• moveral11 establece que un futbolista está en el once titular estableciendo su estaEnel11 a 2 y luego lo actualiza en la base de datos mediante el método update de futbolistaDao.

• modificarDatos realiza modificaciones en dos futbolistas. Establece que el primer futbolista no está en el once titular (estaEnel11 a 0) y que el segundo futbolista está en el once titular (estaEnel11 a 1). Luego, actualiza ambos futbolistas en la base de datos mediante el método update de futbolistaDao.

• noCambio establece que un futbolista está en el once titular (estaEnel11 a 1) y que otro no está en el once titular (estaEnel11 a 0). Luego, actualiza ambos futbolistas en la base de datos mediante el método update de futbolistaDao.

• actualizarValorEquipoSumar suma el valor de un futbolista al presupuesto de un equipo y luego actualiza el equipo en la base de datos mediante el método update de equipoDao.

• actualizarValorEquipo resta el valor de un futbolista al presupuesto de un equipo y luego actualiza el equipo en la base de datos mediante el método update de equipoDao.

• marcarActividadCompra crea una nueva actividad de compra y la inserta en la base de datos utilizando el método insertar de actividadDao.

• marcarActividadVenta crea una nueva actividad de venta y la inserta en la base de datos utilizando el método insertar de actividadDao.

• actualizarPuntos actualiza los puntos de un usuario en la base de datos utilizando el método updatePoints de userDao.

• marcarActividadCrearLiga crea una nueva actividad de inicio de jornada y la inserta en la base de datos utilizando el método insertar de actividadDao.

• marcarActividadTerminarLiga crea una nueva actividad de finalización de liga y la inserta en la base de datos utilizando el método insertar de actividadDao.

• insertarLiga inserta una nueva liga en la base de datos y devuelve su identificador utilizando el método insertarLiga de ligaDao.

• marcarActividadNuevaLiga crea una nueva actividad de inicio de liga y la inserta en la base de datos utilizando el método insertar de actividadDao.

• insertarBot inserta un nuevo bot en la base de datos y devuelve su identificador utilizando el método insert de userDao.

• insertarFutbolista inserta un nuevo futbolista en la base de datos utilizando el método insert de futbolistaDao.

• insertarEquipo inserta un nuevo equipo en la base de datos y devuelve su identificador utilizando el método insert de equipoDao.

• insertarUsuario inserta un nuevo usuario en la base de datos y devuelve su identificador utilizando el método insert de userDao.

Reflexión sobre el trabajo desarrollado

El trabajo presentado muestra un enfoque detallado y estructurado para el desarrollo de una aplicación de fútbol virtual basada en la Liga Española. Se percibe un fuerte énfasis en la planificación y adaptabilidad, aspectos cruciales en la gestión de proyectos de software.

La decisión de limitar las funcionalidades a las competencias actuales del equipo es un enfoque pragmático que prioriza la calidad y la estabilidad del producto final sobre la ambición desmedida. Este enfoque puede resultar en una aplicación más robusta y menos propensa a errores, aunque potencialmente menos innovadora o completa en términos de funcionalidades.

Se ha definido un público objetivo con la aplicación y se ha puesto especial atención en ofrecer una experiencia real y atractiva. La inclusión de un mercado de fichajes virtual y la simulación de competiciones y torneos son características atractivas que pueden incrementar el interés y la retención de usuarios.

Respecto al nombre de la app, "TuOnce", refleja efectivamente la personalización y la propiedad que los usuarios tendrán sobre sus equipos. Esto ayuda a establecer una conexión entre la aplicación y sus usuarios, lo cual es importante para el compromiso a largo plazo.

En cuanto a la interfaz de usuario, el uso de un mapa de navegación y mock-ups detallados muestra un compromiso con la experiencia del usuario. Se han identificado y refinado claramente los flujos de usuario y se han realizado cambios basados en retroalimentación y pruebas iterativas, lo cual es una buena práctica en el desarrollo de software.

Las decisiones tomadas durante la reunión de seguimiento demuestran una capacidad de respuesta y una adaptación a la retroalimentación crítica, lo cual es fundamental para el éxito del desarrollo ágil de productos.

Finalmente, la adopción de patrones de arquitectura como MVVM y DAO indica una consideración seria de las mejores prácticas de ingeniería de software y un esfuerzo por mantener la aplicación mantenible y escalable.

En resumen, el proyecto refleja un enfoque equilibrado entre la ambición y la practicidad, con una buena comprensión de los principios del desarrollo de software y un claro enfoque en la experiencia del usuario. Por útlimo, a pesar de los desafíos de tiempo y las dificultades que hemos enfrentado, hemos conseguido avanzar con el proyecto y superar los obstáculos.