Esses termos têm sido muito comentados em fóruns e redes sociais dentre os profissionais de tecnologia. Mas antes de começarmos a falar sobre o assunto, precisamos saber qual motivo está levando as pessoas a procurar sobre isso.

Como muita gente sabe, a plataforma Android possui os famosos Broadcast Receivers, barramento de eventos nativo. Eles permitem que o aplicativo se registre para receber eventos do sistema ou de outros aplicativos. Assim, todos os receptores inscritos serão notificados, em tempo de execução, toda vez que um evento ou ação aconteça. Embora esse recurso exista na plataforma, está longe de ser uma arquitetura puramente orientada a eventos.

Mas se esses recursos já estão prontamente disponíveis na própria plataforma, por que não usar? Por que buscar por novos recursos? A resposta a esses questionamentos pode se resumir em duas palavras: intent e sobrecarga.  Ao contrário dos Broadcast Receivers, o Bus utiliza classes Java padrão como eventos e é destinado a casos em que você não quer passar pelo incômodo de criar Intents e preparar extras.

Espere, você está me dizendo que o Bus introduz um novo paradigma de programação? Frameworks ou metodologias que adotamos sempre têm um custo, isso poderia trazer alguma vantagem? Eu digo sim e, para mostrar, quero apresentar algumas limitações com o tradicional desenvolvimento de aplicativos Android.

É comum nos depararmos com aplicações que acabam com uma estrutura como este diagrama:

Activities se comunicam com Fragments, que enviam mensagens para outros Fragments e Services. Tudo isso gera um enorme acoplamento dos componentes, e mudanças que por ventura surgirem podem acabar saindo “caro”. A partir do momento em que novas funcionalidade surgem e a quantidade de código aumenta, a capacidade de manutenção e boas práticas de engenharia de software somem em proporções equivalentes, terminando em algo assim:

Podemos propor uma outra representação do sistema utilizando a programação orientada a eventos:

Nessa arquitetura há um barramento em que diferentes entidades podem se inscrever para ouvir eventos e qualquer um pode produzir um evento, sendo um produtor e um consumidor, respectivamente. Com isso, podemos pensar em diversas possibilidades. Um Fragment poderia atualizar sua tela sem saber a lógica por trás de qualquer operação, basta saber que determinado evento ocorreu. Pense na possibilidade de diminuir o acoplamento e ter uma arquitetura limpa.

Após o fim de toda essa explicação, podemos falar de algumas bibliotecas que ajudam a aplicar a programação orientada a evento em nossas aplicações. Atualmente existem dois barramentos de evento bastante conhecidos: Otto (Square) e EventBus (GreenRobot). Vou tentar abordar as principais características de ambos e deixar que vocês escolham qual Bus utilizar.

• EventBus: É mantido pela GreenRobot. Atualmente encontra-se na versão 2.4.0 e tem como principais características lidar com segmentação, ou seja, eventos podem ser postados em threads diferentes da thread de postagem e trabalhar com herança de eventos, o que significa declarar que uma superclasse trate um evento.
• Otto: É mantido pela Square. Atualmente encontra-se na versão 1.3.7 e possui como principais características a declaração dos eventos por anotação e a extrema facilidade de configuração.

No próximo artigo, vou mostrar como implementar um pequeno projeto utilizando as principais funções do EventBus. Ficou alguma dúvida ou tem alguma coisa a acrescentar? Aproveite o campo abaixo!