DEV Community

Cover image for Registro 001 — Antes de Escribir Código: La Importancia de Planificar tu Proyecto Flutter
JR Saucedo
JR Saucedo

Posted on • Updated on

Registro 001 — Antes de Escribir Código: La Importancia de Planificar tu Proyecto Flutter

Plan de Trabajo

Bueno, estamos de vuelta con nuestro proyecto y no, aún no empezaremos con el código. Esto me gustaría compartirlo también como un consejo para todos esos nuevos programadores en camino a transformarse en desarrolladores: antes de empezar a escribir cualquier línea de código o bien antes del comando para iniciar su proyecto, hay que tomar una pausa y planear.

Recuerdo bien cuántos proyectos quise empezar con solo una idea y comenzar a escribir código. Pensando en la marcha, íbamos viendo qué utilizaríamos o cómo lo haríamos, y ahí quedaba ese proyecto, porque como no me tomé el tiempo de planearlo o pensarlo, se quedaba en una idea.

Por eso mismo, y con el ímpetu de mejorar en nuestro crecimiento como desarrolladores, creo que es momento de platicar de qué irá nuestro proyecto o al menos cómo funcionará. Desde ver qué tecnologías utilizaremos, cómo organizaremos nuestro proyecto y cómo lograremos cumplir con nuestro cometido.

Tecnologías

Como ya habíamos platicado en nuestro artículo anterior Registro 000, la tecnología principal en nuestro proyecto será Flutter como base de nuestro código. Posteriormente, utilizaremos como base de datos y backend principal Supabase, que, por sus virtudes de transacciones en tiempo real, nos ayudará en la funcionalidad de creación de partidas, sobre todo las públicas (más adelante hablaremos de eso), de fácil publicación y que a los usuarios les llegue de manera efectiva.

Estructura y Componentes

Nuestro proyecto se conformará de varias partes esenciales que harán que funcione y cumpla con nuestro propósito. Como se muestra en el diagrama siguiente:

Diagrama Proytecto

Data

Nuestra app se conectará al servicio de Supabase, pero antes vamos por partes. Hasta el momento se han detectado tres modelos principales:

  • Usuario
  • Partida
  • Mensaje

Estos serán nuestros modelos principales de nuestra capa de datos, los cuales serán los tipos de datos que manejaremos en toda la app. Puede que tengamos otros nuevos, pero como base empezaremos con los anteriormente mencionados.

Autenticación

Manejaremos el control de autenticación de usuarios, por lo que inicialmente integraremos las cuentas nativas de los dispositivos, Google y Apple, ya que por defecto, si un usuario está en su dispositivo móvil, tiene una cuenta de cualquiera de estos proveedores. Se está considerando Facebook para ampliar el acceso, por ejemplo, a usuarios de dispositivos no compatibles con ninguno de estos proveedores.

En el apartado de Supabase, tenemos nuestras tablas, que, si bien se puede observar, empatan con nuestros modelos. Pero igual tenemos unas notas importantes que mencionar sobre algunas de estas tablas:

Partidas

Las partidas serán de dos tipos: privadas, entre amigos previamente agregados dentro de la misma plataforma, o públicas, entendiendo que al principio no habrá amigos agregados. La posibilidad de crear partidas públicas ayudará a generar dichas conexiones. Por cuestiones de rendimiento, manejaremos 5 partidas públicas abiertas por usuario. ¿Qué significa abiertas? Nos referimos al estado en el que la partida solo cuenta con el usuario que la creó, esperando un retador.

Las partidas constarán de un reto estándar de el mejor de 3, o mejor de 5, según la configuración que se elija al realizar el reto. Con esto no generamos partidas de una sola ronda y se genera un poco más de interactividad y competencia.

Chat de partida

Durante la partida, la interacción entre los usuarios puede agregar un poco de dinamismo, pero a su vez no queremos crear un ambiente tóxico o abusivo, por lo cual se limitará a emojis. Aunque una partida es básicamente corta (mejor de 3 o 5), se piensa que puede traer un factor social interesante de interacción entre las partidas. Según el impacto que tenga, puede que con ciertos controles de moderación se abra una conversación más allá de emojis.


Por el momento, creo que ha sido bastante información y se ha estipulado lo suficiente para comenzar, ahora sí, a escribir código. En nuestra siguiente entrega analizaremos y veremos la organización de nuestro proyecto en cuanto a arquitectura y también las librerías o herramientas que utilizaremos para lograr el cometido.

Gracias por leerme y nos vemos en la siguiente entrega.

Top comments (0)