DEV Community: JR Saucedo

Registro 004-1. Domina Flutter con Clean Architecture: Integración de Supabase y Repositorios Simplificada

JR Saucedo — Sun, 22 Sep 2024 04:23:49 +0000

Continuando con el progreso de nuestro proyecto, ya sabemos cómo se vería la configuración inicial de nuestro service locator para la inyección de dependencias. Ahora, vayamos a algo menos estándar y más relacionado con las características específicas del proyecto, donde comenzaremos a aplicar la clean architecture.

Cuando iniciamos un proyecto y aún no contamos con toda la estructura clara de cómo será, lo que sí solemos tener en mente es nuestro proceso de autenticación. Aunque en nuestro caso sabemos hacia dónde vamos, en este proyecto utilizaremos Supabase y sus capacidades de control de acceso.

`features/user`

Primero, creamos nuestros directorios a utilizar:

Aquí es donde comenzamos a aplicar nuestra clean architecture, dividiendo los directorios y sus responsabilidades. Personalmente, me gusta comenzar en orden alfabético la creación de archivos, así que empecemos por la fuente de datos: data, donde manejaremos todo lo relacionado con la obtención de información del usuario. Primero crearemos el modelo, no muy alfabéticamente de mi parte, pero luego entenderán por qué.

`features/user/data/models`

Aquí definimos lo que esperamos recibir de nuestra instancia de Supabase para el perfil de usuario:

Desglosemos lo que tenemos aquí:

Usamos la anotación @freezed, que nos ayudará a crear todos los métodos necesarios para nuestro modelo, cumpliendo con los estándares de Dart, aunque no se usen todos.
Declaramos nuestra clase y la unimos a nuestro mixin con todos estos métodos.
En nuestro primer factory, definimos los campos que tendrá nuestro modelo.
Por último, creamos un factory fromJson, útil para transformar datos en formato JSON (de APIs, SDKs, etc.) a una data class compatible con Dart, que se generará automáticamente gracias a la anotación @freezed.

Al crear el modelo, verás que el documento se llena de errores, pero no pasa nada. Para que todo funcione, debemos correr el siguiente comando:

dart run build_runner build -d

Si estás creando varios modelos, puedes correr un watch para que se creen automáticamente:

dart run build_runner watch -d

`features/user/data/data_source`

Ya tenemos nuestro modelo, continuemos con nuestro data_source. Este será otro archivo Dart, llamado user_source, que contendrá todas las peticiones a Supabase relacionadas con el usuario:

Como ves, muchos de nuestros métodos devuelven un UserModel. Para evitar más errores, creamos el modelo antes de seguir con esta parte. Ahora vayamos método por método, agregando nuestra lógica:

Para iniciar sesión, primero necesitamos una cuenta. Una opción es hacerlo con un correo electrónico y contraseña. Además, utilizaremos gravatar para generar imágenes de perfil de los usuarios, evitando así gestionar imágenes directamente y evitando posibles problemas legales.

Por último, creamos un registro en nuestra tabla profiles, donde se almacenará el perfil público del usuario para enlazarlo con sus partidas y otros usos. Aquí tienes la estructura de la tabla en Supabase:

Con esto, ya tenemos nuestro método de registro. Ahora podemos iniciar sesión con este otro método:

Es un método sencillo, donde nuestro factory fromJson entra en acción, transformando la respuesta del SDK a una data class compatible con Dart.

Para no hacer más extenso este artículo, continuaremos con estos métodos en el futuro para completar nuestra feature.

Configuración de Inyección

Como mencionamos antes, en el constructor de la clase indicamos que recibirá un SupabaseClient. Pero, ¿de dónde lo recibirá? Esto lo hacemos con cada elemento de nuestra arquitectura a través del service locator o inyector de dependencias.

class UserSource {
  UserSource(this._client);
  final SupabaseClient _client;
...

Utilizaremos un registerFactory para agregar nuestro UserSource y su dependencia requerida en el constructor.

El cual se vería algo así, hasta ahora, donde se ve que le decimos qué dependencia recibe con un tipo en nuestro service locator.

`features/user/[data/domain]/repositories`

Ahora conectemos nuestras capas data y domain. Para esto, primero creemos nuestro repositorio en la capa domain. Esta será una clase abstracta donde solo declaramos los métodos que utilizaremos en domain, los cuales luego implementaremos en nuestro repositorio de implementación.

Aquí está, y si no conoces el paquete dartz, te lo presento. Es una útil herramienta para controlar los estados de error en nuestras diferentes capas. Nuestro método espera dos posibles respuestas: un error o la data correcta, lo cual nos permitirá atrapar estas respuestas y mostrar el estado adecuado en nuestra app.

Para manejar errores, en este caso, crearemos una clase de ayuda llamada Failure, la cual mediante extensiones nos permitirá gestionar diversos errores. Esta la crearemos en core/common/exceptions:

Aquí utilizamos otra librería muy útil llamada Equatable, la cual nos facilita transportar varios campos en nuestra clase y manejar de forma más limpia las comparaciones de clases y valores.

Ahora bien, tenemos en una misma clase dos tipos de error: SupaBaseException y Error, los cuales son extensiones de la misma clase. Nuestros métodos podrían devolver cualquiera de ellos. Además, el campo exception es opcional, ya que no siempre se cumple.

Para finalizar, necesitamos nuestra UserEntity, ya que, como sabemos, en las capas posteriores no deberíamos utilizar los modelos de la capa anterior. Entonces, pasemos a crearla:

Podemos ver que tiene los mismos campos que nuestro modelo, pero más simplificado. A partir de esta capa, no necesitamos realizar más transformaciones ni cambios. Todo es inmutable a partir de este punto.

Regresemos a la capa data en nuestro directorio repositories y creemos nuestro repositorio de implementación user_repo_impl.dart con lo siguiente:

import 'package:dartz/dartz.dart';

import '../../../../core/common/exceptions/failure.dart';
import '../../domain/entities/user.dart';
import '../../domain/repositories/user_repo.dart';
import '../data_source/user_source.dart';

class UserRepoImpl implements UserRepository {
  UserRepoImpl(this._userDataSource);
  final UserSource _userDataSource;

  @override
  Future<Either<Failure, UserEntity?>> getUser() async {
    try {
      final response = await _userDataSource.getUser();
      return Right(response);
    } catch (e) {
      return Left(SupaBaseException(e.toString()));
    }
  }

  @override
  Future<Either<Failure, UserEntity>> signInWithEmailAndPassword(
    String email,
    String password,
  ) async {
    try {
      final response = await _userDataSource.signInWithEmailAndPassword(
        email,
        password,
      );
      return Right(response);
    } catch (e) {
      return Left(SupaBaseException(e.toString()));
    }
  }

  @override
  Future<void> signOut() async {
    await _userDataSource.signOut();
  }

  @override
  Future<Either<Failure, UserEntity>> signUpWithEmailAndPassword(
    String email,
    String password,
    String name,
  ) async {
    try {
      final response = await _userDataSource.signUpWithEmailAndPassword(
        email,
        password,
        name,
      );
      return Right(response);
    } catch (e) {
      return Left(SupaBaseException(e.toString()));
    }
  }
}

Con esto, hacemos la conexión entre capas, logrando pasar nuestros datos desde su fuente hasta las capas posteriores. Ahora, toca agregar la inyección de dependencias correspondiente, ya que nuestra implementación espera recibir el data_source llamado UserSource como dependencia. Para eso hacemos lo siguiente:

Aquí podemos notar algo peculiar: declaramos como tipo principal UserRepository, pero en el factory inicializamos nuestro UserReposImpl, que es el que necesita la dependencia UserSource. Sin embargo, en la siguiente capa domain/use_cases, utilizaremos UserRepository.

Si estás siguiendo el proceso, es posible que te hayas encontrado con el siguiente error:

Los métodos del repositorio están esperando como respuesta un tipo UserEntity, pero nosotros estamos enviando un UserModel. Este error lo abordaremos en el siguiente artículo, ya que, como pueden ver, hasta ahora hemos hecho bastante trabajo, y este post se ha vuelto mucho más largo en comparación con mis registros anteriores.

Para resolverlo, hay varios caminos, y los analizaremos en la segunda parte de este blog.

Gracias por acompañarme hasta aquí, y espero que haya sido claro. ¡Nos vemos en la siguiente entrega!

devsignersmx / rps-public

RPS Rumble

Proyecto donde aplicaremos la Clean Architecture con dependency injection y bloc. Encuentra todo los articulos en la serie de:

De Cero a Flutter: Mi Viaje para Construir una App y Compartir lo Aprendido

View on GitHub

Retgistro 003 — Flutter desde Cero: Simplificando tu main.dart y Dominando la Inyección de Dependencias

JR Saucedo — Wed, 28 Aug 2024 20:25:18 +0000

Luego de platicar sobre la planeación y estipular la arquitectura a utilizar, porque como bien sabemos, y si no te lo había contado, aplicar una arquitectura como Clean Architecture puede tener muchas variantes. Al final, más que una estructura rígida, termina siendo una filosofía que podemos adaptar según las necesidades e interpretaciones, siempre cumpliendo con sus principios. Pero bueno, si queremos profundizar más en eso, podemos leer el artículo anterior: Registro 002. Porque ahora sí, en este artículo, comenzaremos a escribir código.

Inyeccion de dependencias y primeros ajustes.

Como lo platicamos, esta sería nuestra estructura; no cambia mucho a lo normal. Contamos con un archivo main.dart y otros directorios. Pero en este caso, limpiaremos nuestro archivo y le quitaremos unas cuantas responsabilidades que no sean las de inicialización.

Originalmente, nuestro archivo main.dart suele venir así:

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        // This is the theme of your application.
        //
        // TRY THIS: Try running your application with "flutter run". You'll see
        // the application has a purple toolbar. Then, without quitting the app,
        // try changing the seedColor in the colorScheme below to Colors.green
        // and then invoke "hot reload" (save your changes or press the "hot
        // reload" button in a Flutter-supported IDE, or press "r" if you used
        // the command line to start the app).
        //
        // Notice that the counter didn't reset back to zero; the application
        // state is not lost during the reload. To reset the state, use hot
        // restart instead.
        //
        // This works for code too, not just values: Most code changes can be
        // tested with just a hot reload.
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  // This widget is the home page of your application. It is stateful, meaning
  // that it has a State object (defined below) that contains fields that affect
  // how it looks.

  // This class is the configuration for the state. It holds the values (in this
  // case the title) provided by the parent (in this case the App widget) and
  // used by the build method of the State. Fields in a Widget subclass are
  // always marked "final".

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      // This call to setState tells the Flutter framework that something has
      // changed in this State, which causes it to rerun the build method below
      // so that the display can reflect the updated values. If we changed
      // _counter without calling setState(), then the build method would not be
      // called again, and so nothing would appear to happen.
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    // This method is rerun every time setState is called, for instance as done
    // by the _incrementCounter method above.
    //
    // The Flutter framework has been optimized to make rerunning build methods
    // fast, so that you can just rebuild anything that needs updating rather
    // than having to individually change instances of widgets.
    return Scaffold(
      appBar: AppBar(
        // TRY THIS: Try changing the color here to a specific color (to
        // Colors.amber, perhaps?) and trigger a hot reload to see the AppBar
        // change color while the other colors stay the same.
        backgroundColor: Theme.of(context).colorScheme.inversePrimary,
        // Here we take the value from the MyHomePage object that was created by
        // the App.build method, and use it to set our appbar title.
        title: Text(widget.title),
      ),
      body: Center(
        // Center is a layout widget. It takes a single child and positions it
        // in the middle of the parent.
        child: Column(
          // Column is also a layout widget. It takes a list of children and
          // arranges them vertically. By default, it sizes itself to fit its
          // children horizontally, and tries to be as tall as its parent.
          //
          // Column has various properties to control how it sizes itself and
          // how it positions its children. Here we use mainAxisAlignment to
          // center the children vertically; the main axis here is the vertical
          // axis because Columns are vertical (the cross axis would be
          // horizontal).
          //
          // TRY THIS: Invoke "debug painting" (choose the "Toggle Debug Paint"
          // action in the IDE, or press "p" in the console), to see the
          // wireframe for each widget.
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            const Text(
              'You have pushed the button this many times:',
            ),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headlineMedium,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ), // This trailing comma makes auto-formatting nicer for build methods.
    );
  }
}

Haremos un cambio bastante fuerte, quitando todo lo que no necesitamos que esté aquí y, como mencionamos, solo dejaremos lo necesario para inicializar nuestra app. Llegamos a esto:

import 'package:error_stack/error_stack.dart';
import 'package:flutter/foundation.dart' show kDebugMode;
import 'package:flutter/material.dart';

import 'package:supabase_flutter/supabase_flutter.dart';

import 'core/app/app.dart';
import 'core/service_locator.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Supabase.initialize(
    url: const String.fromEnvironment(
      'SUPABASE_URL',
    ),
    anonKey: const String.fromEnvironment(
      'SUPABASE_ANON_KEY',
    ),
    realtimeClientOptions: const RealtimeClientOptions(
      logLevel: kDebugMode ? RealtimeLogLevel.debug : RealtimeLogLevel.info,
    ),
  );
  await setupServiceLocator();
  await ErrorStack.init();
  runApp(const MainApp());
}

Encontramos quizás código conocido para todos y otro no tan conocido.

WidgetsFlutterBinding.ensureInitialized(); Con este paso, nos aseguramos de que el Flutter engine esté listo para comenzar nuestras acciones, especialmente nuestra conexión con Supabase.
Inicializamos nuestra conexión con Supabase, trayendo de nuestro environment las variables necesarias. A su vez, le designamos un logLevel a nuestras comunicaciones en tiempo real.

Para hacer funcionar String.fromEnvironment() cuando corramos nuestra app y hagamos build, tendremos que agregar nuestras variables como argumentos: --dart-define=SUPABASE_URL=*****, separando un argumento por cada variable de ambiente.
Si estás corriendo en debug directamente desde VS Code, estos argumentos extras puedes agregarlos en el launch.json:

Si estas usando Android Studio, entras a la configuración de debugging y agregas los argumentos extras:

Luego, iniciamos nuestro serviceLocator, que se encargará de la inyección de dependencias.
Tenemos una librería que nos muestra mayor información cuando tenemos errores que no estamos capturando, muy útil: ErrorStack.
Al final, contamos con nuestro clásico runApp.

Service Locator

Luego de ver los detalles en main.dart, podemos pasar al archivo que es un tanto diferente a lo que podríamos estar acostumbrados a ver en nuestros proyectos de Flutter. Para el caso de la inyección de dependencias, utilizaremos la librería get_it. La inicialización de este es muy sencilla, al menos al inicio. Creamos un archivo service_locator.dart en nuestro directorio core.

import 'package:get_it/get_it.dart';

final GetIt sl = GetIt.instance;

Future<void> setupServiceLocator() async {}

Como bien podemos ver, el método setupServiceLocator es el que invocamos en main.dart y, en su caso, la instancia sl es la que llamaremos para acceder a las dependencias. Vamos a configurar una dependencia que es la principal a utilizar, en este caso el cliente de Supabase, aunque en otros proyectos podría ser el cliente de Dio o el cliente HTTP que utilices.

Configuración de dependencias - Supabase

La instancia de Supabase ya la inicializamos en el main.dart, ahora hagámosla accesible a través de nuestro inyector. Creamos un archivo dentro de core/services y lo llamaremos supabase_client.dart. En él colocaremos una clase donde accederemos a las librerías que necesitamos de Supabase.

import 'package:supabase_flutter/supabase_flutter.dart';

class SupabaseNetwork {
  SupabaseNetwork(this._supabase) {
    _supabase = Supabase.instance;
  }
  Supabase _supabase;
  SupabaseClient get client => _supabase.client;
}

Por cuestiones de naming, no pudimos llamar nuestra clase igual que nuestro archivo, pero este archivo va más como ejemplo. Porque si bien podríamos agregarlo directo a nuestro serviceLocator, como bien mencioné, para ejemplificar en nuestro proyecto, estamos haciéndolo así.

Luego de que tenemos nuestra clase, la registramos en nuestro serviceLocator.

import 'package:get_it/get_it.dart';
import 'package:supabase_flutter/supabase_flutter.dart';

import 'services/supabase_client.dart';

final GetIt sl = GetIt.instance;

Future<void> setupServiceLocator() async {
  sl
    //Services
    ..registerFactory<SupabaseClient>(
      () => SupabaseNetwork(Supabase.instance).client,
    );
}

En este caso, lo registramos como factory, para acceder a una nueva instancia con cada get que realicemos de la dependencia. Luego, con otros tipos, usaremos otros tipos de registro para poder compartir el mismo estado de las dependencias según el caso.

Creo que por este artículo ha sido bastante información. En la siguiente entrega abordaremos la creación del features/users, donde veremos la inyección de la dependencia y conexión con data_source, repos, y bloc en sus diferentes ubicaciones, así como también el registro de esas dependencias.

devsignersmx / rps-public

RPS Rumble

Proyecto donde aplicaremos la Clean Architecture con dependency injection y bloc. Encuentra todo los articulos en la serie de:

De Cero a Flutter: Mi Viaje para Construir una App y Compartir lo Aprendido

View on GitHub

Registro 002 - Organizando el Código: Clean Architecture en Acción para tu Proyecto Flutter

JR Saucedo — Tue, 13 Aug 2024 01:15:09 +0000

Como hemos visto luego de planear ya podemos comenzar escribir nuestro codigo, y si bien no quisiera entrar en temas muy iniciales de flutter y demas, si podemos obviar algunas cosas que necesitamos para comenzar:

Prerequisitos

Comenzaremos con que es importante tener Flutter instalado y Android Studio, entre otros pasos que puedes revisar aquí, primeramente para crear nuestro proyecto:

flutter create {nombre de directorio} --project-name {nombre de nuestro app}

Luego agregaremos las librerias que utilizaremos en nuestro proyecto:

flutter pub add supabase_flutter bloc flutter_bloc dartz get_it dio flutter_gen google_fonts error_stack cached_network_image equatable flutter_dotenv flutter_screenutil freezed_annotation gap go_router json_annotation pull_to_refresh skeletonizer toastification google_sign_in flutter_gravatar

a. Las librerias de soporte en el desarrollo que usaremos:

flutter pub add --dev bloc_test build_runner flutter_gen_runner freezed json_serializable mockito mocktail
Estructura
Como hemos mencionado, trabajaremos con la Clean Architecture, por lo que debemos organizar nuestros directorios de manera específica para no perdernos y cumplir con cada punto de dicha metodología. A continuación, implementaremos una estructura que me ha servido y que considero la más fácil de usar, aunque en internet encontrarás diferentes maneras de aplicar esta arquitectura.

Estructura

Comencemos con el primer nivel de directorios:

core: Aquí almacenaremos servicios y widgets comunes o compartidos.

features: Donde organizaremos las secciones principales de nuestra app.

gen: Es un directorio autogenerado que utiliza la librería flutter_gen para los assets que usemos. No es necesario generarlo manualmente, ya que se autogenerará más tarde.

main.dart: Contendrá nuestra función main, que correrá la app.

Core

Como mencionamos, nuestro directorio core almacenará todo lo relacionado con servicios y widgets compartidos en toda la app.

app: Almacena nuestra aplicación, donde agregaremos todo lo relacionado con las configuraciones de nuestra clase MainApp. Usualmente, se encuentra dentro de main.dart, pero es más limpio extraerla a su propio archivo.

routes: La configuración de nuestras rutas, donde usaremos GoRoute.

theme: Nuestra clase para configurar todo nuestro tema.

common: Contendrá todos nuestros widgets compartidos y clases que utilizaremos en servicios o dentro de la misma Clean Architecture.

services: Aquí irán nuestras clases de clientes de comunicación con las diferentes APIs que utilicemos o clientes HTTP. En nuestro proyecto, utilizaremos Supabase.

service_locator: Nuestra clase encargada de la inyección de dependencias.

Features

Nuestra organización estará centrada en funcionalidades (features), por lo que dentro de este directorio las dividiremos por nombre, y dentro colocaremos nuestra estructura de Clean Architecture.

data: Concentra la obtención de información de fuentes externas.

data_source: Contiene las clases que utilizan nuestro servicio de API para obtener la información a utilizar.
models: Son nuestras estructuras de datos primitivas, donde hacemos la transformación de JSON a data class de Dart. Principalmente, utilizamos este primer paso para hacer más sencillo su manejo dentro de nuestra app. Suelen ser una extensión de nuestras entities.
repositories: Aquí se almacenan las implementaciones de los repositorios que se encuentran en domain. Es crucial que estas implementaciones se mantengan en la capa data para cumplir con los principios de la Clean Architecture.

domain: Concentra nuestra lógica ya transformada y compatible con nuestra app.

entities: Son nuestros modelos, pero ya listos para su manejo dentro de la app. A partir de este punto, solo usamos las entities para mostrar nuestros datos en la app.
repositories: Son la representación abstracta de nuestros repositorios, previamente implementados en la capa data. Mantener los repositorios en forma de interfaces en esta capa asegura la independencia de la lógica de negocio.
use_cases: Son clases con propiedades que llaman a nuestros repositorios con un método call(). Entonces, por cada método de nuestro repositorio, existirá un use_case.

presentation: Engloba la parte visual de nuestra app, donde ahora sí utilizaremos los datos listos y “sanitizados” de nuestra app.

bloc: Consumirá nuestros use_cases y hará las actualizaciones de estado de nuestra app, según las respuestas que reciba, ya sean satisfactorias o errores. Es importante mantener la lógica de presentación aislada de los detalles específicos de los casos de uso.
pages: Teniendo en mente el pensamiento de diseño atómico de nuestros componentes, esta parte almacenará las moléculas que se complementarán de widgets que esperan recibir la data para mostrarla.
widgets: Son la parte más pequeña de nuestra app, fragmentos que esperan recibir data para presentarla. A su vez, ejecutan acciones de nuestro bloc para recibirla o hacer cambios en nuestra app, como formularios, botones o URLs de imágenes para mostrarlas.

Es crucial recordar que la organización debe seguir principios claros de separación de responsabilidades y uso de abstracciones para mantener la integridad de la Clean Architecture.

Esto ha sido un monton de información que degerir, pero es mucho más sencillo de lo que parece. En nuestro siguiente capitulo veremos que código va en donde y por qué. Por lo pronto esta es una explicación rápida de como organizar nuestro código y proyecto con Clean Architecture.

Gracias por leerme y cualquier duda estoy a la orden en los comentarios.

Happy coding!

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

JR Saucedo — Sat, 03 Aug 2024 06:12:13 +0000

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:

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.

Registro 000 - ¿Listo para Flutter? Sigue Mi Aventura en el Desarrollo de una App con Clean Architecture

JR Saucedo — Sat, 20 Jul 2024 23:53:36 +0000

Antecedentes

Esta idea surgió con el propósito de cubrir los temas de un curso universitario que impartí un año antes de la pandemia. El objetivo era enseñar a los estudiantes de Diseño Multimedia lo que podían hacer con los conocimientos adquiridos durante los siete semestres previos. Considerando que ya habían tomado cursos de programación, desarrollo de videojuegos y desarrollo web, se desarrolló este pequeño juego para que pudieran ver cómo desarrollar futuras ideas. En su momento, utilizamos tecnologías web(VueJS) y servicios como Firebase.

Motivación

La curiosidad por aprender y aplicar buenas prácticas en el desarrollo de aplicaciones con Flutter, BLoC y Clean Architecture me ha llevado a iniciar este proyecto. Desarrollaré una aplicación basada en el clásico juego de Piedra, Papel, Tijeras, cumpliendo con las directrices principales: que sea rápida, casi en tiempo real, y con la posibilidad de jugar con amigos. Quiero explorar cómo estas metodologías pueden mejorar la eficiencia y calidad del desarrollo de aplicaciones, además de crear algo divertido y funcional.

Propósito

Después de varios años desarrollando en Flutter, mi propósito es aplicar mis conocimientos y compartirlos con la comunidad hispanohablante. Quiero difundir el conocimiento en nuestra lengua materna. No sé si es una crisis de la edad (34 años cuando escribo esto) o simplemente ego, pero me interesa contribuir significativamente a la comunidad que me ha dado tanto, ofreciendo recursos de aprendizaje y más. Como desarrollador senior, mi objetivo es retribuir y enriquecer la comunidad de desarrolladores en español.

Plan de Trabajo

Este plan está pensado para desarrollarse en dos partes:

Parte 1: Registro público y educación

Llevaré un registro público de mi avance a través de este blog (me disculpo por adelantado, ya que es la primera vez que lo hago).
Grabación y publicación de una serie de videos donde explicaré de la mejor manera posible las buenas prácticas en el uso de Flutter, BLoC y Clean Architecture.
En esta parte se concentrará mi contribución a la comunidad de desarrollo, compartiendo conocimientos y recursos útiles.

Parte 2: Desarrollo privado y lanzamiento

Esta parte del proyecto será llevada de manera privada y no estará completamente relacionada con el propósito educativo de la iniciativa.
El objetivo secundario es publicar e implementar la aplicación final.
Aunque no sabemos si la aplicación tendrá éxito, me reservaré esta parte del proceso. Sin embargo, pretendo compartir los resultados de la publicación, tanto negativos como positivos.
La idea es abrir una conversación con la comunidad tecnológica sobre los aprendizajes obtenidos.

Bueno entonces sin más, comencemos la pre pre planeación. Agradezco a quien se haya tomado el tiempo de leer.