DEV Community: Yago Souza Oliveira

Using ThemeData to create a Light and Dark Theme in Flutter

Yago Souza Oliveira — Thu, 21 Nov 2024 20:35:09 +0000

Dark and Light themes are fundamental concepts in interface design and user experience. While the 'Light Theme' offers a bright and illuminated aesthetic, the 'Dark Theme' provides a softer, low-luminance atmosphere.

The choice between these two themes plays a important role in the usability of applications and websites, impacting not only aesthetics but also visual comfort and efficiency, adapting to user preferences.

In Flutter, ThemeData is the main tool for managing colors in your application, allowing complete interface customization and the implementation of themes such as light and dark mode. We have most of ways to apply that concept in Flutter Apps, this one is a simplify and is especially useful in small apps.

When started a new App Flutter, we have a MaterialApp to start:

  return MaterialApp(
      title: 'My App Name',
      themeMode: ThemeMode.system,
      darkTheme: MyThemeDataDark.themeData,
      theme: MyThemeDataLight.themeData,
      home: const FooBarScreen(),
    );

If you see, we have two themes: the theme, where we input a ThemeData with Light, and the darkTheme.

ThemeData is the best way to share colors and fontstyles. You can see in official article with Flutter here

In this example, we put this in Light Theme:

abstract class MyAppThemeLight {
  static ThemeData themeData = ThemeData(
    primaryColor: const Color(0xFFF2F2F2),
    scaffoldBackgroundColor: const Color(0xFFF2F2F2),
    appBarTheme: const AppBarTheme(
      backgroundColor: Color(0xFFF2F2F2),
      elevation: 0.0,
    ),
    switchTheme: SwitchThemeData(
      trackColor: MaterialStateProperty.all(
        const Color(0xFFB6B6D4),
      ),
    ),
    elevatedButtonTheme: ElevatedButtonThemeData(
      style: ElevatedButton.styleFrom(
        backgroundColor: const Color(0xFF000027),
      ),
    ),
    textButtonTheme: TextButtonThemeData(
      style: TextButton.styleFrom(
        foregroundColor: const Color(0xFF000027),
      ),
    ),
    colorScheme: const ColorScheme(
      brightness: Brightness.light,
      primary: Colors.white,
      onPrimary: Color(0xFF000027),
      secondary: Color(0xFF000027),
      onSecondary: Color(0xFFF5F5F8),
      error: Color(0xFF721C24),
      onError: Color(0xFFF5C6CB),
      background: Color(0xFFF5F5F8),
      onBackground: Color(0xFFF5F5F8),
      surface: Colors.white,
      onSurface: Colors.black,
    ),
    textTheme: GoogleFonts.montserratTextTheme(
      const TextTheme(
        titleMedium: TextStyle(
          color: Colors.white,
        ),
      ),
    ),
    fontFamily: GoogleFonts.montserrat().fontFamily,
    useMaterial3: true,
  );
}

Please note that we have some specific themes for widgets, like ElevatedButton and Switch. It is important to have these themes minimally defined as it reduces the redundancy of colors and attributes.

The ColorScheme is your best friend. The Primary Color and Secondary of ThemeData is good, but not cover all situations. The ColorScheme get others options and is easly to access this in componentes:

SizedBox(
   height: 25.0,
   width: 25.0,
   child: CircularProgressIndicator(
            color: Theme.of(context).colorScheme.primary,
  ),
)

When you build the two themes, choice the colors with de Dark theme and input this in MaterialApp.

Put themeMode: ThemeMode.system we look for the Operational System and apply the theme selected by the user in there. If the user set you SO in Light Mode, Flutter get this information and apply the theme data.

And that's it! We have a Dark and Light mode in our app. But if we need to switch in the app the theme, not depending for the selection in OS? Well, in this case, we need a more steps.

First, we need to save the choice of the user and see if has selected every time the app is initializated. We can use the package Shared Preferences to do that. In the main method, before to called a Material app we do:

void main() async {
  ThemeMode themeMode = ThemeMode.system;
  final Future<SharedPreferences> prefsInstance =
      SharedPreferences.getInstance();
  final SharedPreferences prefs = await prefsInstance;
  final bool? isDarkTheme = prefs.getBool('is_dark_theme');
  if (isDarkTheme != null) {
    themeMode = isDarkTheme ? ThemeMode.dark : ThemeMode.light;
  }
  runApp(
    MyApp(
      themeMode: themeMode,
    ),
  );
}

In this example, we initialize the ThemeMode in the main, preventing us from passing null values and using this in the MaterialApp below.

void main() async {
  ThemeMode themeMode = ThemeMode.system;
  final Future<SharedPreferences> prefsInstance =
      SharedPreferences.getInstance();
  final SharedPreferences prefs = await prefsInstance;
  final bool? isDarkTheme = prefs.getBool('is_dark_theme');
  if (isDarkTheme != null) {
    themeMode = isDarkTheme ? ThemeMode.dark : ThemeMode.light;
  }
  runApp(
    MyApp(
      themeMode: themeMode,
    ),
  );
}

Foto de David Clode na Unsplash

Smart e Dumb Components no Flutter: Guia Prático.

Yago Souza Oliveira — Mon, 29 Jul 2024 19:13:47 +0000

Introdução

Em desenvolvimento de software, especialmente em frameworks Javascript como React, Vue e Angular, os conceitos de Smart Components e Dumb Components são fundamentais para a criação de interfaces de usuário mais organizadas, reutilizáveis e eficientes. Mas o que são esses conceitos?

Para ilustrar, vamos imaginar que sua aplicação é um apiário (conjunto de colmeias) e que objetivo da sua aplicação é justamente a produção de mel.

Smart Components

No nosso apiário as abelhas rainhas são os Smart Components. Elas são responsáveis por tomar decisões importantes dentro de cada colmeia. Elas fazem o seu controle, determinam a produção de novas abelhas e organizam as tarefas das abelhas operárias. Elas têm uma visão completa do funcionamento de sua colmeia e gerenciam as operações para garantir que tudo funcione sem problemas. As abelhas rainhas:

Têm muita responsabilidade.
Tomam decisões complexas.
Gerenciam a comunicação entre diferentes partes da colmeia.
Sabem quais tarefas estão sendo executadas e quando precisam ser concluídas.

O papel principal de um Smart Component é gerenciar o estado e a lógica da aplicação ou de parte dela. Isso significa que ele controla como obter as informações, como exibir e como essas informações mudam ao longo do tempo.

Em resumo, Smart Components são a parte ativa e inteligente de uma aplicação. Eles são os responsáveis por fazer com que as coisas aconteçam, respondendo às interações do usuário e às mudanças nos dados.

Um exemplo prático e bem básico utilizando Flutter é a própria tela de contagem de clicks:

class CounterApp extends StatefulWidget {
  @override
  _CounterAppState createState() => _CounterAppState();
}

class _CounterAppState extends State<CounterApp> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Contador'),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text(
              'Você pressionou o botão $_counter vezes',
            ),
            ElevatedButton(
              onPressed: _incrementCounter,
              child: Text('Contar'),
            ),
          ],
        ),
      ),
    );
  }
}

Neste exemplo, o CounterApp é um Smart Component. Ele gerencia o estado do contador _counter, define a lógica para incrementar o contador _incrementCounter e renderiza a interface do usuário.

Dumb Component

Já as abelhas operárias do nosso apiário são os Dumb Components. Elas têm tarefas mais simples e específicas, como coletam néctar, produzem mel e cuidam das larvas.

Apesar da tradução para o português ser "burro", o "dumb" trás a ideia de que esses componentes são mais simples e sem nenhuma regra de negócio, assim como as operárias. Elas não precisam entender o funcionamento completo do apiário ou sequer da colmeia, elas apenas fazem bem suas tarefas com base nas instruções que recebem das abelhas rainhas. As abelhas operárias:

Têm responsabilidade limitada.
Realizam tarefas específicas e repetitivas.
Não tomam decisões complexas.
Dependem das instruções das abelhas rainhas.

Um exemplo disso em Flutter seria um botão customizável que recebe uma cor, um texto e uma função a ser executada ao ser pressionado. Esse botão não sabe o que a função faz, apenas a executa quando necessário:

class CustomButton extends StatelessWidget {
  final Color color;
  final String text;
  final VoidCallback onPressed;

  const CustomButton({
    super.key,
    required this.color,
    required this.text,
    required this.onPressed,
  });

  @override
  Widget build(BuildContext context)  
 {
    return ElevatedButton(
      style: ElevatedButton.styleFrom(
        primary: color,
      ),
      onPressed: onPressed,
      child: Text(text),
    );
  }
}

O uso desse botão, dentro de uma aplicação seria:

class MyHomePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Minha Página'),
      ),
      body: Center(
        child: CustomButton(
          color: Colors.blue,
          text: 'Clique aqui',
          onPressed: () {
            // Lógica a ser executada quando o botão for pressionado
            print('Botão pressionado!');
          },
        ),
      ),
    );
  }
}

Neste exemplo demonstra como criar um componente simples e reutilizável em Flutter, focando apenas na apresentação visual.

E porque usar?

Usar esses conceitos trás diversas vantagens, além de estar alinhada com conceitos do SOLID e do Clean. Como por exemplo:

Separação de responsabilidades: Facilita a compreensão e a manutenção do código;
Reutilização: Dumb Components podem ser usados em diversos lugares;
Teste: Facilita a criação de testes unitários, pois os componentes são mais isolados;
Melhora a performance: Ao separar a lógica da apresentação, é possível otimizar a renderização e alocação de memória;

Conclusão

Ao longo desta conversa, exploramos a fundo os conceitos de Smart e Dumb Components e como eles se relacionam com os princípios SOLID e Clean Code.

Smart Components são os "cérebros" da aplicação, responsáveis por gerenciar o estado, tomar decisões e coordenar outras partes do sistema.
Dumb Components são os "operários" da aplicação, focados em exibir informações na tela de forma clara e concisa.

A analogia com as abelhas e a colmeia é uma forma interessante de visualizar essa divisão de responsabilidades. Cada abelha tem um papel específico, e todas trabalham juntas para o bem da colmeia e do apiario. Da mesma forma, cada componente em uma aplicação tem uma função específica, e todos trabalham juntos para criar uma experiência de usuário coesa.

Em conclusão, a utilização de Smart e Dumb Components é uma prática recomendada para o desenvolvimento de aplicações modernas. Ao entender os princípios por trás dessa abordagem, você será capaz de criar software mais robusto, escalável e fácil de manter.

E ai? Quais outros tópicos você quer ver por aqui? Você concorda, discorda? Deixe seu comentário!

Referência Bibliográfica:

Componentes React: Dumb vs Smart, NCB{code}. Disponível em: https://www.tautorn.com.br/docs/react/dumb-e-smart-components Acesso em 29 de julho de 2024.

Smart e Dumb Components: Maximizando a Eficiência do Desenvolvimento Front-End, ADSON MARTINS. Disponível em: https://medium.com/@adson.martins982/smart-e-dumb-components-maximizando-a-efici%C3%AAncia-do-desenvolvimento-front-end-817acd6f36f1. Acesso em 29 de julho de 2024.

Dumb e Smart Components, TAUTORN. Disponível em: https://www.tautorn.com.br/docs/react/dumb-e-smart-components. Acesso em 29 de julho de 2024.

Foto de Annie Spratt na Unsplash

Train Release: Uma abordagem para entrega de apps mobile

Yago Souza Oliveira — Mon, 27 May 2024 19:16:14 +0000

No contexto de enviar versões de app mobile para loja, um Release Train assume um papel crucial na agilização, padronização e otimização do processo de lançamento. Funciona como um trem em movimento constante, transportando incrementos de valor para os usuários de forma regular e eficiente.

Exemplo de Fluxo de um Train Release de um app mobile

O que é um Train Release

Como o próprio nome sugere, um "Trem de Lançamento" é um fluxo de trabalho que ocorre periodicamente. A analogia com um trem se refere à ideia de que, assim como os trens param em estações para pegar passageiros, os lançamentos periódicos carregam mudanças e correções de software, levando-as até o destino final: o dispositivo do usuário.

Para implementar um Train Release de forma eficaz, primeiro defina os intervalos de tempo para cada estágio de desenvolvimento e determine quanto tempo será dedicado aos testes de integração, testes beta e aos estágios de lançamento. Durante a fase de desenvolvimento, as equipes têm tempo para revisar, testar e mesclar os recursos no branch principal que será incluído no trem. Quando o conteúdo de um lançamento é definido e está pronto, ocorre uma fase final de testes de integração.

Nesta fase, os membros da equipe devem verificar se os novos recursos e correções funcionam conforme esperado. Bugs serão corrigidos e mesclados novamente, se necessário. Um congelamento de código pode marcar o fim de um ciclo de desenvolvimento e o início de outro. As equipes de desenvolvimento podem então iniciar um novo sprint para continuar o processo até o próximo lançamento.

Exemplo de Train Release

Uma empresa está lançando um novo app mobile para iOS e Android. O app oferece funcionalidades para gerenciar tarefas, notas e calendário. A equipe de desenvolvimento utiliza o framework Scrum para gerenciar o projeto e deseja implementar o Release Train para otimizar o processo de lançamento.

Defina o intervalo de tempo: No caso da empresa, por ser uma equipe pequena, ficou definido uma janela de desenvolvimento de quinze dias (duas semanas).
Congelamento do código: Passado o período de desenvolvimento, é criado uma branch do código base naquela data. Até este momento, todos devem ter incluído suas funcionalidades e correções. Não é permitida a adição de novo código na branch de congelada, a não ser que seja para corrigir algo como veremos a seguir.
Entrega para equipe de testes: Um build do app é entregue para a equipe de qualidade da empresa. Eles devem ter os casos de uso definidos e todo o roteiro das funcionalidades novas e antigas, garantindo que tudo esteja funcionando.
Correções: Como a vida não é um morango, a equipe de qualidade pode encontrar problemas e inconsistências. Aqui criamos correções que vão para apenas a branch de congelamento e refazemos os testes.
Disponibilização nas lojas: Após os testes e tudo aprovado, a nova versão é enviada para lojas.
Monitoramento: É muito importante que o app seja monitorado para que possíveis problemas sejam corrigidos o mais rápido possível ou suspender a publicação daquela versão.

Como o Release Train se aplica ao lançamento de apps mobile:

Planejamento em ciclos: O Release Train define ciclos de planejamento regulares com duração fixa, onde cada empresa ou produto escolhem o melhor intervalo. Nesses ciclos, as equipes definem metas, priorizam tarefas e traçam o roteiro para o próximo lançamento.

Sincronização e ritmo constante: Diferente de lançamentos pontuais e desorganizados, o Release Train sincroniza o trabalho de todas as equipes envolvidas, garantindo um ritmo constante de entregas. Isso significa que os incrementos de valor, seja uma nova funcionalidade ou correção de bug, chegam aos usuários com frequência previsível.

Visibilidade e colaboração: O Release Train utiliza ferramentas e práticas para tornar o progresso do trabalho transparente para todos. Isso facilita a identificação e resolução de problemas de forma proativa, além de promover a colaboração e o engajamento entre as equipes.

Foco em entregas frequentes: O objetivo principal do Release Train é a entrega frequente de valor aos usuários. Isso significa que, em vez de esperar por um lançamento grandioso com todas as funcionalidades prontas, o app é lançado com incrementos que oferecem benefícios tangíveis aos usuários a cada ciclo.

Adaptabilidade e feedback: O Release Train é um processo adaptável que se ajusta às necessidades do projeto e do mercado. O feedback dos usuários é coletado e utilizado para aprimorar o app e direcionar o desenvolvimento em iterações futuras.

Benefícios do Release Train para lançamento de apps mobile:

Maior velocidade de lançamento: Com lançamentos frequentes e previsíveis, o Release Train reduz drasticamente o tempo necessário para levar novos recursos e correções aos usuários.
Maior qualidade do app: A entrega frequente de valor permite que os bugs sejam identificados e corrigidos rapidamente, resultando em um app mais estável e confiável.
Maior satisfação do cliente: Ao receber novas funcionalidades e melhorias com frequência, os usuários se sentem mais engajados e satisfeitos com o app.
Maior agilidade e adaptabilidade: O Release Train permite que a equipe responda rapidamente às mudanças nas necessidades do mercado e dos usuários, ajustando o roteiro e priorizando as funcionalidades de acordo com o feedback.

Em resumo, o Release Train é uma ferramenta poderosa para otimizar o lançamento de apps mobile, proporcionando maior velocidade, qualidade, satisfação do cliente e agilidade. Se você busca um processo mais eficiente e eficaz para levar seu app aos usuários, o Release Train pode ser a solução ideal.

Foto de JK na Unsplash

Construindo um BFF usando Shelf e Dart

Yago Souza Oliveira — Mon, 30 Jan 2023 00:02:03 +0000

Introdução

As aplicações mobiles modernas cresceram bastante em funcionalidades e, por consequência, em complexidade. A mesma aplicação pode consumir 8 a 10 serviços para exibir a tela inicial do app. Como manter uma aplicação coesa e de fácil manutenção diante desse cenário? Dai nasce o Backend for Frontend ou BFF.

Mas o que é um BFF?

Um Backend for Frontend (BFF) é uma arquitetura de software que consiste em um ou mais serviços de back-end que são projetados especificamente para atender às necessidades de um aplicativo ou conjunto de aplicativos de front-end. O BFF age como uma camada intermediária entre o aplicativo de front-end e os serviços de back-end existentes, fornecendo uma interface de API personalizada e adaptada para atender às necessidades específicas do aplicativo de front-end.

Os pontos positivos e negativos de usar um BFF

Positivos

Permite aos desenvolvedores de aplicativos front-end se concentrar nas necessidades do usuário, enquanto o BFF se preocupa com as necessidades de comunicação com os serviços de back-end
Possibilidade de criar uma interface de API personalizada e adaptada para o aplicativo de front-end, o que pode melhorar a performance e a escalabilidade do aplicativo
Permite a separação de preocupações entre os desenvolvedores de front-end e back-end, o que pode melhorar a colaboração e a eficiência do time.

Negativos

Adiciona uma camada adicional de complexidade à arquitetura do sistema
Pode haver uma sobrecarga de trabalho adicional para os desenvolvedores, já que eles precisam manter e atualizar tanto o aplicativo de front-end quanto o BFF
Pode exigir mais recursos computacionais para executar o BFF, o que pode afetar a escalabilidade e o custo do sistema.

Casos de Uso

Para saber se essa arquitetura é suficiente para você, abaixo temos alguns casos de uso que podem ajudar na tomada de decisão:

Comunicação com vários serviços de back-end: Quando um aplicativo de front-end precisa se comunicar com vários serviços de back-end diferentes, um BFF pode ser usado para agregar essas chamadas em uma única interface de API personalizada. Isso pode melhorar a performance e a escalabilidade do aplicativo.
Segurança: O BFF pode ser usado para adicionar medidas de segurança, como autenticação e validação de entrada, antes de passar as solicitações para os serviços de back-end.
Caching: O BFF pode ser usado para armazenar dados em cache e reduzir a frequência de chamadas para os serviços de back-end, o que pode melhorar a performance e a escalabilidade do aplicativo.
Transformação de dados: O BFF pode ser usado para transformar os dados retornados pelos serviços de back-end antes de passá-los para o aplicativo de front-end, para que ele possa ser facilmente consumido pelo aplicativo.
Gerenciamento de versão: O BFF pode ser usado para gerenciar diferentes versões de um aplicativo de front-end, permitindo que os desenvolvedores façam mudanças nas APIs sem afetar os aplicativos existentes.
Aplicativos móveis ou de outras plataformas: O BFF pode ser usado para fornecer uma interface de API personalizada para aplicativos móveis ou de outras plataformas, como aplicativos de assistente de voz, para que eles possam se comunicar com os serviços de back-end.

O Shelf

O Shelf é um package para Dart que fornece uma maneira fácil de criar servidores HTTP. Ele fornece uma interface de programação de aplicativos (API) limpa e intuitiva para lidar com requisições e respostas HTTP e permite que os desenvolvedores adicionem middlewares para suportar funcionalidades específicas, como autenticação, validação de entrada, etc.

O Shelf foi projetado para ser simples de usar e escalar facilmente, permitindo que os desenvolvedores possam lidar com cargas de trabalho altas sem prejudicar a performance do servidor. Ele também é fácil de integrar com outros pacotes e bibliotecas do Dart, o que significa que os desenvolvedores podem aproveitar as funcionalidades existentes e aumentar a produtividade.

Shelf para Construção de BFF

Existem várias razões pelas quais o Shelf pode ser uma boa escolha para construir um Backend for Frontend (BFF) usando Dart. Algumas delas incluem:

Simplicidade: O Shelf é projetado para ser simples de usar e possui uma interface de programação de aplicativos (API) limpa e intuitiva. Isso significa que os desenvolvedores podem se concentrar nas funcionalidades do BFF, em vez de lidar com a complexidade de baixo nível da criação de um servidor HTTP.
Flexibilidade: O Shelf é altamente flexível e permite aos desenvolvedores adicionar middlewares para suportar funcionalidades específicas, como autenticação, validação de entrada, etc.
Escalabilidade: O Shelf é projetado para escalar facilmente, permitindo que os desenvolvedores possam lidar com cargas de trabalho altas sem prejudicar a performance do BFF.
Integração: O Shelf é fácil de integrar com outros pacotes e bibliotecas do Dart, o que significa que os desenvolvedores podem aproveitar as funcionalidades existentes e aumentar a produtividade.
Comunidade: O Dart é uma linguagem de programação crescente e tem uma comunidade ativa, o que significa que os desenvolvedores podem obter ajuda e suporte rapidamente quando precisarem.

Considerando esses pontos, o Shelf é uma boa opção para construir um BFF usando Dart, pois ele oferece uma combinação de simplicidade, flexibilidade, escalabilidade e integração com outros pacotes e bibliotecas. Além disso, a comunidade ativa do Dart, garante suporte e suporte para os desenvolvedores.

Construindo o BFF

Nesse tutorial vamos construir um BFF que retorna a idade, o gênero, o país de origem e uma proposta de atividade baseada em um nome.

Para construir o BFF utilizando Dart e Shelf vamos primeiro criar o projeto:

dart create -t server-shelf my_web_app

No arquivo server.dart vamos colocar dessa forma:

import 'dart:io';
import 'package:shelf/shelf.dart';
import 'package:shelf/shelf_io.dart';

import 'app/routes/routes.dart';

void main(List<String> args) async {
  // Use qualquer host disponível ou IP de contêiner (geralmente `0.0.0.0`).
  final ip = InternetAddress.anyIPv4;

  // Configure um pipeline que registra solicitações.
  final handler = Pipeline()
      .addMiddleware(
        logRequests(),
      )
      .addHandler(
        Routes.routes(),
      );

// Para execução em containers, respeitamos a variável de ambiente PORT.
  final port = int.parse(Platform.environment['PORT'] ?? '8080');
  final server = await serve(handler, ip, port);
  print('Server listening on port ${server.port}');
}

Vamos agora criar uma pasta app no mesmo nível do arquivo server.dart e nele criar as seguintes pastas:

app
|-controllers
|-routers
|-models

Dessa forma vamos organizar cada parte do nosso BFF.

Routers

É no arquivo de routers.dart que vamos dizer a nossa aplicação quais rotas vamos receber e qual o controller responsável por ela. Esse arquivo usa o package shelf_routerpara usar suas classes.

import 'package:shelf_router/shelf_router.dart' as shelf_router;

import '../controllers/hello_world_controller.dart';
import '../controllers/name_details_controller.dart';

class Routes {
  static shelf_router.Router routes() {
    final router = shelf_router.Router()
      ..get(
        '/helloworld',
        HelloWorldController.helloWorldHandler,
      )
      ..get(
        '/namedetails',
        NameDetailsController.nameDetailsController,
      );
    return router;
  }
}

Iremos colocar uma rota "Hello World!" e a outra para a rota que irá retornar as informações dos nomes que iremos passar por parâmetro. O método da rota é definido pela função ..get(), caso queira outros adiciona-se post, delete e etc.

Hello World!

Nada mais justo do que começar com um Hello World, e o controller fica muito simples:

import 'dart:convert';

import 'package:shelf/shelf.dart';

class HelloWorldController {
  static helloWorldHandler(Request request) async {
    Map<String, dynamic> response = json.decode(await request.readAsString());
    return Response.ok("Olá, ${response['name']}!");
  }
}

A request vem com todas as informações da requisição feita ao serviço. Nesse caso esperamos no body da requisição um json. Esse mesmo json que vamos usar no nosso controller dos nomes:

{
  "name":"João"
}

O objeto Response é utilizado para determinar qual o status code usado para o caso de sucesso e para tratamento de erro. O método Response.ok() retorna a string com um status code de 200.

Name Controller

Vamos à parte principal, o name_controller.dart. É nele que iremos fazer as requisições e tratamentos para juntar informações de vários servições em um só.

Primeiro, vamos estabelecer as chamadas a cada um dos servições que vamos utilizar:

    Map<String, dynamic> requestBody =
        json.decode(await request.readAsString());

    final urlAge = Uri.https('api.agify.io', '', {'name': requestBody['name']});

    final urlGender =
        Uri.https('api.genderize.io', '', {'name': requestBody['name']});

    final urlNationalize =
        Uri.https('api.nationalize.io', '', {'name': requestBody['name']});

    final urlActivy = Uri.https('boredapi.com', '/api/activity');

    final resultAge = await http.get(urlAge);
    if (resultAge.statusCode > 300) {
      return Response(resultAge.statusCode, body: resultAge.body);
    }

    final resultGender = await http.get(urlGender);
    if (resultGender.statusCode > 300) {
      return Response(resultGender.statusCode, body: resultGender.body);
    }

    final resultNationalize = await http.get(urlNationalize);
    if (resultNationalize.statusCode > 300) {
      return Response(resultNationalize.statusCode,
          body: resultNationalize.body);
    }

    final resultActivity = await http.get(urlActivy);
    if (resultActivity.statusCode > 300) {
      return Response(resultActivity.statusCode, body: resultActivity.body);
    }

Nessa primeira parte pegamos o name do body da requisição e pegamos as informações individualmente em cada serviço. Vamos, nesse primeiro momento, usar a estratégia "tudo ou nada": Se algum serviço falhar iremos retornar o erro desse serviço em específico, mas poderíamos tratar dentro de um try catch ou até criar uma resposta informando somente o erro, fica a cargo do leitor implementar isso para estudos.

Usamos o package "http" já amplamente utilizado para poder fazer as requisições aos serviços.

Depois, para facilitar manipulações dos dados, vamos processar os responses em Models:

    final ageDecode = json.decode(resultAge.body);
    final genderDecode = json.decode(resultGender.body);
    final nationalizeDecode = json.decode(resultNationalize.body);
    final activityDecode = json.decode(resultActivity.body);

    final ageModel = AgeModel.fromJson(ageDecode);
    final genderModel = GenderModel.fromJson(genderDecode);
    final nationModel = NationModel.fromJson(nationalizeDecode);
    final activityModel = ActivityModel.fromJson(activityDecode);

E por fim, a montagem do nosso json de response e o envio para o cliente que solicitou:

    Map<String, dynamic> mapResponse = {
      'name': ageModel.name,
      'age': ageModel.age,
      'gender': genderModel.gender,
      'nationality': nationModel.country?[0].countryId,
      'suggestion_activity': activityModel.activity,
    };

    return Response(
      200,
      body: JsonEncoder.withIndent(' ').convert(mapResponse),
    );

Criamos o nosso Map com as informações coletadas dos serviços e, ao colocar no boddy, precisamos processar esses dados em um json no formato adequado. E pronto, feito nosso processo. Nosso arquivo completo ficaria assim:

import 'dart:convert';

import 'package:shelf/shelf.dart';
import 'package:http/http.dart' as http;

import '../models/activity_model.dart';
import '../models/age_model.dart';
import '../models/gender_model.dart';
import '../models/nation_model.dart';

class NameDetailsController {
  static nameDetailsController(Request request) async {
    Map<String, dynamic> requestBody =
        json.decode(await request.readAsString());
    // final allParams = request.requestedUri.queryParameters;

    final urlAge = Uri.https('api.agify.io', '', {'name': requestBody['name']});

    final urlGender =
        Uri.https('api.genderize.io', '', {'name': requestBody['name']});

    final urlNationalize =
        Uri.https('api.nationalize.io', '', {'name': requestBody['name']});

    final urlActivy = Uri.https('boredapi.com', '/api/activity');

    final resultAge = await http.get(urlAge);
    if (resultAge.statusCode > 300) {
      return Response(resultAge.statusCode, body: resultAge.body);
    }

    final resultGender = await http.get(urlGender);
    if (resultGender.statusCode > 300) {
      return Response(resultGender.statusCode, body: resultGender.body);
    }

    final resultNationalize = await http.get(urlNationalize);
    if (resultNationalize.statusCode > 300) {
      return Response(resultNationalize.statusCode,
          body: resultNationalize.body);
    }

    final resultActivity = await http.get(urlActivy);
    if (resultActivity.statusCode > 300) {
      return Response(resultActivity.statusCode, body: resultActivity.body);
    }

    final ageDecode = json.decode(resultAge.body);
    final genderDecode = json.decode(resultGender.body);
    final nationalizeDecode = json.decode(resultNationalize.body);
    final activityDecode = json.decode(resultActivity.body);

    final ageModel = AgeModel.fromJson(ageDecode);
    final genderModel = GenderModel.fromJson(genderDecode);
    final nationModel = NationModel.fromJson(nationalizeDecode);
    final activityModel = ActivityModel.fromJson(activityDecode);

    Map<String, dynamic> mapResponse = {
      'name': ageModel.name,
      'age': ageModel.age,
      'gender': genderModel.gender,
      'nationality': nationModel.country?[0].countryId,
      'suggestion_activity': activityModel.activity,
    };

    return Response(
      200,
      body: JsonEncoder.withIndent(' ').convert(mapResponse),
    );
  }
}

E assim finalizamos nosso artigo! O projeto completo está neste repositório. Ficou alguma dúvida ou sugestão, só deixar nos comentários abaixo. Até a próxima!

Como configurar Fastlane para Firebase App Distribution (Android e iOS)

Yago Souza Oliveira — Tue, 16 Feb 2021 17:18:15 +0000

Neste post iremos mostrar como configurar o Fastlane para distribuir apps Android e iOS através do Firebase App Distribution. Este artigo é um complemento deste post aqui. Iremos tratar a execução das lanes em um ambiente de CI/CD. É bem similar à execução direto no seu computador, mas em determinados momentos pode ficar confuso. As referências estão no final do artigo.

Configuração no iOS
- Instalar Fastlane
- Escrevendo o Fastfile (iOS)
Configuração no Android
- Instalação do Fastlane
- Escrevendo o Fastfile (Android)
Referências

Configuração no iOS

Instalar Fastlane

Primeiro você deve instalar o fastlane no projeto do iOS fora do Ambiente de CI. A melhor forma é usar o Bundler.

Instale o Ruby no seu Mac. A versão do Ruby utilizada pelo Fastlane tem que estar entre a 2.4 e a 2.7;
Após, crie um arquivo chamado Gemfile sem extensão. É nesse arquivo que vamos colocar as gems (o Fastlane é uma Gem).
Colocado a gem do Fastlane, instalar usando o comando bundle na sua pasta raiz.

source "https://rubygems.org"

gem "fastlane", "~> 2.173"

Feito o bundle e instalando o Fastlane executamos bundle exec fastlane init para iniciar o Fastlane no projeto. Esse comando criará os arquivos do Fastlane dentro do projeto. Algumas perguntas podem ser feitas durante o comando, responda conforme for solicitado (Ex.: ID do Projeto).

Pronto, iniciamos o Fastlane.

Escrevendo o Fastfile (iOS)

O Fastfile é o arquivo onde será colocado toda a sua pipeline. É nele que configuraremos as lanes que serão executadas para gerenciar os certificados, os perfis e enviar para o Firebase.

Primeiro, vamos definir a lane que será executada dentro do CI/CD. Ela que será responsável por chamar todas as demais lanes necessárias.

platform :ios do
    desc "Release app for App Distribution in Firebase"
    lane :send_firebase do

        build_app(
          scheme: 'Runner',
          archive_path: './build/Runner.xarchive',
          export_method: 'ad-hoc',
          output_directory: './build/Runner'
        )

        firebase_app_distribution(
          app: <FIREBASE_APP_ID>,
          groups: 'grupo-ios',
          firebase_cli_token: <FIREBASE_APP_DISTRIBUTION_TOKEN>,
          release_notes_file: 'fastlane/release-notes.txt',
          ipa_path: './build/Runner/Runner.ipa'
        )
    end
end

Aqui podemos definir qual a plataforma que será executada (nesse caso, o iOS), uma descrição (facilita na hora de você ver o que está sendo executado), o nome da Lane e duas actions: o build_app e o firebase_app_distribution.

Como deve ter notado precisaremos de um firebase_cli_token para poder enviar o build para o App Distribution. Você pode criar esse token seguindo esse tutorial aqui.

Nosso projeto é feito em Flutter, a configuração do build_app ficou conforme gerado por ele. Modifique-o conforme sua necessidade.

Agora iremos realizar os outros passos para poder assinar o app e colocar os dispositivos cadastrados dentro do Perfil de Provisionamento.

Como estamos em um ambiente de CI precisamos criar uma keychain para poder instalar todos os certificados. Para isso executamos:

before_all do
  create_keychain(
    name: <KEYCHAIN_NAME>,
    password: <KEYCHAIN_PASSWORD>,
    default_keychain: true,
    unlock: true,
    timeout: 3600,
  )
end

A action before_all irá forçar a criação da Keychain antes de quaisquer outra action ser executada, inclusive da sua lane.
Feito isso, podemos criar nossa Pipeline de forma que:

Atualizaremos os dispositivos
Criaremos ou faremos download dos certificados
Distribuiremos o app assinado

A atualização dos dispositivos é feita com a action register_devices:

lane :update_devices do
  register_devices(
    devices_file: './fastlane/devices.txt'
  )
  profiles
end

Como podem ver, assim que é feito o registro dos dispositivos já chamamos a lane profiles. É nela que vamos criar (ou baixar) os certificados da Apple.

É recomendável que o próprio Fastlane crie e gerencie os certificados em ambiente de CI, porque ele fará todas as ligações entre o certificados, os dispositívos e os perfis de provisionamento. Para isso utilizaremos a action Match.

Para iniciar o Match deve-se executar bundle exec fastlane match init fora do ambiente de CI e seguir as instruções que constam na documentação, escolhendo a melhor forma de armazenar de forma segura esses certificados. São dados três opções: Repositório GIT, Google Cloud ou Amazon S3.
As informações de acesso dos certificados devem ficar armazenadas no Matchfile criado no comando acima.

Iniciando o Match, vamos adicionar a criação (ou o download) dos perfis no Fastfile

lane :profiles do |options|
  match(
    app_identifier: <APP_IDENTIFIER>,
    type: 'development',
    readonly: false,
    force_for_new_devices: true,
    force:options[:force],
    keychain_name: <KEYCHAIN_NAME>,
    keychain_password: <KEYCHAIN_PASSWORD>
  )

  match(
    app_identifier: <APP_IDENTIFIER>,
    type: 'adhoc',
    readonly: false,
    force_for_new_devices: true,
    force:options[:force],
    keychain_name: <KEYCHAIN_NAME>,
    keychain_password: <KEYCHAIN_PASSWORD>
  )
end

Cada Match vai criar o certificado e perfil dos tipos development e adhoc. Usaremos o tipo adhoc para o build que será enviado ao App Distribution.

Certo, estamos quase lá. Agora vamos realizar a etapa onde o Fastlane irá acessar e criar os certificados dentro da AppStore Connect. Para isso iremos criar uma API Key dentro da AppStore Connect. Siga esse tutorial para poder criar a key

Com a Key criada vamos inserir no início da nossa Lane:

app_store_connect_api_key(
  key_id: <key_id>,
  issuer_id: <issuer_id>,
  key_filepath: <caminho_para_chave>,
  in_house: false,
)

Ufa! Depois disso tudo teremos nosso Fastfile completo:

default_platform(:ios)

platform :ios do
    before_all do
      create_keychain(
        name: <KEYCHAIN_NAME>,
        password: <KEYCHAIN_PASSWORD>,
        default_keychain: true,
        unlock: true,
        timeout: 3600,
      )
    end

    lane :update_devices do
        register_devices(
          devices_file: './fastlane/devices.txt'
        )
        profiles
    end

    lane :profiles do |options|
        match(
          app_identifier: <APP_IDENTIFIER>,
          type: 'development',
          readonly: false,
          force_for_new_devices: true,
          force:options[:force],
          keychain_name: <KEYCHAIN_NAME>,
          keychain_password: <KEYCHAIN_PASSWORD>
        )

        match(
          app_identifier: <APP_IDENTIFIER>,
          type: 'adhoc',
          readonly: false,
          force_for_new_devices: true,
          force:options[:force],
          keychain_name: <KEYCHAIN_NAME>,
          keychain_password: <KEYCHAIN_PASSWORD>
        )
    end

    desc "Release app for App Distribution in Firebase"
    lane :send_firebase do

        app_store_connect_api_key(
          key_id: <KEY_ID>,
          issuer_id: <ISSUER_ID>,
          key_filepath: <KEY_PATH>,
          in_house: false,
        )

        update_devices

        build_app(
          scheme: 'Runner',
          archive_path: './build/Runner.xarchive',
          export_method: 'ad-hoc',
          output_directory: './build/Runner'
        )

        firebase_app_distribution(
          app: <FIREBASE_APP_ID>,
          groups: 'grupo-ios',
          firebase_cli_token: <FIREBASE_APP_DISTRIBUTION_TOKEN>,
          release_notes_file: 'fastlane/release-notes.txt',
          ipa_path: './build/Runner/Runner.ipa'
        )
    end
end

Podemos ver todo nosso Pipeline dentro da Lane send_firebase:

Criação da Keychain
Conexão com a AppStore
Atualização dos Dispositivos
Criação / Download e Instalação dos Certificados e Perfis de Provisionamento
Build
Entrega para o App Distribution.

Configuração no Android

Instalação do Fastlane

Primeiro você deve instalar o fastlane no projeto do Android fora do Ambiente de CI. A melhor forma é usar o Bundler.

Instale o Ruby no seu PC. A versão do Ruby utilizada pelo Fastlane tem que estar entre a 2.4 e a 2.7;
Após, crie um arquivo chamado Gemfile sem extensão. É nesse arquivo que vamos colocar as gems (o Fastlane é uma Gem).
Colocado a gem do Fastlane, instalar usando o comando bundle na sua pasta raiz.

source "https://rubygems.org"

gem "fastlane", "~> 2.173"

Feito o bundle e instalando o Fastlane damos bundle exec fastlane init para iniciar o Fastlane no projeto. Esse comando criará os arquivos do Fastlane dentro do projeto. Algumas perguntas podem ser feitas durante o comando, responda conforme for solicitado (Ex.: ID do Projeto).

Pronto, iniciamos o Fastlane.

Escrevendo o Fastfile (Android)

Diferente do iOS, no Android não precisamos de nenhum certificado ou coisas do aspecto para poder enviar nosso APK para o Firebase Distribution. Todo nosso Fastfile compreende:

default_platform(:android)

platform :android do
    desc "Release app for App Distribution in Firebase"
    lane :homologacao_firebase do
        firebase_app_distribution(
            app: <FIREBASE_APP_ID_HOMOLOGACAO>,
            groups: "grupo-android",
            firebase_cli_token: <FIREBASE_APP_DISTRIBUTION_TOKEN>,
            release_notes_file: "fastlane/release-notes.txt",
            apk_path: ".path/to/app.apk"
        )
    end
end

Como deve ter notado precisaremos de um firebase_cli_token para poder enviar o build para o App Distribution. Você pode criar esse token seguindo esse tutorial aqui.

Pronto. Isso é tudo o que precisa para enviar o App Android ao Firebase App Distribution.

Ficamos por aqui. Quaisquer dúvida, sugestão ou erro que tenha encontrado terei total prazer em ajudar e corrigir.

Referências

Distribuir apps para Android para testadores com o fastlane, GOOGLE. Disponível em https://firebase.google.com/docs/app-distribution/android/distribute-fastlane#google-acc-fastlane;

Material de consulta sobre a CLI do Firebase, GOOGLE. Disponível em https://firebase.google.com/docs/cli#cli-ci-systems

Getting started with fastlane for iOS, FASTLANE DOCS. Disponível em https://docs.fastlane.tools/getting-started/ios/setup/

Getting started with fastlane for Android, FASTLANE DOCS. Disponível em https://docs.fastlane.tools/getting-started/android/setup/

Photo by John Torcasio on Unsplash

Flutter + Fastlane + Github Actions

Yago Souza Oliveira — Mon, 15 Feb 2021 18:51:43 +0000

Neste post vamos abordar como configurar o Githbub Actions para realizar build e distribuir via Fastlane.

Não sabe configurar o Fastlane? Então leia aqui.

Primeiro, configuramos o arquivo .yaml para ser usado no Actions. Todos os arquivos das actions devem ficar dentro de .github/workflows na raiz do seu projeto. Estes arquivos serão lidos pelo Github e acionados conforme configurados.

Criado o arquivo test_fastlane.yaml colocamos primeiro:

name: App Distribution With Fastlane

on:
  push:
    branches: [master]

Aqui definimos o nome da Action (isso facilita quando você tem mais de uma e quer filtrar) e a forma como ela vai ser acionada (aqui no caso ela vai executar a cada Pull Request aberto na branch develop).

Definido isso, continuamos:

jobs:
  run_test:
    runs-on: macos-latest

jobs são os trabalhos que serão feitos na execução daquela action. Dentro dele você pode definir o que será instalado, o que vai ser executado e qual Sistema Operacional será utilizado. Vale lembrar que cada job executa de forma simultânea e independente, então não é interessante colocar jobs que sejam interligadas. Mas caso seja necessário utilize-as de forma assíncrona ou realizando dependência entre jobs.

Nos jobs você define o SO em runs-on. Estão disponíveis 3 SOs: Ubuntu, Windows e MacOS.

Depois disso chegou a hora interessante: definir os steps:

 steps:
    - name: Checkout repository
      uses: actions/checkout@v2
    - name: Install Java
      uses: actions/setup-java@v1
      with:
        java-version: ${{ env.java_version }}
    - name: Cache Flutter
      uses: actions/cache@v2
      with:
        path: /opt/hostedtoolcache/flutter
        key: ${{ runner.OS }}-flutter-install-cache-${{ env.flutter_version }}

    - name: Install Flutter    
      uses: subosito/flutter-action@v1
      with:
        flutter-version:  ${{ env.flutter_version }}
    - name: Install dependencies
      run: flutter pub get
    - name: Generate Files
      run: flutter packages pub run build_runner build --delete-conflicting-outputs
    - name: App Test
      run: flutter test
    - name: Build iOS
      run: flutter build ios --no-codesign -t lib/config/main_production.dart

Aqui já colocamos todas as steps necessárias para poder executar os comandos do Flutter. Primeiro utilizamos a action que irá acessar seu repositório, em seguida instalar o Java e, por fim, instalar o Flutter. No Flutter inserimos o cache para que nas próximas execuções ele não precise baixar tudo novamente (lembre que cada minuto no Actions é precioso) e em seguida todos os comandos que forem necessários para realizar build e executar os testes no projeto.

No ambiente em que trabalho preferi definir dois jobs: Um para executar o build do iOS no MacOS e outro para executar o build do Android no Ubuntu. Motivo: 1 min de MacOS consome 10 do seu tempo total no Actions. Os 3min de build do Android que você fizer irá tirar 30 minutos do teu tempo total, portanto, fica mais barato realizar dois jobs (apesar de executarem praticamente os mesmos comandos).

Depois de feito isso podemos executar o Fastlane

    - name: Install Ruby    
      uses: actions/setup-ruby@v1
      with:
        ruby-version: '2.7.2'

    - name: Fastlane iOS        
      uses: maierj/fastlane-action@v2.0.1
      with:
        lane: 'homologacao_firebase'
        subdirectory: 'ios'

Acima instalamos o Ruby e em seguida a Action do Fastlane, indicando o subdirectory e qual a lane iremos executar.

Nas configurações do Fastlane são mais simples pois não nos preocupamos com o build do Flutter, executando exclusivamente as assinaturas e entrega ao Firebase Distribution (no caso do iOS). Essa parte do Fastlane para iOS abordaremos em um outro post.

É isso, qualquer sugestão podem colocar nos comentários que iremos corrigir e acrescentar na medida do possível.

Referências:

Workflow syntax for GitHub Actions, GITHUB. Disponível em: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions. Acesso em 15 de Fevereiro de 2021, às 15:35.

Distribuir apps iOS para testadores com o fastlane, GOOGLE. Disponível em: https://firebase.google.com/docs/app-distribution/ios/distribute-fastlane. Acesso em 15 de Fevereiro de 2021, às 15:37.

Deploying Flutter app to Firebase App Distribution using Fastlane, CODEMAGIC. Disponível em: https://blog.codemagic.io/deploying-flutter-app-to-firebase-app-distribution-using-fastlane/. Acesso em 15 de Fevereiro de 2021, às 15:40.

CI/CD com GitHub Actions + Fastlane LACERDA, Aryella. Disponível em: https://medium.com/naqueles-dias/ci-cd-com-github-actions-fastlane-c4c68c37be88. Acesso em 15 de Fevereiro de 2021, às 15:39.

DEV Community: Yago Souza Oliveira

Using ThemeData to create a Light and Dark Theme in Flutter

Smart e Dumb Components no Flutter: Guia Prático.

Introdução

Smart Components

Dumb Component

E porque usar?

Conclusão

Referência Bibliográfica:

Train Release: Uma abordagem para entrega de apps mobile

O que é um Train Release

Exemplo de Train Release

Como o Release Train se aplica ao lançamento de apps mobile:

Benefícios do Release Train para lançamento de apps mobile:

Construindo um BFF usando Shelf e Dart

Introdução

Mas o que é um BFF?

Os pontos positivos e negativos de usar um BFF

Casos de Uso

O Shelf

Shelf para Construção de BFF

Construindo o BFF

Routers

Hello World!

Name Controller

Como configurar Fastlane para Firebase App Distribution (Android e iOS)

Configuração no iOS

Instalar Fastlane

Escrevendo o Fastfile (iOS)

Configuração no Android

Instalação do Fastlane

Escrevendo o Fastfile (Android)

Referências

Flutter + Fastlane + Github Actions

Photo by Riley McCullough on Unsplash