DEV Community: Asiel Alonso

Beyond the MVP: What Every Mobile App Needs Before Its First Release

Asiel Alonso — Tue, 27 Oct 2026 01:17:06 +0000

I've been developing mobile apps since 2018, and there's something I've noticed over the years: no matter how simple an app starts out, certain capabilities tend to become necessary sooner or later.

The MVP Misconception

When starting a new mobile app, one of the first questions is usually: What's the minimum we need to build before launching?

That's a fair question. The whole point of an MVP is to validate an idea without spending time building things nobody might ever use.

But I think there's an important distinction we sometimes overlook: keeping an app simple doesn't mean leaving out the things it needs to run reliably in production.

I can probably guess what you're thinking: Why build something you don't need yet?

I agree. I'm not suggesting we add features just because they might be useful someday. But after working on different mobile projects, I've noticed that certain needs keep coming up. Crash reporting, analytics, notifications, and update management are good examples.

These aren't necessarily difficult to add later. My point is simpler: if we already know we'll probably need them, why not consider them from the beginning?

Once an app reaches the App Store or Google Play, a new phase begins. Real users start interacting with it on devices we haven't tested, under conditions we can't always reproduce. Bugs appear, requirements change, and new versions need to be released.

That's why I believe a production-ready app needs more than its core business features. We also need ways to understand what's happening, respond when something goes wrong, and keep the product evolving.

You Can't Fix What You Can't See

Imagine launching an app that works perfectly on every device you've tested.

A few days later, users start reporting that it occasionally crashes.

Where do you start?

Without production monitoring, you're relying on user descriptions and your ability to reproduce the problem. And anyone who has tried to reproduce a bug that only happens on someone else's device knows how frustrating that can be. Trust me, I've been there more times than I'd like to admit. 😅

Crash Reporting

For me, crash reporting is one of those capabilities that should be there from the first release.

When something goes wrong, we need to know about it. Ideally, we should be able to identify the affected app version, operating system, device, and stack trace without asking the user to explain everything.

Crash reporting also helps us understand the scale of a problem. Is this happening to one person or hundreds? Did it start after the latest release?

Tools like Firebase Crashlytics or Sentry make this possible.

Which one you choose is less important than having that visibility in the first place.

Of course, not every problem causes a crash.

An API request might fail. A payment operation might return an unexpected response. A background task might stop working while the app continues running normally.

These problems can be just as important, but without proper error monitoring, they may go unnoticed.

Product Analytics

Crash reporting helps us understand when something breaks. Analytics helps us understand what people actually do with our app.

Are users completing the registration process? Which features are they using? Where are they dropping off?

Without that information, it's easy to make product decisions based on assumptions.

I'm not suggesting we track every interaction. I think it's better to start with a few meaningful events that tell us whether the app is doing what it's supposed to do.

For example, if registration is an important part of the product, knowing how many users start and complete that process can already tell us something useful.

Firebase Analytics is one option for collecting this information, provided we handle user data responsibly and respect applicable privacy requirements.

The goal isn't to collect as much data as possible. It's to have enough information to make informed decisions.

Every App Needs a Way to Evolve

One thing we can be certain of is that our app will change.

We'll fix bugs, introduce features, update dependencies, and adapt to new operating system versions or backend requirements.

So it's worth thinking about how we're going to handle those changes before the first release.

Application Updates

Publishing a new version to Google Play or the App Store is only part of the process.

Not everyone updates immediately. Some users disable automatic updates, while others keep using older versions for weeks or even months.

That means we may have several versions of our app running in production at the same time.

And we need to be prepared for that.

Version Management

Let's say our backend introduces a change that an older app version doesn't support.

What happens to users who haven't updated?

Do we ask them to install the latest version? Do we prevent them from continuing? Can the backend remain compatible with both versions?

These are decisions I'd rather make during development than in the middle of a production issue.

A basic version management strategy can help us distinguish between recommended and mandatory updates, define minimum supported versions, and communicate clearly with users.

Of course, forcing an update shouldn't be our default solution. Maintaining backward compatibility whenever possible is just as important.

Over-the-Air Updates

Depending on the technology we're using, we may also have the option to deliver certain updates without publishing a new version through the stores.

In React Native projects using Expo, for example, EAS Update allows compatible JavaScript and asset changes to be delivered over the air.

That can be especially useful when we need to fix something quickly.

But OTA updates have limitations. Changes involving native code or dependencies may still require a new binary, and we must respect the distribution platforms' policies.

I'm not saying every project needs OTA updates. I just think it's worth understanding whether they're an option before we need them.

Communication Is Part of the Product

Another capability I've seen become important as applications evolve is communication with users.

Maybe we need to notify someone about a transaction, remind them about an upcoming event, or announce something relevant.

Depending on the product, notifications can become an important part of the experience.

Push Notifications

Push notifications may not appear in the initial requirements, but they're worth considering when the product is likely to need communication outside the app.

And there's more to them than simply displaying a message.

We need to think about notification permissions, user preferences, device registration, and what should happen when someone taps a notification.

Services like Firebase Cloud Messaging or OneSignal provide solutions for delivering push notifications.

Does every app need them from day one? Of course not.

An offline calculator probably doesn't need push notifications. But if we're building an application where reminders, alerts, or transactional updates are likely to matter, I think it makes sense to consider that early.

Update Notifications

There's another type of communication that's easy to overlook: letting users know when they should update the app.

Sometimes an update introduces improvements. Other times, it fixes a critical issue or addresses a compatibility problem.

We should have a clear way to inform users when an update is available and, when necessary, explain why it's required.

It's a small detail that can make the experience much less confusing.

Essential, Recommended, or Optional?

Now, you might be wondering whether all of this defeats the purpose of building an MVP.

I don't think so.

I'm not suggesting that every application needs every capability I've mentioned. A banking app, a social network, and a simple offline utility have very different requirements.

What I'm suggesting is that we should make these decisions consciously instead of ignoring them because they aren't part of the initial business features.

Here's how I'd approach the capabilities we've discussed:

Capability	My recommendation
Crash reporting	Have it from the first public release
Error monitoring	Start with basic visibility
Product analytics	Track a few meaningful events when appropriate
Store release process	Have a reliable process before launch
Version compatibility	Think about it early
OTA updates	Evaluate based on the technology stack
Push notifications	Consider early if communication is relevant to the product
Update notifications	Have a way to communicate important updates

These aren't strict rules. They're simply starting points that have worked well for me.

And there's a question I like to ask when thinking about these decisions:

If we need this capability three months after launch, will we wish we had considered it earlier?

If the answer is yes, maybe it's worth addressing now, even if we decide to postpone the implementation.

Build for What Happens After Launch

An MVP is about building only what's necessary to validate an idea. I completely agree with that approach.

But launching an app isn't the end of development. It's the beginning of a different stage, one where we have real users, unexpected problems, changing requirements, and a product we need to maintain.

Over the years, I've noticed how often the same operational needs come up across different mobile projects.

That's why I believe it's worth thinking about them from the start.

We don't need to implement everything immediately, and we certainly don't need to overengineer a simple application.

We just need to recognize the difference between features we might never need and capabilities that help us operate and maintain the product we're building.

Keep the MVP simple. Just make sure it's ready for what comes after launch.

Bye!!

x402 Payment Required

Asiel Alonso — Tue, 08 Sep 2026 02:35:43 +0000

AI stopped being a tool you use, it's becoming something that acts. Agents that don't just answer questions, but make decisions, execute tasks, and increasingly, act autonomously without a human approving every step. But there's one step most current infrastructure isn't ready for: what happens when that agent needs to pay for something?

Today, if an agent needs market data, access to a specialized model, or any paid resource, the path is still human: a subscription, an API key, a saved card, someone approving the charge. That model works when a person is making an occasional purchase. It doesn't work when an agent is making thousands of micro-decisions per second, each one potentially carrying its
own payment of a few cents.

Why Today's Rails Don't Cut It

The payment rails we use today; cards, bank transfers, PayPal, were designed for people, not machines. They have chargebacks, manual approvals, settlement times measured in days, and cost structures that only make sense when the amount justifies the friction. None of that works for an agent that needs to pay $0.001 for a query and move on half a second later.

Blockchain

Blockchain solves this not because it's "modern", but because it has exactly the properties a machine-to-machine payment needs: final, instant settlement (no chargeback is possible because there's no reversal), permissionless access (no account to open, no approval to request), and a cost that can be a fraction of a cent instead of a fixed $0.30-plus-fee floor. Payment becomes as automatic as any other API call which, ultimately, is what has to happen for an agent's autonomy to be real instead of just a promise.

x402 protocol

The standard pushing this forward is called x402, it takes an HTTP status code that's existed since the '90s but was never actually used ("402 Payment Required") and turns it into the real mechanism: an agent requests a resource, the server responds "this costs X," the agent signs the payment and retries, done. No accounts, no API keys, no human friction in between.

The reference implementation was built with Ethereum/Base in mind makes sense, it's the ecosystem of whoever published it. But the protocol itself isn't tied to any one chain, and an official XRPL implementation already exists.

More than one chain can fill this role, and several will probably end up coexisting. Personally, I think XRPL makes sense for this case: it was built with payments in mind from the start, not adapted afterward to try it, and it now has an official implementation of this protocol. It's not necessarily the only right answer, but it's one worth watching closely while this space is still being defined.

What Doors This Opens

When paying stops being friction, the kind of business that makes sense changes. A research article no longer needs to be sold as a monthly subscription, it can be charged per read. A specialized AI model doesn't need you to request an API key and get billed at month's end it charges per inference, on the spot. Real-time market data, GPU by the compute-minute, storage by what's actually used all of it becomes billable by the second, with nobody needing to open an account first.

This is what the protocol itself describes as "fully autonomous, AI-driven commerce", goal-oriented agents operating independently in an on-demand, permissionless economy. The x402 whitepaper calls it "agentic commerce." It's still early most of this doesn't exist in production yet but the infrastructure for it to exist is already there.

AI is going to keep accelerating, and with it, the autonomy of the agents we build. For that autonomy to be real, it needs a payment layer as fast and cheap as the decision itself and that piece, today, already exists.

SOLID + ReactJS

Asiel Alonso — Sat, 27 Apr 2024 22:28:01 +0000

Los principios SOLID son una parte fundamental del desarrollo de software y son esenciales para crear aplicaciones sólidas y escalables. Fueron introducidos por el ingeniero de software Robert C. Martin, y cada uno de ellos aborda un aspecto específico del diseño de software. En el contexto de ReactJS, aplicar estos principios puede ayudar a crear una arquitectura más cohesiva y modular, lo que puede resultar en un código más fácil de mantener y de modificar.

En este artículo, vamos a explorar los cinco principios SOLID y cómo se aplican específicamente en ReactJS.
Cubriremos ejemplos prácticos de cómo aplicar cada principio y discutiremos por qué son importantes para el desarrollo de aplicaciones de calidad. Ya seas un desarrollador principiante o experimentado, esperamos que este artículo te brinde información útil sobre cómo aplicar los principios SOLID en ReactJS. ¡Comencemos!

Responsabilidad Única (Single Responsibility Principle): Este principio establece que una clase o componente debe tener una única responsabilidad. Esto significa que una clase o componente debe tener una sola razón para cambiar. Al aplicar este principio, se puede mejorar la modularidad de una aplicación y hacer que el código sea más fácil de mantener y de entender. En ReactJS, esto se traduce en asegurarse de que cada componente tenga una función única y no se responsabilice de demasiadas tareas. Por ejemplo, dividir un componente de lista de tareas en componentes más pequeños que se encarguen de mostrar cada tarea individualmente.

Imaginemos que tenemos un componente llamado TodoList que muestra una lista de tareas. El componente TodoList también se encarga de manejar la lógica para agregar nuevas tareas y eliminar tareas existentes. Sin embargo, esto viola el principio de Responsabilidad Única, ya que el componente está manejando múltiples responsabilidades.

Para aplicar el principio de Responsabilidad Única, podemos dividir el componente TodoList en componentes más pequeños y especializados. En lugar de manejar toda la lógica de la lista de tareas en un solo componente, podemos crear componentes más pequeños y especializados para manejar tareas individuales y para agregar y eliminar tareas.

A continuación, te mostraré un ejemplo de código donde hemos aplicado este principio. Hemos dividido el componente TodoList en componentes más pequeños y especializados que se encargan de tareas individuales y la lógica de agregar y eliminar tareas:

function TodoItem({ task, onRemove }) {
  return (
    <li>
      {task}
      <button onClick={onRemove}>Eliminar tarea</button>
    </li>
  );
}

function useTodoList() {
  const [tasks, setTasks] = useState([]);

  function handleAdd(newTask) {
    if (newTask !== "") {
      setTasks([...tasks, newTask]);
    }
  }

  function handleRemove(index) {
    const newTasks = [...tasks];
    newTasks.splice(index, 1);
    setTasks(newTasks);
  }

  return [tasks, handleAdd, handleRemove];
}

function TodoList() {
  const [tasks, handleAdd, handleRemove] = useTodoList();
  const [newTask, setNewTask] = useState("");

  function handleChange(e) {
    setNewTask(e.target.value);
  }

  function handleAddTask() {
    handleAdd(newTask);
    setNewTask("");
  }

  return (
    <div>
      <ul>
        {tasks.map((task, index) => (
          <TodoItem
            key={index}
            task={task}
            onRemove={() => handleRemove(index)}
          />
        ))}
      </ul>
      <div>
        <input value={newTask} onChange={handleChange} />
        <button onClick={handleAddTask}>Agregar tarea</button>
      </div>
    </div>
  );
}

En este ejemplo, hemos creado un hook personalizado useTodoList que se encarga de manejar la lista de tareas y la lógica para agregar y eliminar tareas. Luego, el componente TodoList utiliza el hook para obtener la lista de tareas y los manejadores handleAdd y handleRemove.

El componente TodoList solo se encarga de renderizar la lista de tareas y manejar las interacciones del usuario, lo que cumple con el principio de Responsabilidad Única.

Al separar la lógica del componente TodoList en un hook personalizado, hemos hecho que el código sea aún más modular y fácil de entender y de mantener. Además, hemos mejorado la reutilización del código, ya que ahora podemos usar el hook useTodoList en cualquier componente que necesite manejar una lista de tareas.

Abierto/Cerrado (Open/Closed Principle): Este principio establece que una clase o componente debe estar cerrado a la modificación pero abierto a la extensión. Esto significa que una clase o componente debe ser fácilmente extensible sin tener que modificar su código existente. En ReactJS, esto significa que deberíamos poder agregar nuevas características a nuestro código sin tener que modificar el código existente.

Para aplicar este principio en React, podemos crear componentes reutilizables que sean fácilmente extensibles sin tener que modificar su código original.

Por ejemplo, supongamos que tenemos un componente Button que se utiliza en varios lugares de nuestra aplicación. Ahora necesitamos agregar una nueva funcionalidad a este componente: agregar un icono junto al texto del botón. En lugar de modificar directamente el código del componente Button, podemos crear un nuevo componente que extienda la funcionalidad del Button original.

Aquí te muestro cómo quedaría el código:

import React from "react";

function Button({ children, ...rest }) {
  return <button {...rest}>{children}</button>;
}

function IconButton({ icon, children, ...rest }) {
  return (
    <Button {...rest}>
      <span>{icon}</span>
      {children}
    </Button>
  );
}

export { Button, IconButton };

Sustitución de Liskov (Liskov Substitution Principle): Este principio establece que las clases o componentes derivados deben poder ser utilizados como instancias de sus clases o componentes base sin requerir ninguna modificación adicional. En otras palabras, cualquier instancia de una clase o componente debe poder ser reemplazada por cualquier instancia de su clase o componente base sin que la aplicación falle. En ReactJS, esto significa que los componentes derivados deben poder ser utilizados en lugar de sus componentes base sin causar problemas. Esto se logra manteniendo una estructura coherente y consistente en todos los componentes.

En cuanto al tercer principio, el principio de Sustitución de Liskov, podemos aplicarlo en React cuando utilizamos los patrones de composición y herencia de componentes. En términos generales, podemos decir que un componente hijo debe poder ser utilizado en lugar de su componente padre sin que se produzca un comportamiento incorrecto en la aplicación.

Un ejemplo sencillo de cómo aplicar este principio en React sería el siguiente:

Supongamos que tenemos un componente llamado Button que se utiliza para renderizar botones en nuestra aplicación. Ahora queremos crear un nuevo tipo de botón, llamado SubmitButton, que tenga un estilo diferente y que sea utilizado para enviar formularios.

Podemos crear el nuevo componente SubmitButton heredando de Button y sobrescribiendo el estilo por defecto:

import React from 'react';
import Button from './Button';

function SubmitButton(props) {
  return (
    <Button
      {...props}
      style={{ backgroundColor: 'green', color: 'white' }}
    />
  );
}

export default SubmitButton;

En este ejemplo, el componente SubmitButton hereda de Button y sobrescribe el estilo por defecto para tener un fondo verde y un texto en blanco. Podemos utilizar este nuevo componente SubmitButton en lugar del componente Button en cualquier parte de nuestra aplicación donde necesitemos un botón de envío.

De esta manera, hemos aplicado el principio de Sustitución de Liskov en nuestro código de React, ya que el componente SubmitButton se comporta como un tipo de botón válido en cualquier lugar donde se necesite un botón, y podemos utilizarlo sin preocuparnos de que el comportamiento de nuestra aplicación cambie de manera inesperada.

Segregación de Interfaces (Interface Segregation Principle): Este principio establece que una clase o componente no debe implementar interfaces o comportamientos que no necesite. En ReactJS, esto significa que deberíamos dividir nuestros componentes en piezas más pequeñas y especializadas, en lugar de crear un componente gigante que haga todo. Por ejemplo, podemos separar un componente de formulario en componentes más pequeños que se encarguen de campos de entrada individuales, y un componente que se encargue de enviar el formulario.

Supongamos que tenemos un componente Header que muestra el título de una página y tiene un botón de navegación. Podríamos dividir este componente en dos partes: Title y NavigationButton, que manejan específicamente el título y el botón de navegación respectivamente.

import React from 'react';

interface HeaderProps {
  title: string;
  onNavigation: () => void;
}

function Header({ title, onNavigation }: HeaderProps) {
  return (
    <div>
      <Title title={title} />
      <NavigationButton onNavigation={onNavigation} />
    </div>
  );
}

interface TitleProps {
  title: string;
}

function Title({ title }: TitleProps) {
  return <h1>{title}</h1>;
}

interface NavigationButtonProps {
  onNavigation: () => void;
}

function NavigationButton({ onNavigation }: NavigationButtonProps) {
  return (
    <button onClick={onNavigation}>
      <span>Go to Next Page</span>
    </button>
  );
}

export default Header;

En este ejemplo, Header se ha dividido en dos partes más pequeñas, Title y NavigationButton, que se encargan específicamente de mostrar el título y el botón de navegación, respectivamente. De esta manera, podemos reutilizar estas partes en otros componentes que necesiten mostrar un título o un botón de navegación sin tener que incluir todo el componente Header.

Inversión de Dependencias (Dependency Inversion Principle): Este principio establece que los componentes de nivel superior no deben depender de los componentes de nivel inferior, sino que deben depender de abstracciones. En ReactJS, esto significa que los componentes no deben depender directamente de otros componentes, sino de abstracciones como los props o state. También es importante utilizar patrones de inyección de dependencias para evitar acoplamientos excesivos entre componentes.

Supongamos que tenemos un componente UserList que muestra una lista de usuarios y permite eliminar usuarios haciendo clic en un botón. En lugar de hacer que el componente UserList dependa directamente de una API de usuarios, podemos utilizar una interfaz UserRepository que nos permita acceder a los datos de los usuarios y hacer que la dependencia de UserList sea de la interfaz en lugar de la implementación concreta de la API. De esta manera, podemos cambiar fácilmente la implementación de la interfaz sin tener que cambiar el código del componente UserList.

import React, { useState, useEffect } from 'react';

interface User {
  id: number;
  name: string;
  email: string;
}

interface UserRepository {
  getUsers(): Promise<User[]>;
  deleteUser(id: number): Promise<void>;
}

interface UserListProps {
  userRepository: UserRepository;
}

function UserList({ userRepository }: UserListProps) {
  const [users, setUsers] = useState<User[]>([]);

  useEffect(() => {
    userRepository.getUsers().then((users) => setUsers(users));
  }, [userRepository]);

  function handleDeleteUser(id: number) {
    userRepository.deleteUser(id).then(() => {
      setUsers(users.filter((user) => user.id !== id));
    });
  }

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>
          <span>{user.name}</span>
          <button onClick={() => handleDeleteUser(user.id)}>Delete</button>
        </li>
      ))}
    </ul>
  );
}

export default UserList;

En este ejemplo, el componente UserList utiliza la interfaz UserRepository para acceder a los datos de los usuarios y eliminar usuarios. Ahora podemos proporcionar diferentes implementaciones de UserRepository dependiendo de nuestra necesidad, como una API de usuarios o una simulación de datos en memoria, y el componente UserList funcionará sin cambios en su código.

En resumen, la aplicación de los principios SOLID en React ayuda a crear componentes más cohesivos, flexibles y fáciles de mantener. Cada principio SOLID tiene un propósito específico que ayuda a mejorar la calidad del código y a reducir errores. La correcta aplicación depende del contexto del proyecto, pero su uso puede marcar una gran diferencia en la calidad del software.

Flutter y el patrón Provider

Asiel Alonso — Fri, 25 Jun 2021 21:39:06 +0000

Hola mundo!!

Introducción

Tanto si desarrolla una aplicación nativa como una híbrida, el manejo del estado es un problema que debemos enfrentar y tener bajo control. Para administrar el estado global de una aplicación en Flutter existen varias maneras, en este post abordaremos Provider, una biblioteca bastante popular que nos ayudará con este trabajo.

Aplicación de ejemplo

Para ver el funcionamiento de Provider, vamos a realizar una sencilla aplicación que nos ejemplifique.
Esta app muestra una pantalla con un AppBar y su título, en el centro un Text, y dos botones flotantes en la esquina inferior derecha, que tendrán como función cambiar el valor del texto que será mostrado tanto en el título del AppBar como en el Text del body de la app.
Tenemos en cuenta que el valor del texto será administrado de manera global.

Dejo el link del ejercicio para quien desee descargarlo:
https://github.com/hextiandro/flutter_provider_pattern

Manos a la obra

Primeramente instalaremos la biblioteca: provider: ^5.0.0 (En el momento que escribí el post esta era la versión).
La podemos encontrar en: https://pub.dev/packages/provider

Dentro de lib creamos una carpeta llamada widgets y dentro un archivo llamado floating_actions.dart, lib/widgets/floating_actions.dart para crear el widget con los dos botones flotantes:

import 'package:flutter/material.dart';

class FloatingAction extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
 (context);
    return Column(
      mainAxisAlignment: MainAxisAlignment.end,
      children: <Widget>[
        FloatingActionButton(
            child: Icon(Icons.wifi),
            backgroundColor: Colors.orange,
            onPressed: () {}),
        SizedBox(
          height: 10.0,
        ),
        FloatingActionButton(
            child: Icon(Icons.bluetooth),
            backgroundColor: Colors.blue,
            onPressed: () {})
      ],
    );
  }
}

Notemos que el onPressed lo tenemos sin acción, más adelante agregaremos su funcionalidad.

Ahora dentro de lib/widgets crearemos otro archivo llamado body, lib/widgets/body.dart para crear el widget con el texto centralizado.

import 'package:flutter/material.dart';

class Body extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    (context);
    return Center(
      child: Text("",
        style: TextStyle(fontSize: 20),
      ),
    );
  }
}

El texto mostrado por ahora es la cadena vacía.
Crearemos otro widget dentro de lib, llamado home lib/Home.dart:

import 'package:flutter/material.dart';

class Home extends StatelessWidget {
  @override
  Widget build(BuildContext context) {

    return Scaffold(
      appBar: AppBar(
        title: Center(child: Text("")),
      ),
      body: Body(),
      floatingActionButton: FloatingAction(),
    );
  }
}

Aquí estamos renderizando un Scaffold, con un AppBar y su título vacío por el momento, además renderizamos los widgets Body y FloatingAction creados anteriormente.
Nada de Provider aún, solo vamos armando la interfaz gráfica de la app, pasemos a modificar el main.dart.

Nuestro archivo main.dart debería lucir así por el momento:

import 'package:flutter/material.dart';
import 'package:provider_pattern/home.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Provider',
      home: Home()
    );
  }
}

Con esto tenemos todo listo para comenzar a construir nuestro Provider; hagamos lo siguiente:

Dentro de lib creamos otro directorio llamdo provider y dentro un archivo llamado signal_mode.dart, lib/provider/signal_mode.dart

import 'package:flutter/material.dart';

class SignalMode extends ChangeNotifier {
  String _signalMode = 'Wifi mode';

  String get signalMode => _signalMode;

  set signalMode(String mode) {
    this._signalMode = mode;
    notifyListeners();
  }
}

Listo, este es nuestro Provider, es la clase que se ocupa de centralizar el valor de la variable privada _signalMode de tipo String que es el texto que se mostrará tanto en el título del AppBar como en el centro de la pantalla.

Notemos el primer detalle que extiende de ChangeNotifier clase encargada de exponer los eventos de notificación,
veamos que tenemos un método get para obtener el valor de _signalMode, y un método set para modificarlo, dentro de este método vemos la llamada a notifyListeners() que es quien va a notificar a todos los widgets que escuchen a este provider del cambio, para asi actualizar su estado.

Es momento de encapsular aquellos widgets que van a escuhar los cambios.
Como queremos tener el control del estado en todos los niveles de la aplicación lo haremos en el main.
Tenga en cuenta que no necesariamente se debe envolver en el nivel más alto de la aplicación en caso que desees compartir determinado estado para determinado nivel.
Si modificamos nuestro main quedaría de la siguiente forma:

import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
import 'package:provider_pattern/home.dart';
import 'package:provider_pattern/provider/signal_mode.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ChangeNotifierProvider(
      create: (_) => SignalMode(),
      child: MaterialApp(
          title: 'Provider', 
          home: Home()),
    );
  }
}

De esta manera toda la app está en condiciones de escuchar los cambios de la clase SignalMode

Desde ahora ya podemos integrar los distintos widgets de nuestra app. Modifiquemos la clase FloatingAction para conectarla con nuestro Provider quedando de la siguiente forma:

import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
import 'package:provider_pattern/provider/signal_mode.dart';

class FloatingAction extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final signal = Provider.of<SignalMode>(context);

    return Column(
      mainAxisAlignment: MainAxisAlignment.end,
      children: <Widget>[
        FloatingActionButton(
            child: Icon(Icons.wifi),
            backgroundColor: Colors.orange,
            onPressed: () {
              signal.signalMode = "Wifi mode";
            }),
        SizedBox(
          height: 10.0,
        ),
        FloatingActionButton(
            child: Icon(Icons.bluetooth),
            backgroundColor: Colors.blue,
            onPressed: () {
              signal.signalMode = "Bluetooth mode";
            })
      ],
    );
  }
}

Notemos aquí en la siguiente línea:

  final signal = Provider.of<SignalMode>(context);

de esta manera obtenemos una instancia de nuestro Provider especificando que es de tipo SignalMode.

El otro punto a notar aquí es en el onPressed de los botones, cada uno hace una llamada modificando el valor de signalMode

onPressed: () {
 signal.signalMode = "Wifi mode";
})

onPressed: () {
 signal.signalMode = "Bluetooth mode";
})

De esta manera podemos modifcar el estado global, ahora solamente debemos mostrar los valores, veamos como:

import 'package:flutter/material.dart';
import 'package:provider_pattern/provider/signal_mode.dart';
import 'package:provider_pattern/widgets/body.dart';
import 'package:provider_pattern/widgets/floating_actions.dart';
import 'package:provider/provider.dart';

class Home extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final signal = Provider.of<SignalMode>(context);

    return Scaffold(
      appBar: AppBar(
        title: Center(child: Text(signal.signalMode)),
      ),
      body: Body(),
      floatingActionButton: FloatingAction(),
    );
  }
}

En la clase Home igualmente obtenemos la instancia del Provider y leemos la propiedad signalHome.

De la misma forma lo hacemos en la clase Body:

import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
import 'package:provider_pattern/provider/signal_mode.dart';

class Body extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final signal = Provider.of<SignalMode>(context);
    return Center(
      child: Text(
        signal.signalMode,
        style: TextStyle(fontSize: 20),
      ),
    );
  }
}

Ya, es todo!!

Hemos finalizado nuestro ejemplo, pero les dejaré una última consideración para la utilización de múltiples providers tendríamos que modificar nuevamente nuestro main de la siguiente forma:

void main() => runApp(AppState());

class AppState extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MultiProvider(
      providers: [
       ChangeNotifierProvider(create: (_) => SignalMode())
       ],
      child: MyApp(),
    );
  }
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
     title: 'Provider', 
     home: Home()
    );
  }
}

Percatarse aquí como MultiPorvider admite un arreglo de Provider:

providers: [
 ChangeNotifierProvider(create: (_) => SignalMode())
],

Conclusiones

Hasta aquí este post, espero haberme explicado bien y de alguna manera haberle sido útil, nos vemos en la próxima!!

Chao Mundo!!