DEV Community: Emerson Vieira

Android Lifecycle vs. React Native

Emerson Vieira — Wed, 11 Feb 2026 17:32:47 +0000

Recentemente, acompanhei uma discussão em uma issue do Expo, mais especificamente sobre o expo-video, o modo fullscreen e o método exitFullscreen (implementação).

Problemática: você tenta executar um comando via JS enquanto o player está em fullscreen (por exemplo, fechar o player automaticamente ao final do vídeo) e... nada acontece. O diagnóstico imediato costuma ser: "O Android pausa o JS quando a Activity principal sai do topo, por isso o exitFullScreen não funciona."

Spoiler: Tem muita confusão entre Activity e Processo nessa história.

O equívoco do onPause e onStop

No Android, quando você entra em modo Fullscreen, geralmente uma nova Activity é criada para o player. A Activity principal (onde o JS nasceu) entra em onPause ou onStop.

Muita gente acha que onPause na Activity = Pausa no motor JavaScript.

A real é que o Android não pausa o motor JS (Hermes/JSC) só porque a Activity pausou. O que acontece é uma questão de prioridade de recursos:

Se a Activity principal não está visível, o Android "desprioriza" timers (setTimeout, setInterval).
O motor JS continua lá, mas o agendamento de tarefas fica na geladeira pra economizar bateria.

Processo vs. Activity

Se o app está mostrando um vídeo em Fullscreen, o processo do app ainda tem prioridade de Primeiro Plano (Foreground Priority).

O sistema operacional sabe que o app está ativo e visível. O motor JS está pronto para trabalhar, ele só não vai "se esforçar" por conta própria (timers).

Como "acordar" o JS?

Se você precisa que o JS execute algo (como fechar o player) enquanto outra Activity está por cima, a solução é parar de confiar em tempo e passar a confiar em Sinais do Sistema.

Eventos disparados pelo lado Nativo (como um callback de "vídeo terminou") conseguem furar a fila da "despriorização" do JS. O sinal viaja do Nativo -> Bridge/JSI -> JS, e o motor processa isso na hora, mesmo com a Activity principal em onPause.

Moral da história: O JS não está morto, ele só está esperando um motivo real (um evento nativo) para agir.

Você está gastando mais RAM do que pediu: Lições de baixo nível para React Native

Emerson Vieira — Fri, 16 Jan 2026 11:43:18 +0000

Ontem caí num post excelente do Daniel Lemire (se você curte performance e não conhece ele, pare tudo e vá ler). O texto é sobre C++ e alocadores de memória, mas enquanto lia, só conseguia pensar no impacto disso na New Architecture do React Native.

O resumo da ópera do Lemire é simples: malloc(n) quase nunca aloca n bytes.

Se você pede 30 bytes, o sistema operacional provavelmente vai te entregar 40, 48 ou 64. Existe um "imposto" de metadados e alinhamento (padding) que a gente esquece.

Não acredita? A Prova Real

Em JavaScript, a gente não vê isso porque a engine abstrai tudo. Mas em C++ (que roda por baixo dos seus TurboModules), podemos perguntar diretamente ao Sistema Operacional quanto ele realmente reservou.

Se você rodar esse snippet C++ simples num ambiente Linux (ou Android via shell):

#include <iostream>
#ifdef __APPLE__
    #include <malloc/malloc.h>
    #define GET_SIZE malloc_size
#else
    #include <malloc.h>
    #define GET_SIZE malloc_usable_size
#endif

int main() {
    size_t pedido = 30; // Pedindo 30 bytes
    void* ponteiro = malloc(pedido);

    size_t recebido = GET_SIZE(ponteiro);

    std::cout << "--- Prova do Overhead ---" << std::endl;
    std::cout << "Você pediu: " << pedido << " bytes" << std::endl;
    std::cout << "O SO alocou: " << recebido << " bytes" << std::endl;
    std::cout << "Desperdício: " << (recebido - pedido) << " bytes (" 
              << ((recebido - pedido) * 100.0 / recebido) << "%)" << std::endl;

    free(ponteiro);
    return 0;
}

O Resultado (no meu Linux):

Você pediu: 30 bytes
O SO alocou: 40 bytes
Desperdício: 10 bytes (25%)

Nota: No macOS/iOS, esse valor costuma pular para 48 bytes devido a regras diferentes de alinhamento.

Por que isso acontece?

Header (Metadados): O sistema precisa de bytes "invisíveis" antes do seu dado para saber o tamanho do bloco na hora de dar o free().
Padding (Alinhamento): A CPU odeia ler endereços quebrados. O alocador arredonda tudo (geralmente para múltiplos de 8 ou 16 bytes) para garantir performance.

Agora, o que isso tem a ver com seu app? Tudo, especialmente agora que estamos movendo tanta lógica para JSI e Native Modules.

1. O Custo Oculto da Ponte (JSI)

Com a chegada dos TurboModules e JSI, a gente se acostumou a ouvir que a comunicação JS <-> Nativo ficou "instantânea" porque não tem mais a serialização da Bridge antiga.

Mas existe um custo de memória.

Quando você decide passar um array gigante de objetos pequenos do JS para o C++ (digamos, 10.000 itens de telemetria), cada objeto criado no lado nativo invoca o alocador do sistema.

Se cada item tem 30 bytes de dados úteis, você viu no teste acima que vai pagar por 40 bytes (ou mais). Multiplique isso por 100 mil objetos. Você está desperdiçando megabytes de RAM só com ar (padding) e metadados de controle.

A lição:
Se for passar dados massivos via JSI, evite "picotar" os dados. Prefira passar um único ArrayBuffer ou uma String longa e fazer o parse no C++. Uma alocação grande de 1MB tem um overhead percentual minúsculo (apenas alguns bytes de header) comparado a 50 mil alocações pequenas.

2. iOS e Android não concordam sobre memória

O artigo do Lemire mostra como diferentes sistemas operacionais têm estratégias diferentes.

O Linux/Android tende a usar alocadores como Scudo ou jemalloc, que são eficientes mas ainda possuem overhead (como vimos nos 25% de desperdício acima).
O iOS (baseado em Darwin) usa "zonas" e costuma ser ainda mais agressivo no arredondamento, às vezes pulando para múltiplos de 512 bytes em certas faixas.

A lição:
Não confie cegamente que o consumo de memória que você vê no Xcode Simulator será igual no Android ou num iPhone físico. O simulador roda sobre o alocador do macOS. Se você está trabalhando com manipulação de imagens ou buffers de áudio na unha, testar em dispositivo real é obrigatório. O que cabe na memória no Android pode estourar (OOM) no iOS por pura questão de como o SO arredonda os bytes.

3. A Regra das Potências de 2 (Power of 2)

Isso é velho, mas o post reforça. Se você aloca um buffer de imagem de 4097 bytes, é bem provável que o sistema te dê 8192 bytes (4KB x 2) ou algo próximo de 5KB, dependendo da página de memória. Você cruzou a linha invisível do alocador por 1 byte e pagou o dobro.

No React Native, isso afeta quem usa bibliotecas como react-native-blob-util ou manipuladores de stream.

A lição:
Sempre que estiver definindo tamanhos de chunks para upload ou leitura de arquivos, tente alinhar com potências de 2 (4096, 8192, 16384). É o jeito mais seguro de garantir que o que você pediu é (quase) o que o sistema alocou.

4. Contexto importante: quando se preocupar (e quando não)

Não precisa otimizar prematuramente:

Aplicativos com pouca lógica nativa
Componentes que não manipulam grandes volumes de dados
Apps que já performam bem dentro dos limites de memória

Vale a pena investigar:

Módulos nativos que processam listas com 10.000+ itens
Manipulação de imagens/áudio/vídeo no lado nativo
Apps com uso intensivo de JSI para transferência de dados
Problemas recorrentes de Out Of Memory em apenas uma plataforma

Conclusão

Não precisa ficar paranoico e tentar gerenciar cada byte do seu app feito em React Native. O Hermes já faz muita mágica por nós para otimizar o heap do JavaScript.

O overhead de alocação é real, mas não é motivo para pânico. A chave está no equilíbrio:

Para 95% dos apps: O Hermes e a engine JavaScript já fazem otimizações excelentes. Foque em escrever código limpo e só otimize quando identificar problemas reais.
Para os 5% com lógica nativa crítica: Entenda como a memória funciona nas plataformas-alvo. Teste em dispositivos reais. Use estruturas de dados contíguas para grandes volumes.
Regra geral: Prefira uma alocação grande a muitas alocações pequenas. Este princípio simples resolve a maioria dos problemas de overhead.

Lembre-se: pedir memória ao sistema operacional é igual pedir comida em rodízio — sempre vem um pouco mais do que você pediu, e a conta chega no final.

Leu algo interessante sobre performance mobile recentemente? Deixa aí nos comentários.

React Native em Alta Performance: Expo Modules, C++ e SIMD (ARM NEON)

Emerson Vieira — Mon, 05 Jan 2026 10:49:16 +0000

Você já sentiu que o JavaScript "pediu arrego" ao tentar processar algo pesado no React Native? Seja manipulando milhares de pixels em tempo real ou processando áudio, o loop do JS muitas vezes não é suficiente.

Neste artigo, vou mostrar como construí o Expo Chroma, um app que remove o fundo verde (Chroma Key) de imagens usando o Expo Modules SDK, C++ e instruções SIMD (ARM NEON) para alcançar uma performance que o JavaScript puro jamais conseguiria.

Repositório do Projeto: mensonones/ExpoChromaApp

O que é SIMD e por que ele importa?

Se você nunca ouviu falar de SIMD (Single Instruction, Multiple Data), pense nele como uma linha de montagem ultra-eficiente.

Historicamente, o conceito surgiu nos anos 70 com supercomputadores (como o lendário Cray-1), mas chegou aos nossos computadores e celulares nos anos 90 e 2000 (com tecnologias como MMX, SSE e AVX na Intel, e NEON na ARM).

Na programação convencional (Escalar), se você quer somar dois vetores de 4 números, você faz 4 somas separadas. Com SIMD, você carrega os dois vetores em registradores especiais e executa uma única instrução que soma todos os números de uma vez. É a base de quase tudo que exige performance hoje: processamento de vídeo, jogos 3D, criptografia e, claro, Inteligência Artificial.

O Coração do Projeto: C++ SIMD (ARM NEON)

O grande diferencial deste projeto é o uso de SIMD (Single Instruction, Multiple Data).

Em um processador comum, para remover o verde de 16 pixels, você faria 16 verificações sequenciais. Com ARM NEON (presente em quase todos os Androids e iPhones), processamos esses 16 pixels (64 bytes) simultaneamente em um único ciclo de CPU.

Por que exatamente 16 pixels?

A matemática é simples e fascinante:

Os registradores NEON têm 128 bits de largura.
Cada canal de cor (R, G, B ou A) é um uint8 (8 bits).
128 / 8 = 16.

Isso significa que o tipo uint8x16_t que usamos no código é, literalmente, um vetor que carrega 16 valores de uma vez. Quando fazemos uma comparação, o hardware compara os 16 valores em paralelo no nível elétrico do silício.

Veja como fica o kernel em C++:

#include <arm_neon.h>

extern "C" void processChromaKey(uint8_t* data, size_t length) {
    size_t numPixels = length / 4;
    size_t i = 0;

    // Definimos o threshold fora do loop para máxima performance
    uint8x16_t threshold = vdupq_n_u8(30);

    for (; i + 15 < numPixels; i += 16) {
        uint8_t* ptr = data + (i * 4);

        // Carrega 16 pixels desintercalando os canais (R, G, B, A)
        uint8x16x4_t rgba = vld4q_u8(ptr);

        // Lógica: Verde > (Vermelho + 30) && Verde > (Azul + 30)
        uint8x16_t r_plus_th = vqaddq_u8(rgba.val[0], threshold);
        uint8x16_t b_plus_th = vqaddq_u8(rgba.val[2], threshold);

        uint8x16_t mask_r = vcgtq_u8(rgba.val[1], r_plus_th);
        uint8x16_t mask_b = vcgtq_u8(rgba.val[1], b_plus_th);
        uint8x16_t is_green = vandq_u8(mask_r, mask_b);

        // Zera o Alpha (torna transparente) onde for verde
        rgba.val[3] = vbicq_u8(rgba.val[3], is_green);

        // Salva de volta na memória
        vst4q_u8(ptr, rgba);
    }
    // ... fallback para pixels restantes
}

Integrando com Kotlin (Android)

Para que o C++ converse com o Android sem lentidão, usamos o JNI e DirectBuffers. Isso permite que o C++ manipule a memória do Bitmap do Android diretamente, sem criar cópias desnecessárias.

AsyncFunction("processImageBase64") { base64String: String ->
  // ... decodificação do bitmap

  // Aloca um DirectBuffer para acesso direto do C++
  val byteBuffer = ByteBuffer.allocateDirect(mutableBitmap.byteCount)
  mutableBitmap.copyPixelsToBuffer(byteBuffer)

  // Chama o kernel C++ otimizado
  nativeProcessImage(byteBuffer, mutableBitmap.byteCount)

  // ... retorna para o JS
}

Resultados e Benchmarks

O benchmark mede o tempo de processamento bruto de um buffer de 8MB (equivalente a uma imagem 2K em RGBA). Isso isola a performance do algoritmo, ignorando custos de decodificação de arquivos ou renderização na tela.

Nos testes realizados em um dispositivo intermediário:

JS Puro (Hermes): ~320ms (estável entre 321ms e 326ms nas execuções seguintes)
C++ Nativo (Escalar): ~4ms (caindo para 2ms após o warm-up)
C++ Nativo (SIMD): ~2ms (caindo para 1ms após o warm-up)

O Fenômeno do "Warm-up": Por que a segunda vez é mais rápida?

Se você rodar o benchmark no app, notará algo curioso: a primeira execução é sempre mais lenta que as seguintes. Por exemplo, o C++ Escalar pode começar em 4ms e cair para 2ms, enquanto o SIMD cai de 2ms para 1ms.

Isso acontece por três motivos técnicos:

CPU Frequency Scaling: Para economizar bateria, o Android mantém a CPU em "repouso". Quando o código pesado começa, o sistema leva alguns milissegundos para subir a frequência do processador ao máximo.
CPU Cache: Na primeira vez, os dados saem da RAM (lenta). Nas execuções seguintes, os pixels já estão no Cache L1/L2 do processador, que é ordens de grandeza mais rápido.
Branch Prediction: O processador "aprende" o padrão dos seus ifs. Após a primeira volta, ele já sabe prever quais pixels serão transparentes, evitando pausas no fluxo de execução (pipeline stalls).

Isso prova que:

Mover para o Nativo já elimina o overhead do Garbage Collector e do motor JS, sendo 80x a 160x mais rápido que o Hermes.
Usar SIMD extrai o máximo de poder do hardware, dobrando a performance do C++ comum ao processar dados em paralelo no nível do silício.

Conclusão

O React Native, através do ecossistema Expo, evoluiu para uma plataforma onde o limite não é mais o JavaScript. Se você precisa de performance extrema, não tenha medo de descer para o C++. O Expo Modules SDK torna essa ponte (ou melhor, esse JSI) muito mais simples de implementar.

O código completo deste projeto está disponível no GitHub: mensonones/ExpoChromaApp

A Arquitetura e Estrutura do Módulo

Para este projeto, criei um Expo Module local localizado em modules/expo-chroma/. Esta é a estrutura recomendada para manter o código nativo organizado:

cpp/: Contém o núcleo em C++ com os kernels SIMD.
android/ e ios/: Implementações nativas que expõem o C++ para cada plataforma via JNI/Swift.
src/: A camada TypeScript que define a API consumida pelo React Native.

Utilizamos a JSI (JavaScript Interface) do Expo Modules SDK. Isso permite que o JavaScript chame as funções nativas de forma síncrona e direta, eliminando o overhead da antiga "Bridge" e permitindo a passagem de buffers de memória de forma ultra-eficiente.

Gostou do conteúdo? Deixe um comentário sobre qual tarefa pesada você adoraria ver rodando nativamente no seu app! 🚀

A Portfolio Powered by Gemini & Antigravity

Emerson Vieira — Sat, 03 Jan 2026 15:51:07 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

I'm Emerson Vieira, a Mobile Engineer and Software Developer dedicated to building robust, high-performance, and secure applications. My journey is driven by a passion for solving complex architectural challenges and creating seamless user experiences. With this portfolio, I wanted to showcase how AI can be integrated into a professional developer's workspace to enhance both development speed and user interaction.

Portfolio

Note: If the embed above doesn't load correctly, you can access it directly at: https://portfolio-316545967978.us-central1.run.app

How I Built It

My portfolio was built with a modern and secure architecture focused on performance. The source code is available on GitHub.

Frontend: React 19, TypeScript, Vite, and Tailwind CSS for a premium UI with smooth micro-animations.
Backend Proxy: Node.js and Express serving as a secure gateway for API calls to protect sensitive credentials.
Infrastructure: Containerized with Docker and deployed to Google Cloud Run using the official Google AI community labels.
Google AI Tools:
- Antigravity: Developed using Google's AI-first development environment, which significantly boosted productivity through intelligent coding assistance.
- Gemini 1.5 Flash: Integrated via the @google/generative-ai SDK to power an interactive career assistant.

One of the key design decisions was to move all API interactions to the backend. This keeps API keys secure and allowed for a custom in-memory caching layer to handle GitHub's rate limits and ensure a fast, responsive UX.

dev

What I'm Most Proud Of

I'm most proud of the integration between the AI Assistant and my real-world data. By combining the Gemini model with a secure proxy to my GitHub activity, I created a functional "Digital Twin" that can answer technical questions about my repositories and professional history in real-time.

Solving technical hurdles like CORS and rate-limiting through a custom backend proxy was a rewarding challenge that resulted in a much more stable and professional product.

Developed with ❤️ using Antigravity and Google AI.

Android 15 e Páginas de 16KB: Performance Turbinada para Seus Apps React Native

Emerson Vieira — Sat, 10 May 2025 18:23:43 +0000

Com a chegada do Android 15, uma das novidades mais interessantes "por baixo do capô" é o suporte aprimorado para páginas de memória de 16KB. Pode parecer um detalhe técnico, mas o impacto na performance dos aplicativos, incluindo os desenvolvidos com React Native, pode ser bem expressivo!

Vamos entender o que isso significa e como nós, desenvolvedores React Native, podemos nos beneficiar.

O que são Páginas de Memória (e por que 16KB é legal)?

De forma simplificada, o sistema operacional gerencia a memória RAM em blocos chamados "páginas". Tradicionalmente, o Android utilizava páginas de 4KB. O Android 15 está expandindo o suporte e incentivando o uso de páginas de 16KB em dispositivos compatíveis.

Por que isso importa?

Menos "Viagens": Com páginas maiores, o sistema precisa gerenciar um número menor de páginas para a mesma quantidade de memória. Isso pode reduzir a sobrecarga e o número de "falhas de página" (page faults) – que ocorrem quando o sistema precisa buscar dados que não estão na memória imediata.

Os Benefícios Concretos das Páginas de 16KB no Android 15:

O Google estima que o uso de páginas de 16KB pode levar a:

⚡ Inicialização de apps até 30% mais rápida!
🚀 Inicialização do sistema (boot) até 8% mais veloz.
📉 Redução no consumo de energia em alguns casos, devido à menor atividade de gerenciamento de memória.
👍 Melhora geral na responsividade do sistema.

Para os usuários, isso se traduz em uma experiência mais fluida e rápida ao usar seus dispositivos e aplicativos.

E o React Native com Isso?

O React Native 0.77 (lançado no início de 2025) e versões posteriores já trazem suporte para o Android 15 e, crucialmente, para o build de apps que utilizam essas páginas de 16KB.

https://reactnative.dev/blog/2025/01/21/version-0.77

Isso significa que, ao utilizar uma versão compatível do React Native e compilar seu aplicativo para o Android 15 (API de nível 35), seus usuários em dispositivos Android 15 compatíveis com páginas de 16KB poderão experimentar esses ganhos de performance sem que você, desenvolvedor, precise fazer grandes alterações no seu código JavaScript!

O Que Isso Significa Para Você, Desenvolvedor React Native?

Mantenha-se Atualizado: Garanta que seus projetos estejam utilizando o React Native 0.77 ou superior para tirar proveito dessa otimização.
TargetSDK para Android 15: Ao preparar seu app para o Android 15, defina o targetSdkVersion para 35. A Google Play exigirá que novos apps e atualizações direcionados ao Android 15 suportem páginas de 16KB a partir de 1º de novembro de 2025.
Teste: Como sempre, teste seus aplicativos em dispositivos, de preferência físicos, ou emuladores com Android 15 para garantir que tudo funcione como esperado e para observar os ganhos de performance.
Benefício "Transparente": Para a maior parte, o benefício das páginas de 16KB será "transparente" uma vez que seu ambiente e targetSDK estejam configurados corretamente. O ganho vem da forma como o sistema operacional e a JVM (para o código nativo) gerenciam a memória.

Conclusão

O suporte a páginas de 16KB no Android 15 é um passo importante para otimizar o desempenho em todo o ecossistema Android. É excelente ver que o React Native já está alinhado, permitindo que nossos aplicativos ofereçam uma experiência ainda melhor e mais rápida para os usuários finais.

E aí, o que achou dessa novidade? Já está se preparando para o Android 15 nos seus projetos React Native? Comente abaixo! 👇

Hacktoberfest

Emerson Vieira — Fri, 27 Sep 2024 00:30:37 +0000

O que é o Hacktoberfest?

O Hacktoberfest é o evento anual da DigitalOcean que incentiva as pessoas a contribuírem para o código aberto durante o mês de outubro. Grande parte da infraestrutura tecnológica moderna — incluindo alguns dos produtos da DigitalOcean — depende de projetos de código aberto criados e mantidos por pessoas apaixonadas que geralmente não têm equipe ou orçamento para fazer muito mais do que manter o projeto vivo. O Hacktoberfest tem tudo a ver com retribuir a esses projetos, aprimorar habilidades e celebrar todas as coisas de código aberto, especialmente as pessoas que tornam o código aberto tão especial.

Ao contribuir, você estará ajudando a fortalecer a comunidade open source e colaborando para o crescimento de projetos que podem impactar milhões de usuários!

Como Participar?

Participar da Hacktoberfest é simples. Siga esses passos:

Inscreva-se no site oficial da Hacktoberfest. (entre 23 de setembro e 31 de outubro)
Encontre repositórios de código aberto no GitHub ou GitLab que estejam marcados com a tag hacktoberfest. Você também pode procurar por issues que aceitam contribuições de iniciantes (good first issue).
Tente enviar quatro solicitações de pull/merge de alta qualidade entre 1º e 31 de outubro, com os mantenedores do projeto aceitando suas solicitações de pull/merge para que sejam contabilizadas em seu total
Se suas contribuições forem aprovadas e aceitas, você pode ganhar um emblema digital personalizável da Holopin que ganha novas características com cada uma de suas solicitações de pull/merge. Conforme cada solicitação de pull/merge que você enviou for aceita pelos mantenedores, você desbloqueará um novo nível e personalização para seu emblema, até as quatro solicitações de pull/merge para concluir o Hacktoberfest.

Não sabe por onde começar?

Se você é novo em contribuições open source ou está procurando um bom ponto de partida, aqui estão algumas dicas:

Contribua para a documentação: Muitos projetos precisam de melhorias em sua documentação, e isso é uma ótima maneira de começar sem precisar mergulhar de cabeça no código.
Resolva pequenos bugs: Comece com problemas menores. A comunidade geralmente rotula esses problemas com tags como good first issue ou beginner-friendly.
Sugira melhorias: Muitas vezes, projetos open source estão abertos a novas ideias e melhorias. Se você encontrar uma maneira de otimizar ou melhorar o desempenho de um projeto, crie um PR!

Para mais detalhes acesse: https://hacktoberfest.com/participation/

Benefícios de Participar

Aprimore suas habilidades: Participar da Hacktoberfest é uma excelente maneira de aprender novas tecnologias e praticar desenvolvimento em um ambiente colaborativo.
Networking: Ao contribuir com projetos open source, você pode conhecer outros desenvolvedores ao redor do mundo e até mesmo criar conexões valiosas para a sua carreira.
Seja recompensado: Além de contribuir para a comunidade, você estará ganhando experiência e construindo uma boa reputação para processos seletivos, onde contribuições open source são bem vistas.

Dicas Para Contribuir com Sucesso

Leia as diretrizes do projeto: Antes de fazer um PR, certifique-se de ler e seguir as contribuições exigidas pelo repositório.
Seja paciente: Lembre-se de que os mantenedores de projetos open source são voluntários, e pode levar um tempo até que eles revisem sua contribuição.
Seja educado e colaborativo: Contribuir para o open source envolve trabalhar com outras pessoas. Mantenha sempre uma comunicação clara e respeitosa com os mantenedores e outros colaboradores.

Vamos Colaborar! 💻

Agora que você sabe tudo sobre a Hacktoberfest, o que está esperando? Participe e ajude a construir o futuro do open source! Compartilhe suas experiências, desafios e aprendizados com a comunidade dev, e não se esqueça de celebrar suas conquistas!

Happy Coding! 🎉👨‍💻👩‍💻

Memory Leak em React Native

Emerson Vieira — Thu, 15 Aug 2024 21:12:23 +0000

O que é Memory Leak?

Memory leak (vazamento de memória) ocorre quando uma aplicação não libera a memória que não está mais em uso, fazendo com que o consumo de memória aumente continuamente. No React Native, isso pode causar problemas de desempenho, como travamentos, queda de FPS e, em casos graves, a aplicação pode ser fechada pelo sistema operacional.

Causas Comuns de Memory Leak em React Native

Componentes não desmontados corretamente: Quando um componente continua a "viver" mesmo após ser removido da árvore de componentes.
Event Listeners não removidos: Listeners continuam ativos mesmo após o componente ser desmontado.
Timers (setTimeout ou setInterval): Se não forem limpos corretamente, esses timers continuarão ativos, mesmo quando não forem mais necessários.
Async Operations (Promises, Fetch, Axios): Promessas ou requisições assíncronas que continuam sendo resolvidas ou rejeitadas mesmo depois de o componente ser desmontado.
Referências circulares: Isso acontece quando dois objetos fazem referência um ao outro, impedindo o coletor de lixo de liberar a memória corretamente.

Como Identificar Memory Leaks?

Algumas técnicas para detectar vazamentos de memória em aplicações React Native incluem:

Uso do DevTools do React Native: Monitore o uso de memória no profiler.
Ferramentas de análise de desempenho: No Android, o Android Studio Profiler ajuda a rastrear o uso de memória.
Alertas de uso excessivo de memória: O monitoramento de erros em produção com ferramentas como Sentry pode ajudar a identificar padrões de aumento de memória.

Como Prevenir Memory Leaks?

Desmonte corretamente os componentes: Certifique-se de limpar timers, listeners e operações assíncronas no componentWillUnmount (ou no retorno do useEffect).
Uso do AbortController com Axios ou Fetch: Para garantir que uma requisição seja cancelada quando o componente desmonta.
Gerencie corretamente dependências no useEffect: Assegure-se de que a lista de dependências do useEffect está correta para evitar chamadas desnecessárias e possíveis vazamentos.
Limpe os estados: Ao desmontar o componente, garanta que as operações que dependem de um estado sejam adequadamente tratadas, evitando a atualização de estados em componentes desmontados.

Exemplo

// HomeScreen.tsx
import React, { useEffect, useState } from "react";
import { View, Button } from "react-native";
import checkLocationPermission from "./location";

const HomeScreen = ({ navigation }) => {
  const [hasPermission, setHasPermission] = useState(false);

  useEffect(() => {
    const checkPermission = async () => {
      const permission = await checkLocationPermission();
      setHasPermission(permission);
    };

    checkPermission();
  }, []);

  if (!hasPermission) {
    return null;
  }

  return (
    <View style={{ padding: 20 }}>
      <Button
        title="Ir para Mapa"
        onPress={() => navigation.navigate("Map")}
        disabled={!hasPermission}
      />
    </View>
  );
};

export default HomeScreen;

O código de exemplo da HomeScreen realiza a verificação das permissões de acesso à localização do dispositivo e, em seguida, redireciona o usuário para a tela de Mapa (MapScreen).

// MapScreen.tsx
import React, { useEffect, useState, useCallback, useRef } from "react";
import { View, Button, Text } from "react-native";
import MapView, { Marker } from "react-native-maps";
import Geolocation from "@react-native-community/geolocation";

const MapScreen = ({ navigation }) => {
  const [location, setLocation] = useState({
    latitude: 37.78825,
    longitude: -122.4324,
    latitudeDelta: 0.005,
    longitudeDelta: 0.005,
  });
  const [errorMsg, setErrorMsg] = useState(null);
  const [loading, setLoading] = useState(true);
  const [isLocationValid, setIsLocationValid] = useState(false);
  const watchId = useRef(null);

  const getGpsLocation = useCallback(() => {
    console.log("Iniciando escuta de localização...");
    watchId.current = Geolocation.watchPosition(
      (position) => {
        if (position && position.coords) {
          const { latitude, longitude } = position.coords;
          setLocation({
            latitude,
            longitude,
            latitudeDelta: 0.005,
            longitudeDelta: 0.005,
          });
          setLoading(false);
          setIsLocationValid(true);
          console.log("Localização atualizada:", position);
        } else {
          console.error("Posição ou coordenadas não definidas");
        }
      },
      (error) => {
        console.error("Error getting GPS location:", error);
        setErrorMsg(error.message);
        setLoading(false);
      },
      {
        enableHighAccuracy: true,
        timeout: 30000,
        maximumAge: 10000,
        distanceFilter: 0,
        interval: 5000,
        fastestInterval: 5000,
      },
    );
  }, []);

  useEffect(() => {
    getGpsLocation();

    /* return () => {
      if (watchId.current !== null) {
        Geolocation.clearWatch(watchId.current);
        console.log('Escuta de localização removida');
        watchId.current = null; // Resetar para evitar limpeza dupla
      }
    }; */
    return () => {
      // A escuta de localização não será removida, causando um memory leak
      console.log(
        "Componente desmontado, mas a escuta de localização continua",
      );
    };
  }, [getGpsLocation]);

  return (
    <View style={{ flex: 1 }}>
      {isLocationValid ? (
        <MapView
          style={{ flex: 1 }}
          initialRegion={{
            latitude: location.latitude,
            longitude: location.longitude,
            latitudeDelta: location.latitudeDelta,
            longitudeDelta: location.longitudeDelta,
          }}
          loadingEnabled={loading}
          region={{
            latitude: location.latitude,
            longitude: location.longitude,
            latitudeDelta: location.latitudeDelta,
            longitudeDelta: location.longitudeDelta,
          }}
          showsUserLocation={true}
        >
          <Marker
            coordinate={{
              latitude: location.latitude,
              longitude: location.longitude,
            }}
            title="Sua localização"
          />
        </MapView>
      ) : (
        <View
          style={{ flex: 1, justifyContent: "center", alignItems: "center" }}
        >
          <Text>Obtendo localização...</Text>
        </View>
      )}
      <View style={{ padding: 20 }}>
        {errorMsg && <Text>{errorMsg}</Text>}
        <Button title="Voltar para Home" onPress={() => navigation.pop()} />
      </View>
    </View>
  );
};

export default MapScreen;

O código exemplo de MapScreen, um memory leak ocorre porque a escuta de localização (Geolocation.watchPosition) não é limpa corretamente quando o componente MapScreen é desmontado. Isso faz com que a aplicação continue a escutar a localização mesmo quando o componente já não está em uso, resultando em um consumo desnecessário de memória.

Ao abrir a tela de Mapa e obter a localização, ao voltar para a tela Home, a coleta da posição continua sendo realizada. Isso pode ser observado no console através do seguinte log da tela de Mapa: console.log('Localização atualizada:', position);.

A correção é simples: basta limpar a escuta de localização no retorno da função useEffect:

useEffect(() => {
  getGpsLocation();
  return () => {
    if (watchId.current !== null) {
      Geolocation.clearWatch(watchId.current);
      console.log("Escuta de localização removida");
      watchId.current = null; // Resetar para evitar limpeza dupla
    }
  };
}, [getGpsLocation]);

Projeto de Exemplo

ReactNativeMemoryLeak

Conclusão

Memory leaks podem impactar severamente a experiência do usuário em uma aplicação React Native. Identificar e mitigar esses vazamentos é essencial para manter uma performance estável e evitar problemas maiores, como travamentos ou encerramento inesperado da aplicação. Ao seguir boas práticas, como desmontar corretamente os componentes e cancelar operações assíncronas, você pode evitar a maioria dos problemas de vazamento de memória.

React Native: Turbo Modules

Emerson Vieira — Mon, 25 Mar 2024 00:26:33 +0000

React Native: Nova Arquitetura

Ao longo do post, você irá se deparar com termos/conceitos com o qual pode não estar familiarizado, então faz-se necessário algum entendimento. Abaixo um link para leitura:

React Native — Ultimate Guide on New Architecture in depth

O que são Turbo Modules

"TurboModules são a próxima iteração de módulos nativos que oferecem alguns benefícios extras, em particular esses módulos usam JSI, uma interface JavaScript para código nativo, que permite uma comunicação mais eficiente entre código nativo e JavaScript do que a ponte".

Fonte: Turbo Modules

Turbo Modules são módulos nativos otimizados que facilitam o acesso à API nativa do dispositivo e outros recursos. Eles permitem a integração entre a camada JavaScript e a nativa, usando Java/Kotlin (Android) ou Objective-C/Swift (iOS).

Implementando um módulo nativo com Turbo Modules

Umas das primeiras impressões que tive ao ter contato com Turbo Modules na prática é que é um pouco mais "complicado" de implementar se comparado com a maneira antiga e se quiser ter uma noção de como é, basta acessar o post.

Prática

Iremos criar um módulo nativo que retorne a informação da versão do Android no dispositivo.

1 - Você deve criar uma pasta chamada TurboModulesPractice
2 - Dentro da pasta criada anteriomente, crie uma pasta chamada RTNDeviceInfo ( RTN significa "React Native" e é um prefixo recomendado para módulos React Native)
3 - Ainda na pasta criada no passo 1, crie um novo projeto React Native com o comando abaixo:

npx react-native@latest init DeviceInfoPractice

4 - Dentro da pasta RTNDeviceInfo, crie duas subpastas js e android .

Sua estrutura de pastas deve ficar assim:

TurboModulesPractice
├── DeviceInfoPractice
└── RTNDeviceInfo
    ├── android
    └── js

5 - Dentro da subpasta js que fica dentro da pasta RTNDeviceInfo, crie um arquivo chamado NativeDeviceInfo.ts

NativeDeviceInfo.ts

import type { TurboModule } from "react-native/Libraries/TurboModule/RCTExport";
import { TurboModuleRegistry } from "react-native";

export interface Spec extends TurboModule {
  getAndroidVersion(): Promise<string>;
}

export default TurboModuleRegistry.get<Spec>("RTNDeviceInfo") as Spec | null;

6 - Na raiz da pasta RTNDeviceInfo, crie um arquivo chamado package.json

package.json

{
    "name": "rtn-device-info",
    "version": "0.0.1",
    "description": "Get device info(s) with Turbo Modules",
    "react-native": "js/index",
    "source": "js/index",
    "files": [
      "js",
      "android",
      "!android/build"
    ],
    "keywords": [
      "react-native",
      "android"
    ],
    "license": "MIT",
    "devDependencies": {},
    "peerDependencies": {
      "react": "*",
      "react-native": "*"
    },
    "codegenConfig": {
      "name": "RTNDeviceInfoSpec",
      "type": "modules",
      "jsSrcsDir": "js",
      "android": {
        "javaPackageName": "com.rtndeviceinfo"
      }
    }
  }

Esse arquivo será necessário para a instação do módulo

7 - Crie um arquivo chamado build.gradle na subpasta android que fica dentro da pasta RTNDeviceInfo

build.gradle

buildscript {
  ext.safeExtGet = {
    prop,
    fallback ->
    rootProject.ext.has(prop) ? rootProject.ext.get(prop) : fallback
  }
  repositories {
    google()
    gradlePluginPortal()
  }
  dependencies {
    classpath("com.android.tools.build:gradle:7.3.1")
    classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.22")
  }
}

apply plugin: 'com.android.library'
apply plugin: 'com.facebook.react'
apply plugin: 'org.jetbrains.kotlin.android'

android {
  compileSdkVersion safeExtGet('compileSdkVersion', 33)
  namespace "com.rtndeviceinfo"
}

repositories {
  mavenCentral()
  google()
}

dependencies {
  implementation 'com.facebook.react:react-native'
}

8- Crie uma pasta chamada rtndeviceinfo em: android/src/main/java/com

Sua estrutura de pastas deve ficar assim:

├── android
│ ├── build.gradle
│ └── src
│ └── main
│ └── java
│ └── com
│ └── rtndeviceinfo
│

├── js
│ └── NativeDeviceInfo.ts
└── package.json

9 - Dentro da pasta rtndeviceinfo crie um arquivo chamado DeviceInfoModule.kt

DeviceInfoModule.kt

package com.rtndeviceinfo;
import com.facebook.react.bridge.Promise;
import com.facebook.react.bridge.ReactApplicationContext;
import com.rtndeviceinfo.NativeDeviceInfoSpec;
import android.os.Build;

class DeviceInfoModule(reactContext: ReactApplicationContext) : NativeDeviceInfoSpec(reactContext) {

  override fun getName() = NAME

  override fun getAndroidVersion(promise: Promise) {
    promise.resolve(Build.VERSION.RELEASE)
  }

  companion object {
    const val NAME = "RTNDeviceInfo"
  }
}

10 - Ainda na pasta rtndeviceinfo crie um arquivo chamado DeviceInfoPackage.kt

DeviceInfoPackage.kt

package com.rtndeviceinfo;

import com.facebook.react.TurboReactPackage;
import com.facebook.react.bridge.NativeModule;
import com.facebook.react.bridge.ReactApplicationContext;
import com.facebook.react.module.model.ReactModuleInfo;
import com.facebook.react.module.model.ReactModuleInfoProvider;
import java.util.HashMap;

class DeviceInfoPackage : TurboReactPackage() {
  override fun getModule(name: String, reactContext: ReactApplicationContext): NativeModule? {
    return if (name == DeviceInfoModule.NAME) {
        DeviceInfoModule(reactContext)
    } else {
      null
    }
  }

  override fun getReactModuleInfoProvider(): ReactModuleInfoProvider {
    return ReactModuleInfoProvider {
      val moduleInfos: MutableMap<String, ReactModuleInfo> = HashMap()
      moduleInfos[DeviceInfoModule.NAME] = ReactModuleInfo(
        DeviceInfoModule.NAME,
        DeviceInfoModule.NAME,
        false,  // canOverrideExistingModule
        false,  // needsEagerInit
        true,  // hasConstants
        false,  // isCxxModule
        true // isTurboModule
      )
      moduleInfos
    }
  }
}

Com o que já foi feito até aqui, temos nosso módulo pronto para ser integrado ao projeto React Native, mas ainda falta uma etapa para a integração de fato.

11 - Acesse a pasta DeviceInfoPractice que é a pasta do projeto react native gerado no passo 3
12 - Execute os comandos a seguir:

yarn add ../RTNDeviceInfo
cd android
./gradlew generateCodegenArtifactsFromSchema

Você poderá verificar o resultado desses comandos em:

DeviceInfoPractice/node_modules/rtn-device-info/android/build/generated/source/codegen

Caso exista esse caminho, deu tudo certo na execução dos comandos.

O primeiro comando adiciona o pacote/módulo ao aplicativo. Então, em seguida acessa a pasta android, após isso ele invoca uma tarefa Gradle para criar o código gerado.

Para mais informações: https://github.com/reactwg/react-native-new-architecture

13 - Acesse android/gradle.properties no projeto DeviceInfoPractice e certifique-se de que a propriedade newArchEnabled seja true.

Agora podemos utilizar o Módulo Turbo para usar getAndroidVersion função no aplicativo!

14 - Acesse a pasta do projeto DeviceInfoPractice e abra o arquivo App.tsx e substitua o código com o conteúdo a seguir:

App.tsx

import React, { useEffect, useState } from 'react';
import { SafeAreaView, StatusBar, StyleSheet, Text, View, ActivityIndicator } from 'react-native';
import RTNDeviceInfo from 'rtn-device-info/js/NativeDeviceInfo';

function App(): React.JSX.Element {
  const [result, setResult] = useState<string | null>(null);
  const [loading, setLoading] = useState<boolean>(true);

  useEffect(() => {
    fetchAndroidVersion();
  }, []);

  const fetchAndroidVersion = async () => {
    try {
      const version = await RTNDeviceInfo?.getAndroidVersion();
      setResult(version ?? null);
      setLoading(false);
    } catch (error) {
      console.error('Error fetching Android version:', error);
      setResult(null);
      setLoading(false);
    }
  };

  return (
    <SafeAreaView style={styles.container}>
      <StatusBar barStyle={'dark-content'} />
      <View style={styles.content}>
        <Text style={styles.label}>
          Android version:
        </Text>
        {loading ? (
          <ActivityIndicator style={styles.activityIndicator} size="small" color="#0000ff" />
        ) : (
          <Text style={styles.text}>
            {result ?? 'Failed to fetch Android version'}
          </Text>
        )}
      </View>
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
  },
  content: {
    flexDirection: 'row',
    alignItems: 'center',
  },
  label: {
    marginLeft: 20,
    fontSize: 18,
    fontWeight: 'bold',
  },
  text: {
    marginLeft: 10,
    fontSize: 18,
  },
  activityIndicator: {
    marginLeft: 10,
  },
});

export default App;

Resultado

Espero que ajude a entender um pouco, apesar do post ser mais prático que teórico, então, por isso, não deixe de ler sobre algo que não entendeu e qualquer dúvida, não deixe de comentar! :)

Uma Introdução ao Redux Toolkit Query

Emerson Vieira — Mon, 20 Mar 2023 11:41:29 +0000

Uma Introdução ao Redux Toolkit Query

Parte 1

Segundo seus criadores, o RTK Query é uma poderosa ferramenta de busca e cache de dados. Ele foi projetado para simplificar casos comuns de carregamento de dados em um aplicativo da Web, eliminando a necessidade de escrever manualmente a lógica de busca e armazenamento em cache .

Ele é um complemento opcional incluído no pacote Redux Toolkit e sua funcionalidade é construída sobre as outras APIs no Redux Toolkit.

O RTK Query está incluído na instalação do pacote principal do Redux Toolkit. Está disponível através de um dos dois pontos de entrada abaixo:

import  { createApi }  from  '@reduxjs/toolkit/query'  

/* Ponto de entrada específico do React que gera automaticamente
   hooks correspondentes aos endpoints definidos */
import  { createApi }  from  '@reduxjs/toolkit/query/react'

A consulta RTK inclui estas APIs:

createApi(): o núcleo da funcionalidade do RTK Query. Ele permite que você defina um conjunto de endpoints e descreva como recuperar dados de uma série de endpoints, incluindo a configuração de como buscar e transformar esses dados. Na maioria dos casos, você deve usar isso uma vez por aplicativo, com "uma fatia de API por URL base" como regra geral.
fetchBaseQuery(): Um pequeno wrapper fetchque visa simplificar as solicitações. Pretendido como o recomendado baseQuerypara ser usado createApipara a maioria dos usuários.

Abaixo um exemplo de uso com React

import { createApi, fetchBaseQuery } from "@reduxjs/toolkit/query/react";

export const jediOrderApi = createApi({
  reducerPath: "jediOrderApi",
  baseQuery: fetchBaseQuery({ baseUrl: "http://localhost:8000/" }),
  tagTypes: ["JediOrder"],
  endpoints: (builder) => ({
    getJediOrder: builder.query({
      query: (page = 1) => `starwars?_page=${page}&_limit=5`,
      providesTags: ["JediOrder"],
    }),
    createJedi: builder.mutation({
      query: (jedi) => ({
        url: "starwars",
        method: "POST",
        body: { jedi },
      }),
      invalidatesTags: ["JediOrder"],
    }),
  }),
});

export const {
  useGetJediOrderQuery,
  useCreateJediMutation,
  reducer,
  middleware,
} = jediOrderApi;

A createApi é uma função que permite definir endpoints para uma API, gerar reducers e actions do Redux e configurar outras opções para a API. A fetchBaseQuery é uma função que retorna um adaptador base para fazer solicitações de API com fetch.

A jediOrderApi é criada com a configuração da reducerPath, que é o nome do slice na store do Redux, o baseQuery, que é o adaptador base para fazer as solicitações, tagTypes, que é uma lista de nomes de tags para identificar os dados retornados pela API, e endpoints, que é um objeto com as definições dos endpoints da API.

tagTypes é uma propriedade opcional na configuração da API slice que permite adicionar tags aos dados retornados por uma consulta ou mutação.

As tags são uma maneira de identificar os dados retornados pela API e rastrear seu estado na store do Redux. Isso é especialmente útil quando se trabalha com consultas em cache, pois permite que você atualize facilmente os dados em cache quando eles são alterados no servidor.

tagTypes é um array de strings que define os tipos de tag a serem usados pela API. Por exemplo, em jediOrderApi definido no código acima, tagTypes é definido como ['JediOrder'].

Quando uma consulta ou mutação é executada, as tags especificadas em providesTags ou invalidatesTags são automaticamente geradas para cada tipo de tag definido em tagTypes. Essas tags são adicionadas aos dados retornados ou afetados pela consulta ou mutação, permitindo que eles sejam facilmente rastreados e atualizados na store do Redux.

Nesse caso, existem dois endpoints definidos: getJediOrder e createJedi. O getJediOrder é uma query que retorna uma lista de Jedi em ordem de registro, paginados com 5 Jedi por página. Ele usa o parâmetro page para definir a página a ser buscada e especifica que essa query fornece a tag JediOrder.

O createJedi é uma mutation que cria um novo Jedi. Ele recebe um objeto Jedi como argumento e usa esse objeto para criar uma solicitação POST para a URL starwars. Ele também especifica que essa mutation invalida a tag JediOrder.

Por fim, o código exporta as funções useGetJediOrderQuery e useCreateJediMutation, que são hooks gerados automaticamente pela createApi para executar as queries e mutations definidas na jediOrderApi. Ele também exporta o reducer e o middleware, que são o reducer e o middleware gerados pela createApi para gerenciar o estado da API na store do Redux.

Criando um bot para WhatsApp que se comunica com o Jira

Emerson Vieira — Sun, 26 Feb 2023 18:48:08 +0000

Este projeto faz uso dos seguintes módulos node:

1 - whatsapp-web.js
2 - axios, axios-cookiejar-support e tough-cookie
3 - node-cron
4 - qrcode-terminal

OBS: Crie um projeto node e adicione os módulos acima

Estrutura do Projeto

project
├── services
│   └── api.js
├── utils
│   └── jiraUtils.js
├── index.js
├── jiraClient.js
└── package.json

Código do Projeto

// api.js

const axios = require("axios");
const { wrapper } = require("axios-cookiejar-support");
const { CookieJar } = require("tough-cookie");

const cookieJar = new CookieJar();

axios.defaults.withCredentials = true;
axios.defaults.jar = cookieJar;

const instance = wrapper(
  axios.create({
    baseURL: process.env.JIRA_REST_API_URL,
  })
);

module.exports = instance;

Os módulos axios-cookiejar-support e tough-cookie ajudam a tratar e manipualr cookies.

// jiraClient.js

const instance = require("./services/api");

const loginJira = async () => {
  try {
    const result = await instance.post("/rest/auth/1/session", {
      username: process.env.JIRA_USERNAME;,
      password: process.env.JIRA_PASSWORD,
    });
    if (result.status === 200) {
      console.log("Login realizado com sucesso");
      return true;
    }
  } catch (error) {
    console.log("Erro ao realizar o login:", error.message);
  }
  return false;
};

const getIssue = async (id) => {
  const result = await instance.get(`/rest/api/2/issue/${id}`);
  return result;
};

const jiraClient = async (id) => {
  try {
    const result = await instance.get("/rest/auth/1/session");
    if (result) {
      console.log("Sessão ativa");
      const issue = await getIssue(id);
      return issue;
    }
  } catch (error) {
    if (error.response.status === 401) {
      console.log("Não autorizado");
      const loginResult = await loginJira();
      if (loginResult) {
        return jiraClient(id);
      } else {
        throw error;
      }
    } else {
      console.log("Erro ao obter a sessão:", error);
      throw error;
    }
  }
};

module.exports = jiraClient;

// jiraUtils.js

const jiraClient = require(".././jiraClient");

const JIRA_REMINDER_MESSAGE = "Não esquecer de logar as horas no Jira!";

const makeResponseJira = async (id) => {
  try {
    const jiraIssue = await jiraClient(id);
    return `Issue: ${jiraIssue?.data?.key}\nLabel: ${jiraIssue?.data?.fields?.labels[0]}\nAssignee: ${jiraIssue?.data?.fields?.assignee?.name}\nDescription: ${jiraIssue?.data?.fields?.description}`;
  } catch (error) {
    if (error.response.status === 404) {
      return `Issue ${id} não encontrada!`;
    }
    if (error.response.status === 401) {
      return `Verifique suas credenciais!`;
    }
  }
};

const processMsgReceived = async (msg) => {
  let response;
  if (msg.body.startsWith("DEV-")) {
    response = await makeResponseJira(msg.body);
  } else if (msg.body.startsWith("!lembrete")) {
    response = JIRA_REMINDER_MESSAGE;
  } else {
    return null;
  }
  return response;
};

module.exports = processMsgReceived;

OBS: DEV refere-se ao padrão de nomenclatura das issues do Jira durante os testes
Exemplo de issue: DEV-100

// index.js 

const qrcode = require("qrcode-terminal");
const { Client, MessageMedia, LocalAuth } = require("whatsapp-web.js");
const cron = require("node-cron");
const processMsgReceived = require("./utils/jiraUtils");

const GROUP_ID = process.env.WPP_GROUP_ID;
const JIRA_LOGO_URL =
  "https://visuresolutions.com/wp-content/uploads/2022/07/Logo-Jira.png";
const JIRA_REMINDER_MESSAGE = "Não esquecer de logar as horas no Jira!";

const newBotClient = async () => {
  const client = new Client({ authStrategy: new LocalAuth() });
  return client;
};

const botJira = async (client) => {
  client.initialize();

  client.on("qr", (qr) => {
    qrcode.generate(qr, { small: true });
  });

  client.on("authenticated", () => {
    console.log("AUTHENTICATED");
  });

  client.on("ready", async () => {
    console.log("Client is ready!");
    cron.schedule(
      "0 17 * * *",
      async () => {
        // running a task every day 17 hrs
        const media = await MessageMedia.fromUrl(JIRA_LOGO_URL);
        let message = JIRA_REMINDER_MESSAGE;
        client.sendMessage(GROUP_ID, media, {
          caption: message,
        });
      },
      {
        scheduled: true,
        timezone: process.env.TIMEZONE || "America/Sao_Paulo",
      }
    );
    client.on("message", async (message) => {
      const processedMsg = await processMsgReceived(message);
      console.log("processedMsg MSG: ", processedMsg);
      if (processedMsg !== null) {
        const media = await MessageMedia.fromUrl(JIRA_LOGO_URL);
        const response = client.sendMessage(message.from, media, {
          caption: processedMsg,
        });

        return response;
      }
    });
  });
};

const startBot = async () => {
  try {
    const client = await newBotClient();
    botJira(client);
    console.log("Bot started!");
  } catch (error) {
    console.log("ERROR INIT BOT: ", error);
  }
};

startBot();

Alguns pontos a serem explicados:

1 - Ao Startar o projeto, será exibido um QR Code no terminal. Você deverá ler o mesmo utilizando a conta do WhatsApp que será o bot.
2 - GROUP_ID refere-se ao grupo do WhatsApp em que o bot será adicionado para responder.
3 - cron.schedule é utilizado para disparar um lembrete todo dia às 17hrs

Link do projeto: https://github.com/mensonones/bot-jira-tutorial

Por hora é isso! Espero que seja útil e qualquer dúvida basta comentar ou entrar em contato comigo. Até a próxima :)

Consumindo API GraphQL usando React Native e Apollo Client

Emerson Vieira — Sun, 15 May 2022 19:35:50 +0000

No tutorial de hoje, iremos consumir uma API GraphQL usando React Native e Apollo Client.

A API GraphQL será a seguinte: https://rickandmortyapi.com/graphql

Vamos à prática!

Crie um projeto usando npx react-native init NomeProjeto e após isso adicione as dependências abaixo

yarn add graphql @apollo/client@3.2.5

Observação: @apollo/client@3.2.5 essa versão específica pois há um bug nas versões mais novas que impede o pleno funcionamento da mesma no RN.

Estrutura do projeto

Editar o arquivo metro.config.js como no exemplo abaixo

/**
 * Metro configuration for React Native
 * https://github.com/facebook/react-native
 *
 * @format
 */
const { getDefaultConfig } = require("metro-config");
const { resolver: defaultResolver } = getDefaultConfig.getDefaultValues();

module.exports = {
  resolver: {
    ...defaultResolver,
    sourceExts: [...defaultResolver.sourceExts, "cjs"],
  },
  transformer: {
    getTransformOptions: async () => ({
      transform: {
        experimentalImportSupport: false,
        inlineRequires: true,
      },
    }),
  },
};

src/service/index.js

import { ApolloClient, InMemoryCache } from "@apollo/client";

const client = new ApolloClient({
  uri: "https://rickandmortyapi.com/graphql",
  cache: new InMemoryCache(),
});

export default client;

src/queries/index.js

import { gql } from "@apollo/client";

const INFO_PERSON = gql`
  query {
    characters {
      results {
        id
        name
        gender
        image
      }
    }
  }
`;

export default INFO_PERSON;

src/App.js

/**
 * Sample React Native App
 * https://github.com/facebook/react-native
 *
 * @format
 * @flow strict-local
 */

import React from "react";

import Home from "./src/screens/Home";

import { ApolloProvider } from "@apollo/client";

import client from "./src/service/index";

const App = () => {
  return (
    <ApolloProvider client={client}>
      <Home />
    </ApolloProvider>
  );
};

export default App;

/src/screens/Home.js

import React from "react";
import { View, Text, FlatList } from "react-native";
import { useQuery } from "@apollo/client";
import INFO_PERSON from "../queries";

import Card from "../components/Card";

const Home = () => {
  const { loading, error, data } = useQuery(INFO_PERSON);

  return (
    <View>
      {loading && <Text>Loading...</Text>}
      {error && <Text>Error! {error.message}</Text>}
      {data && (
        <FlatList
          data={data.characters.results}
          renderItem={({ item }) => <Card card={item} />}
          keyExtractor={(item) => item.id}
        />
      )}
    </View>
  );
};

export default Home;

src/components/Card/index.js

import React from "react";
import { View, Text, Image } from "react-native";
import styles from "./styles";

const Card = ({ card }) => (
  <View activeOpacity={1} style={styles.card}>
    <Image
      style={styles.image}
      source={{ uri: card.image }}
      resizeMode="contain"
    />
    <View style={styles.imageDescriptionContainer}>
      <Text style={styles.text}>{`${card.name}, ${card.gender}`}</Text>
    </View>
  </View>
);

export default Card;

src/components/Card/styles.js

import { StyleSheet, Dimensions } from "react-native";
const { height } = Dimensions.get("window");

export default StyleSheet.create({
  card: {
    height: height - 300,
    justifyContent: "center",
    alignItems: "center",
    backgroundColor: "#fff",
    borderRadius: 5,
    shadowColor: "#000",
    shadowOffset: {
      width: 0,
      height: 2,
    },
    shadowRadius: 6,
    shadowOpacity: 0.3,
    elevation: 2,
    marginBottom: 2,
  },
  image: {
    borderRadius: 2,
    flex: 1,
    width: "100%",
    borderColor: "#000",
  },
  imageDescriptionContainer: {
    justifyContent: "flex-end",
    alignItems: "flex-start",
    flexDirection: "column",
    height: "100%",
    position: "absolute",
    left: 10,
    bottom: 10,
  },
  text: {
    textAlign: "center",
    fontSize: 20,
    color: "#fff",
    fontFamily: "Avenir",
    textShadowColor: "#000",
    textShadowRadius: 10,
  },
});

Resultado

Link do projeto: https://github.com/mensonones/ReactNativeGQL

É isso! Qualquer dúvida, sugestão ou crítica, basta comentar abaixo :)

Consumindo API GraphQL usando React e Apollo Client

Emerson Vieira — Mon, 01 Mar 2021 00:08:35 +0000

No tutorial de hoje, iremos consumir uma API GraphQL usando React e Apollo Client.

A API GraphQL será a seguinte: https://rickandmortyapi.com/graphql

Vou deixar abaixo dois links que falam sobre GraphQL e Apollo para quem quiser entender melhor antes de prosseguir com o tutorial

https://adrianolisboa.com/o-minimo-que-voce-precisa-saber-sobre-graphql-para-nao-passar-vergonha-em-uma-conversa/

https://www.redhat.com/pt-br/topics/api/what-is-graphql

Vamos à prática!

Crie um projeto usando CRA(Create React App) e após isso, adicione a dependência abaixo

yarn add graphql @apollo/client

Estrutura do projeto

src/service/index.js

import { ApolloClient, InMemoryCache } from "@apollo/client";

const client = new ApolloClient({
  uri: "https://rickandmortyapi.com/graphql",
  cache: new InMemoryCache(),
});

export default client;

src/querys/index.js

import { gql } from "@apollo/client";

const INFO_PERSON = gql`
  query {
    characters {
      results {
        name
        species
        gender
        image
      }
    }
  }
`;

export default INFO_PERSON;

src/App.js

import { useQuery } from "@apollo/client";

import INFO_PERSON from "./querys/index";

import "./App.css";

function App() {
  const { loading, error, data } = useQuery(INFO_PERSON);

  if (loading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>an error occurred...</p>;
  }

  return (
    <section className="parent">
      {data.characters.results.map((person, index) => (
        <div className="card" key={person.name}>
          <img src={person.image} alt="Avatar" style={{ width: "100%" }} />
          <div className="container">
            <h4>
              <b>{person.name}</b>
            </h4>
            <p>
              <b>GENDER:</b> {person.gender}
            </p>
            <p>
              <b>SPECIE:</b> {person.species}
            </p>
          </div>
        </div>
      ))}
    </section>
  );
}

export default App;

/src/index.js

import React from "react";
import ReactDOM from "react-dom";
import "./index.css";
import App from "./App";
import reportWebVitals from "./reportWebVitals";
import { ApolloProvider } from "@apollo/client";

import client from "./service/index";

ReactDOM.render(
  <React.StrictMode>
    <ApolloProvider client={client}>
      <App />
    </ApolloProvider>
  </React.StrictMode>,
  document.getElementById("root")
);

// If you want to start measuring performance in your app, pass a function
// to log results (for example: reportWebVitals(console.log))
// or send to an analytics endpoint. Learn more: https://bit.ly/CRA-vitals
reportWebVitals();

src/App.css

.parent {
     display: flex;
     flex-wrap: wrap;
     justify-content: space-between;
}
 .card {
     margin: 5%;
     box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2);
     transition: 0.3s;
     width: 20%;
}
 .card:hover {
     box-shadow: 0 8px 16px 0 rgba(0, 0, 0, 0.2);
}
 .container {
     padding: 2px 16px;
}

Resultado

É isso! Qualquer dúvida, sugestão ou crítica, basta comentar abaixo :)