Share via

Diretrizes de portabilidade de aplicativo da área de trabalho

  • Artigo

A maioria dos códigos do aplicativo pode ser categorizada em uma das seguintes áreas:

  • Código da interface do usuário (por exemplo, janelas e botões)
  • Controles de terceiros (por exemplo, gráficos)
  • Lógica de negócios (por exemplo, regras de validação)
  • Armazenamento e acesso a dados locais
  • Serviços Web e acesso a dados remotos

Para aplicativos Windows Forms e WPF escritos com C# (ou Visual Basic.NET) uma quantidade surpreendente da lógica de negócios, o acesso a dados local e o código de serviços Web podem ser compartilhados entre plataformas.

.NET Portability Analyzer

O Visual Studio 2017 e posteriores dão suporte ao Analisador de Portabilidade do .NET (download para Windows), que pode examinar seus aplicativos existentes e informar quanto código pode ser portado "como está" para outras plataformas.

Há também uma ferramenta de linha de comando que pode ser baixada do Analisador de Portabilidade no GitHub e usada para fornecer os mesmos relatórios.

"x% do meu código é portátil. O que vem a seguir?"

Espero que o analisador mostre que uma grande parte do seu código é portátil, mas certamente haverá algumas partes de cada aplicativo que não podem ser movidas para outras plataformas.

Partes diferentes de código provavelmente cairão em um desses buckets, explicado em mais detalhes abaixo:

  • Código portátil reutilizável
  • Código que requer alterações
  • Código que não é portátil e requer uma nova gravação

Código portátil reutilizável

O código .NET escrito em APIs disponíveis em todas as plataformas pode ser usado entre plataformas inalterado. Idealmente, você poderá mover todo esse código para uma Biblioteca de Classes Portátil, Biblioteca Compartilhada ou Biblioteca Padrão do .NET e testá-lo em seu aplicativo existente.

Essa biblioteca compartilhada pode ser adicionada a projetos de aplicativos para outras plataformas (como Android, iOS e macOS).

Código que requer alterações

Algumas APIs do .NET podem não estar disponíveis em todas as plataformas. Se essas APIs existirem em seu código, você precisará gravar novamente essas seções para usar APIs multiplataforma.

Exemplos disso incluem o uso de APIs de Reflexão que estão disponíveis no .NET 4.6, mas não estão disponíveis em todas as plataformas.

Depois de escrever novamente o código usando APIs portáteis, você poderá empacotar esse código em uma biblioteca compartilhada e testá-lo em seu aplicativo existente.

Código que não é portátil e requer uma nova gravação

Exemplos de código que provavelmente não serão multiplataforma incluem:

  • Interface do usuário – telas Windows Forms ou WPF não podem ser usadas em projetos no Android ou iOS, por exemplo. Sua interface do usuário precisará ser reescrito, usando essa Comparação de Controles como referência.

  • Armazenamento específico da plataforma – código que depende de uma tecnologia específica da plataforma (como um banco de dados de SQL Server Express local). Você precisará gravar novamente isso usando uma alternativa multiplataforma (como SQLite para o mecanismo de banco de dados). Algumas operações do sistema de arquivos também podem precisar ser ajustadas, pois a UWP tem APIs ligeiramente diferentes para Android e iOS (por exemplo, alguns sistemas de arquivos diferenciam maiúsculas de minúsculas e outros não).

  • Componentes de terceiros – verifique se os componentes de terceiros em seus aplicativos estão disponíveis em outras plataformas. Alguns, como pacotes NuGet não visuais, podem estar disponíveis, mas outros (especialmente controles visuais, como gráficos ou media players)

Dicas para tornar o código portátil

  • Injeção de dependência – fornecer implementações diferentes para cada plataforma e

  • Abordagem em camadas – seja MVVM, MVC, MVP ou algum outro padrão que o ajude a separar o código portátil do código específico da plataforma.

  • Mensagens – você pode usar a mensagem passando seu código para desacoplar interações entre diferentes partes do aplicativo.