Cross Platform Design Pattern

Falar de “Cross Platform” não é novidade em desenvolvimento de softwares (principalmente aplicativos para celular) porém, quase que exclusivamente, são abordados temas relacionados a criação de interfaces, mas chegou a hora de expandirmos um pouco mais essa fronteira, com “Cross Platform Design Pattern”…

Semanas atrás, mais precisamente sexta-feira (21/07/2017), estive no TDC, em São Paulo, “palestrando” sobre este tema e, antes de mais nada, me sinto honrado por, mais uma vez, poder contribuir como palestrante nesse evento fantástico que, com certeza, está entre os maiores eventos do Brasil! Meu muito obrigado pela oportunidade!

O contexto Cross Platform

Assim como mencionei no início do artigo, “Cross Platform” não é uma novidade e ganhou muito destaque no meio mobile com tecnologias como PhoneGap, Ionic, Cordova, Xamarin, etc, que permitem que os desenvolvedores sejam capazes de criar aplicativos que podem ser “compilados” para várias plataformas.

Simplificadamente, uma aplicação “cross platform”, pode ser definida como:

Uma aplicação que pode ser executada em mais de uma plataforma…

Ao dizer “executada”, podemos ir além de simplesmente implementarmos uma fina (ou não tão fina) camada de apresentação Cross Platform, e sim passarmos a conceber uma aplicação Cross Platform, desde suas camadas inferiores (ou internas) e promover o máximo compartilhamento de código possível entre o maior número de plataformas existentes!

Porque o “fator” Cross Platform RARAMENTE vai além da camada de apresentação?

Não há resposta certa para essa pergunta mas, IMHO, a diversidade de ambientes, linguagens, frameworks, tecnologias, etc, envolvidas na pilha de camadas de uma aplicação, tornam o “pensar” Cross Platform em apenas mais uma variável em um contexto tão complexo, onde péssimas decisões podem causar transtornos em disponibilidade, escalabilidade, performance, negócio e por aí vai…

O fato é que, escolher o melhor “stack” para um projeto não é uma tarefa fácil, da escolha das tecnologias até as metodologias, as opções são infinitas e cada um tem uma forma de pensar, pode não ser a melhor forma, mas a “preferência” da equipe ou empresa vai contar muito na tomada de decisão.

“Inaugurando” o padrão “Cross Platform Design Pattern”

Desde meus primeiros caracteres na programação, sempre procurei uma solução para o “problema” de ser “obrigado” a saber várias tecnologias (linguagens de programação, etc) para poder reescrever meus códigos para cada um dos ambientes (sistemas operacionais, etc) que meus softwares precisariam atender, não que isso seja exatamente um problema, pois conhecimento nunca é demais, porém é algo que custa muito tempo e esforço.

Lógico que, em uma empresa de grande porte, com fontes “inesgotáveis” de recursos (pessoais e financeiros, principalmente), esse não é um fator capaz de prejudicar o andamento de um projeto, mas quando se tem um ambiente com escassez extrema de recursos, cada caractere digitado que puder ser reaproveitado fará uma grande diferença no futuro.

Lógico que, em 2000~2002 não haviam tecnologias que permitiam o compartilhamento completo de todo o “stack”, haviam algumas promessas, porém rodavam bem em ambientes “x” e “y” e não tão bem no ambiente “z” e por aí vai.

Quando comecei a trabalhar com .NET e vi surgir uma “Extension” para o Visual Studio que possibilitava compartilhar minhas “Libs” com projetos Silverlight (in memorian) com um nível “aceitável” de gambiarras “dibres tecnológicos”, confesso que nasceu em mim uma centelha de esperança para tornar meus códigos mais reutilizáveis. Posteriormente esse recurso foi incorporado ao Visual Studio e se transformou no que conhecemos (dentro do .NET) por “Portable Class Library”.

As “Portables” chegaram “praticamente” junto com o Xamarin (na época mais conhecido por Mono4Android e MonoTouch… Xamarin.Forms era sonho!), aí as coisas tomaram outra proporção e, de lá pra cá, as coisas evoluíram exponencialmente no universo .NET (vide a revolução: .NET Standard), o que hoje, acredito eu, tornam-se válidas iniciativas para criação de padrões focados no desenvolvimento de aplicações Cross Platform.

Pode parecer “blá blá blá” até o momento mas, IMHO, entender o contexto nos faz ter melhor clareza para onde queremos chegar.

Portanto, a ideia é:

Estabelecer um “padrão/conceito” com objetivo de promover o máximo compartilhamento de código entre plataformas e dispositivos.

Para atingir esse objetivo, o “padrão” precisa ser extremamente leve (“caber” dentro de uma “DLL”) e escalável, deve permitir sua utilização por referência no maior número de ambientes e dispositivos possíveis!

Desafiador não!? Sim, se você não está por dentro das “novidades” do .NET Framework e das PCLs (e do .NET Standard que já está razoavelmente estável). Se você já conhece esses “paranauês” todos aí, deve estar pensando: Mas isso é fácil, basta criar uma nova PCL e selecionar TODOS os “Target Frameworks”, na tela que segue:

Em partes é assim que a coisa funciona, porém não é tão simples. Atualmente, escrever uma biblioteca e simplesmente compartilhar seu código entre ambientes e dispositivos é uma tarefa razoavelmente fácil, os problemas começam a surgir quando você precisa compartilhar regras de negócio, modelagem de objetos e outras coisas, de forma organizada que te permita evoluir e manter a sua aplicação, sem que isso se torne um verdadeiro inferno para seu time de desenvolvimento, e ainda, ser extremamente leve, para que tudo caiba no menor “pacote” possível e funcione no maior número de ambientes possíveis.

É aí que entra o “Cross Platform Design Pattern”!

De forma extremamente simplificada, suprimindo tudo o que é “inútil”, podemos representar/entender um software da seguinte forma:

Na imagem acima, representamos o seguinte fluxo:

1. Ocorre um “evento”, um acesso a um site, um “click” em um item de uma lista num aplicativo, uma chamada agendada em um evento no sistema operacional, enfim, qualquer coisa que “dispare” uma requisição que vai INTERAGIR com a aplicação;
2. A aplicação captura os parâmetros (caso hajam) enviados pelo evento e inicia o processamento das rotinas evolvidas para executar a “tarefa” solicitada pelo usuário (lembrando que a interação pode ser disparada por outra aplicação, ex.: integrações, etc). A aplicação, por sua vez, interage com bancos de dados, outros sistemas, outras rotinas dentro do escopo da própria aplicação, etc;
3. Após o fim do processamento, a aplicação retorna o resultado do processamento das rotinas ao “remetente” da chamada.

Simples certo? Ok, desconsiderei uma série de outros fatores que interferem nesse fluxo AFINAL, a expectativa de um usuário (ou outra aplicação, etc) é que uma aplicação, ao ser “sensibilizada”, execute a ação desejada e informe o resultado da solicitação após encerrado o processo.

Arquiteturas orientadas a serviços (SOA), mais especificamente “Microservices Architecture”, partem da premissa de “pergunta/resposta” e também do conceito de “blocos” pequenos e “autônomos” onde cada serviço é capaz de responder a uma capacidade específica das regras de negócio e, portanto, mesclar “Microservices Architecture” com o fator “Cross Platform” é totalmente plausível.

Construindo o “Cross Platform Design Pattern”

Agora que já apresentei a vocês todo o contexto e alguns conceitos, irei apresentar minha proposta, que nomeei de “Cross Platform Design Pattern”.

O “pattern” pode ser representado da seguinte forma:

Como mostra o diagrama acima, a proposta é implementar um serviço (Micro/Nano service) de forma que parte do código/lógica seja compartilhada entre todas as plataformas desejadas e outra parte é implementada de forma específica para a plataforma “hospedeira” do serviço no momento da execução da aplicação.

Podemos, por exemplo, validar os parâmetros de entrada de forma compartilhada e interagir com bancos de dados na parte específica e por aí vai…

Os serviços podem interagir entre si, realizar chamadas para outros serviços e, conforme a aplicação evolui, maior é o aproveitamento da lógica e do trabalho realizado anteriormente.

Para aqueles que quiserem ir acompanhando a evolução do trabalho ou então queiram testar a proposta, seguem alguns links:

GitHub do projeto: https://github.com/balivo/CrossPlatform

E, para mostrar como o padrão é leve, segue o NuGet Package com toda base necessária para implementar o padrão: https://www.nuget.org/packages/CrossPlatform.Core

Enfim, acredito que tenha feito um overview razoável a respeito da proposta e, nos próximos artigos, vou demonstrar o “Pattern” em ação.

Até a próxima conexão pessoal!