Descripci贸n
Aplicaci贸n Android desarrollada en Kotlin siguiendo el patr贸n de dise帽o MVVM que permite a los usuarios simular batallas con personajes de Dragon Ball. Ofrece una interfaz clara y estructurada, con activities de inicio de sesi贸n y de pantalla principal, la cual posee fragments compartidos (Single Activity).
La aplicaci贸n utiliza clases como CharacterDTO y Character para representar y transformar datos del servidor (API Rest Dragon Ball proporcionada por la escuela de programaci贸n KeepCoding) y emplea SharedPreferences para guardarlos. Otras caracter铆sticas incluyen la restauraci贸n de puntos de vida gracias a la acci贸n de un bot贸n, persistencia del juego al cerrar la aplicaci贸n y estad铆sticas de selecci贸n en el detalle del personaje.
鈿狅笍 Informaci贸n mucho m谩s detallada en el README del proyecto en GitHub. 鈿狅笍
Caracter铆sticas y funcionalidades
- Model-View-ViewModel (MVVM).
- Dise帽o de interfaces con XML.
- Consumo de API Rest con la biblioteca OkHttp.
- Uso de extensiones.
- Uso de interfaces.
- Unit Testing.
- Atenci贸n por el dise帽o y la experiencia de usuario.
- SharedPreferences.
Pantalla de Login en la que se deben introducir las credenciales, las cuales, antes de ser enviadas a la API para ser corroboradas, se comprueba que tanto el correo electr贸nico como la contrase帽a cumplan con el formato adecuado. En el caso de cumplir con el formato y ser err贸neas, aparece un Dialog para notificar al usuario que la autentificaci贸n ha sido fallida, es decir, que no se encuentran los datos registrados en nuestro backend.
Los EditText poseen cierta dinamicidad cuando se pulsa en ellos en pos de atender a la experiencia de usuario.
El correcto formato tanto del correo electr贸nico como de la constrase帽a se comprueba en tiempo real cada vez que el usuario escribe en el EditText. De esta forma, en caso de no ser adecuado, cosa que controlamos observando un StateFlow que alberga una Sealed Class que recoge diversos estados, se muestra un mensaje al usuario de que todav铆a el formato de aquello que est谩 escribiendo no es correcto.
Una vez que los formatos son correctos, aparecer谩 el bot贸n para hacer Login, ya que su visibilidad est谩 limitada al correcto formato del correo y de la contrase帽a.
Al pulsar el bot贸n de Login, el estado de la vista pasa a Loading y se muestra una ProgressBar en modo horizontal atendiendo, as铆, a la experencia de usuario y, una vez que se ha comprobado que las credenciales introducidas est谩n registradas en nuestro backend, se navega al HomeActivity, el cual es el encargado de albergar los dos fragments que constituir谩n el resto de nuestra aplicaci贸n, siguiendo la pr谩ctica Single Activity, tan extendida hoy d铆a en el desarrollo de aplicaciones Android gracias a su recomendaci贸n por Google ya que los fragments son m谩s 贸ptimos que las Activities.
Pantalla principal de la aplicaci贸n en la que, a trav茅s de un RecyclerView-Adapter-ViewHolder se muestra el listado de personajes que hemos obtenido llamando a la API Rest.
Las celdas (items, com煤nmente denominadas en Android) son personalizadas e incluyen un ImageView, un TextView, un ProgressBar para reflejar la vida del personaje de forma visual y otro TextView para mostrar la vida de forma n煤merica.
Adem谩s, se han a帽adido dos iconos en la Toolbar, los cuales, al pulsarlos, uno restaura al 100 la vida de todos los personajes; mientras que el otro se dedica a cerrar la sesi贸n, eliminando los datos guardados en SharedPreferences, destruyendo las vistas y navegando al LoginActivity.
Segundo fragment empleado en la HomeActivity. Muestra el detalle del personaje que ha sido seleccionado previamente por el usuario en el listado. Aqu铆 se expone la imagen del personaje, su nombre, su vida y tres botones: uno para curarse la vida 20 puntos, otro para recibir un da帽o entre 10 y 60 puntos de manera aleatoria y un 煤ltimo que, al pulsarlo, aparece un Toast que nos indica las veces que ha sido seleccionado ese personaje por el usuario a lo largo del uso de la aplicaci贸n, a modo de estad铆stica.
La l贸gica implementada alrededor de la vida del personaje tiene en cuenta, como es obvio, que esta no supere los 100 puntos si pulsamos ilimitadamente el bot贸n de curar, y que al llegar a 0 puntos, aparezca un Dialog que nos indique que el personaje ha sido derrotado y que al pulsar en OK, se destruya el fragment y se vuelva al otro fragment que muestra el listado de personajes.
Por 煤ltimo, se帽alar que los personajes derrotados tendr谩n una apariencia diferente en el listado para que el usuario sepa su estado, adem谩s de que estos no podr谩n ser pulsados para ir a su detalle.
GitHub