Xamarin

Prévia do material em texto

<p>Xamarin.Form</p><p>Introdução</p><p>Aplicações mobile estão muito em alta hoje. Após a chegada da primeira versão do iPhone da Apple, o celular deixou de ser visto como somente um aparelho que faz ligação e envia mensagens de texto para passar a ser visto como um aparelho que pode realizar quase qualquer tipo de tarefa que um computador pode fazer. Isso se deve principalmente ao fato de que o hardware dos celulares evoluiu, ficando muito mais rápido e eficiente; e também ao fato de que o acesso à aparelhos celulares hoje em dia é muito mais facilitado do que foi em outrora.</p><p>Já que hoje praticamente qualquer pessoa pode (e geralmente já tem) um aparelho com um certo poder de hardware e a tendência é que as pessoas utilizem o celular para resolver os problemas do dia-a-dia cada vez com mais frequência, torna-se essencial que um desenvolvedor seja capaz de projetar e desenvolver aplicativos para celulares e smartphones.</p><p>A miscelânea de plataformas pode ser um problema...</p><p>Se formos analisar o mercado atual de dispositivos smartphones e celulares, temos duas plataformas dominantes no mercado: Android, da Google; e iOS, da Apple. Juntas, estas respondem por mais de 90% do mercado. O restante é ocupado por plataformas menos relevantes, como o Windows Phone da Microsoft e até mesmo o Symbian.</p><p>Plataforma / Sistema operacional</p><p>Market Share</p><p>Android</p><p>82,3%</p><p>iOS</p><p>13,8%</p><p>Windows Phone</p><p>2,7%</p><p>Outros</p><p>1,1%</p><p>Essa dominância das plataformas Android e iOS fica explícita na tabela acima, criada a partir de informações da PSafe em 2014.</p><p>A variância de plataformas é excelente para nós como consumidores, mas pode ser terrível para nós como desenvolvedores. Isso porque cada plataforma simplesmente utiliza uma tecnologia/plataforma/linguagem de programação completamente diferente!</p><p>· iOS utiliza Swift e Objective-C;</p><p>· Android utiliza Java;</p><p>· Windows Phone utiliza .NET;</p><p>· As outras plataformas utilizam as mais variadas tecnologias, como C++ e GTK.</p><p>Isso, em tese, significa que, se você quiser lançar um aplicativo para pelo menos as duas plataformas dominantes do mercado, você precisará escrever seu código pelo menos duas vezes: uma em Objective-C/Swift para o iOS e outra em Java para o Android. E isso torna a situação bem complicada por uma série de fatores:</p><p>· A produtividade cai drasticamente, afinal, você precisa escrever o código da mesma aplicação duas vezes em plataformas completamente distintas;</p><p>· Consequentemente, a manutenção também fica prejudicada. A cada atualização do aplicativo, você precisará modificar o código das duas plataformas.</p><p>Será que não existe uma maneira de se criar um único código que possa rodar de maneira uniforme em todas as plataformas?</p><p>A questão das aplicações híbridas</p><p>Pensando nisso, há algum tempo atrás, foi criado o conceito de aplicações híbridas para resolver este problema.</p><p>Aplicativos híbridos são aplicativos escritos em HTML, CSS e JavaScript. Estes arquivos são empacotados de maneira adequada a cada uma das plataformas. Quando uma aplicação híbrida é executada em um dispositivo, na verdade, é como se você estivesse abrindo estes arquivos HTML, CSS e JavaScript em seu dispositivo local, porém, sem mostrar que se trata de código que é executado dentro de um browser na verdade.</p><p>Como qualquer dispositivo moderno é capaz de acessar páginas web e interpretar arquivos HTML, CSS e JavaScript, essa parecia ser a solução perfeita. Bastava escrever uma aplicação utilizando HTML, CSS e JavaScript que qualquer dispositivo poderia executar a aplicação de maneira uniforme. E, de fato, isso acontece quando escrevemos aplicações mobile em plataformas híbridas, como o Cordova e o PhoneGap.</p><p>O grande ponto é que esta abordagem tem algumas vantagens que, dependendo do negócio do aplicativo, podem se tornar verdadeiros problemas:</p><p>· O código HTML, CSS e JavaScript é interpretado pela engine de visualização do browser. Como cada browser implementa uma engine diferente, não dá para garantirmos que o mesmo código terá o mesmo comportamento em dispositivos diferentes. Isso é similar ao problema que temos com os browsers quando desenvolvemos para a web, onde é comum você escrever um determinado código que é executado com sucesso pelo Google Chrome, mas dá problemas no Internet Explorer ou no Safari, por exemplo;</p><p>· Como qualquer código escrito em HTML, CSS e JavaScript, a performance pode ser um problema. Não que os dispositivos sejam lentos para interpretar estes aplicativos híbridos, mas a velocidade quase nunca é similar à velocidade de uma aplicação nativa. Isso pode acabar prejudicando a experiência do usuário com a aplicação ou pode ser um problema se a sua aplicação precisa de uma certa performance (se falamos de jogos mobile, por exemplo, isso certamente será um problema);</p><p>· O acesso ao hardware do dispositivo pode ser um problema. No final, o desenvolvedor fica dependendo de plug-ins das diferentes plataformas híbridas para conseguir acessar recursos de hardware como o sensor de NFC ou acelerômetro, por exemplo. Hoje este problema já está quase contornado, mas é comum as fabricantes lançarem novas versões de determinados aparelhos e estes plug-ins simplesmente não funcionarem nestes novos dispositivos;</p><p>· Falhas de segurança também acompanham aplicações híbridas, exigindo cuidado redobrado do desenvolvedor. Um exemplo é o componente de renderização de HTML, CSS e JavaScript que acompanhava o Android até a versão 4.x, o chamado WebView. Ele tem uma falha de segurança que permite que um usuário malicioso tome o controle total do dispositivo. Inclusive, a Google já se manifestou e disse que simplesmente não vai corrigir este problema. Você pode acompanhar maiores detalhes desta falha em: https://goo.gl/vhTgup .</p><p>Isso tudo não quer dizer que não devemos utilizar plataformas híbridas para desenvolver nossas aplicações. Mas, quer dizer que nem sempre essa é a melhor decisão. Se você precisa realmente de performance, especialmente na interface, e precisa ter uma certeza maior sobre o acesso aos dispositivos de hardware, as aplicações híbridas podem não ser necessariamente a melhor saída.</p><p>Xamarin: o melhor de dois mundos</p><p>É exatamente neste ponto que podemos entrar com o Xamarin!</p><p>O Xamarin é um framework open source para criação de aplicações mobile cross-platform. Ou seja: teoricamente, ele faz a mesma coisa que o Cordova e o PhoneGap, por exemplo...</p><p>Só que não faz a mesma coisa!</p><p>O Xamarin é compilado para código nativo, ao contrário do Cordova/PhoneGap. Isso quer dizer que você escreverá um único código que será compilado nativamente para cada uma das plataformas. Ou seja, nós conseguimos ter o melhor de dois mundos: o aspecto multiplataforma (ou cross-mobile) e a performance e eficiência das aplicações nativas.</p><p>Como o Xamarin funciona?</p><p>Como comentado anteriormente, o Xamarin (pronuncia-se “Zêmarin”) é um framework open source e que passou a ser de utilização gratuita desde que a Xamarin Foundation foi adquirida pela Microsoft. Isso quer dizer que você não precisa pagar pelo uso do Xamarin, nem pela distribuição de aplicativos construídos com ele (com exceção das licenças de desenvolvedor de cada plataforma quando falamos de publicação de aplicativos).</p><p>Se você quiser dar uma olhada no GitHub do Xamarin, pode fazer isso através do link: https://github.com/xamarin .</p><p>O Xamarin é baseado no C#, da própria Microsoft. Os motivos que levaram o Xamarin a utilizar essa linguagem são descritos abaixo:</p><p>· O Xamarin na verdade funciona inteiro em cima de .NET. Sendo assim, faz sentido utilizar a principal linguagem da plataforma, que é o C#;</p><p>· O C# é similar tanto ao Java utilizado pelos desenvolvedores Android quanto ao Swift/Objective-C, utilizados pelos desenvolvedores Apple. Isso facilita a aproximação com os desenvolvedores das duas plataformas dominantes do mercado.</p><p>Inicialmente, o Xamarin na verdade foi baseado no Mono, que foi um port do .NET para ambientes não-Windows (como Linux e Mac). Porém, com a absorção do Mono pela Microsoft, hoje ele roda de fato em cima do .NET Framework.</p><p>O processo de compilação do Xamarin é</p><p>bem interessante, variando de plataforma para plataforma para a qual nós compilamos. Acompanhe nos itens abaixo como funciona esse processo:</p><p>· Se estamos falando de Android, o Xamarin faz a compilação do código C# para IL (Intermediate Language) utilizando o MonoVM mais o JIT’ing. Dessa maneira, no final das contas, algumas classes e bibliotecas-base são inclusas no pacote final compilado para que a aplicação possa ser executada ao lado do próprio Java do Android e/ou o Android Runtime (ART). A aplicação faz acesso à API do Android via JNI (Java Native Interface);</p><p>· Se estamos falando de ambientes Windows, a compilação é feita da maneira tradicional para o IL e nenhum artefato adicional é incluso no pacote final, pois os ambientes Windows já são preparados para executar aplicações .NET;</p><p>· Se estamos falando de iOS, a compilação é realizada ahead-of-time (AOT), o que significa que o código é todo compilado para a IL e imediatamente compilado para código nativo (o que, em ambientes mobile, pode significar um ganho perceptível de performance, frente ao processo de compilação tradicional com o JIT). No caso de compilações para iOS, o código é compilado para um assembly ARM. O código ARM é perfeitamente interpretável pela plataforma iOS, como se fosse um processo de compilação de uma linguagem nativa como o Swift ou o Objective-C.</p><p>O processo de geração dos respectivos assemblies e o ambiente de execução pode ser representado da seguinte forma:</p><p>Ainda temos um problema com o Xamarin “tradicional”</p><p>A priori, parece que a solução proposta pelo Xamarin funciona perfeitamente. E sim, de fato ela funciona. Mas o Xamarin não consegue lidar muito bem com um aspecto principalmente: a interface. Como a interface depende intrinsecamente do sistema operacional por causa das APIs, mesmo utilizando Xamarin, você pode acabar tendo um pequeno esforço duplicado para criar interfaces pelo menos para o Android e para o iOS. Isso fica mais claro ao vermos que temos versões dedicadas do Xamarin para estas duas plataformas: o Xamarin.Android e o Xamarin.iOS.</p><p>A solução: o Xamarin.Forms</p><p>Felizmente, em 2014, o time do Xamarin em conjunto com a Microsoft conseguiu desenvolver uma solução para este ponto: o Xamarin.Forms!</p><p>A ideia do Xamarin.Forms é que até mesmo o processo de criação de interfaces seja de fato cross-platform, ou seja: você pode criar uma única interface que será interpretada por qualquer sistema operacional. Isso é feito através de componentes disponibilizados pelo Xamarin.Forms chamados controles, que representam os diferentes elementos que um usuário pode interagir (como Entry – que representa um TextBox; Slider, CheckBox, etc.). Estes componentes, que são dispostos pela API do Xamarin.Forms, são devidamente traduzidos para os respectivos componentes na plataforma nativa durante o processo de compilação.</p><p>Com essa estratégia, o time da Xamarin/Microsoft garante que, pelo menos, 96% do código se torna de fato cross-platform. Só não é garantido 100% porque, dependendo do que sua aplicação for realizar, você precisará realizar chamadas específicas de cada plataforma em seu código...</p><p>Xamarin.Forms: tendência, mesmo com alguns problemas</p><p>O Xamarin.Forms foi criado em 2014, o que o faz ainda muito novo. Isso quer dizer que, eventualmente, algum pequeno problema pode acabar parecendo no decorrer de sua utilização. O que os desenvolvedores mais costumam questionar é a inicialização de uma aplicação escrita com o Xamarin.Forms, que costuma demorar um pouco mais que uma aplicação escrita com Xamarin.Android ou Xamarin.iOS. Também temos o fato de que nem todos os componentes ainda são disponibilizados pela API do Xamarin.Forms, já que ele acaba se restringindo ao subconjunto de componentes que podem ser comutados entre todas as plataformas.</p><p>Porém, é fato de que o Xamarin.Forms é uma tendência que vem crescendo muito forte dentro do Xamarin, sendo o sub framework que mais vem recebendo atenção e recursos da Microsoft. A partir da versão 2, mesmo com estes pequenos problemas, o framework se tornou muito viável comercialmente falando, o que ressalta a sua evolução rápida e dedicação da Microsoft em o melhorar cada vez mais.</p><p>Por causa disso, nem sempre utilizar também o Xamarin.Forms é a melhor solução...</p><p>Considere utilizar Xamarin.Forms se...</p><p>· A aplicação não realizará interações de interface que exigem velocidade extrema;</p><p>· Quando o compartilhamento de código for realmente o foco;</p><p>· Quando a aplicação não fará muitas chamadas nativas de cada sistema operacional.</p><p>Agora, considere utilizar Xamarin.Android ou Xamarin.iOS se...</p><p>· A aplicação precisa de velocidade extrema na interface, como em jogos;</p><p>· Quando a aplicação precisar lidar com a API de baixo nível de cada um dos sistemas operacionais com uma certa frequência.</p><p>Também é importante ressaltar que o Xamarin.Forms não vem substituir completamente o Xamarin.Android ou o Xamarin.iOS, mesmo porque ele roda em cima destes dois. O processo de execução de uma aplicação Xamarin.Forms pode ser representado com a ilustração abaixo:</p><p>Estratégias de compartilhamento de código</p><p>No Xamarin.Forms, o código, inclusive a interface, é compartilhado entre todas as plataformas. E isso pode ser feito de duas maneiras: através de uma Portable Class Library (PCL) ou através de um Shared Application Project (SAP).</p><p>Estratégia através de SAP (Shared Application Project)</p><p>Há algum tempo atrás, era a prática mais convencional se tratando de Xamarin.Forms. Nessa estratégia, o projeto é criado com uma base de código compartilhada em um projeto separado, um Shared Project. Quando utilizamos esta estratégia e precisamos definir porções de código que serão executadas em determinadas versões de sistema operacional, deve-se utilizar diretivas de compilação, especialmente o #if.</p><p>A utilização de diretivas de compilação pode ser ilustrada com o código abaixo:</p><p>1</p><p>2</p><p>3</p><p>4</p><p>5</p><p>6</p><p>7</p><p>8</p><p>9</p><p>10</p><p>11</p><p>#if __WINDOWS__</p><p>// Código que será executado somente em plataforma Windows</p><p>#elif __ANDROID__</p><p>// Código que será executado somente na plataforma Android</p><p>#elif __ANDROID_19__</p><p>// Código que será executado somente na plataforma Android com API 19 (Android 4.3 ~4.4)</p><p>#elif __IOS__</p><p>// Código que será executado somente na plataforma iOS</p><p>#endif</p><p>C# (C Sharp)</p><p>Perceba que o Xamarin define diretivas de compilação para especificar cada uma das plataformas suportadas. A diretiva correspondente a cada plataforma sempre começa com dois underlines e sempre termina com dois underlines (__).</p><p>Existe um ponto interessante com o Shared Application Project. Por baixo dos panos, é como se o projeto fosse duplicado em cada um dos subprojetos para o compilador. Sendo assim, para o compilador, os projetos Droid, iOS, Windows e WinPhone possuem cópias exatas do projeto compartilhado, sendo que cada plataforma irá interpretar somente o código que estiver ou fora das diretivas, ou dentro das diretivas correspondentes à plataforma do projeto. Existe uma implicação técnica por causa deste comportamento: Shared Application Projects não geram DLLs. Em projetos .NET, geralmente, quando criamos projetos que se relacionam dentro de uma solution, cada um dos subprojetos gera sua respectiva DLL. Esse comportamento não ocorre em Shared Application Projects. O código que fica na base de código compartilhada é embarcado dentro do assembly da própria aplicação.</p><p>Estratégia através de PCL (Portable Class Library)</p><p>Uma outra forma de compartilhamento de código é através de uma Portable Class Library, estratégia conhecida como PCL.</p><p>Uma PCL é exatamente como uma Class Library comum. Isso quer dizer que sua compilação produz uma DLL, DLL essa que é consumida pelos projetos Droid, iOS, Windows e WinPhone. Ao final, uma PCL contém somente código que é realmente possível de ser interpretado por todas as plataformas que a PCL suporta, o que dispensa a utilização de diretivas.</p><p>A definição das plataformas suportadas é feita através de algo que chamamos de profile.</p><p>PCLs e profiles</p><p>Um profile define para uma PCL as plataformas que esta deverá suportar. Isso é configurável quando</p><p>clicamos com o botão direito sobre a Class Library e acionamos a categoria Library. Você verá uma tela similar à tela abaixo:</p><p>Perceba no caso da configuração acima que nós estamos utilizando como base o .NET 4.5. Também configuramos a PCL para que esta suporte o Windows 8, Windows Phone 8, o ASP.NET Core 1, o Windows Phone 8.1, Xamarin.Android, Xamarin.iOS convencional e clássico e, por fim, Xamarin.Mac. Isso sinaliza que a PCL em questão só pode ser utilizada nestes sistemas operacionais e frameworks.</p><p>Cada configuração de perfil geralmente tem um código associado. No caso acima, este é o perfil padrão do Xamarin.Forms. Este perfil recebe o código #111 ou #259. Você pode visualizar essa informação ao abrir o arquivo CSPROJ associado à sua PCL.</p><p>O cruzamento das informações entre o perfil selecionado e a versão do .NET Framework utilizado é muito relevante para que você consiga definir os recursos do .NET que o projeto terá à disposição. Pelo fato de uma PCL automaticamente selecionar subconjuntos de funcionalidades do .NET de acordo com as plataformas a serem suportadas e a versão do .NET utilizada, pode ser que dependendo da configuração que você realize, você não possa utilizar recursos do C#, como a utilização da coleção iQueryable<T>. A tabela abaixo ilustra de maneira resumida estas limitações:</p><p>Recurso</p><p>.NET Framework</p><p>Windows Store Apps</p><p>Silverlight</p><p>Windows Phone</p><p>Xamarin</p><p>Core</p><p>Sim</p><p>Sim</p><p>Sim</p><p>Sim</p><p>Sim</p><p>LINQ</p><p>Sim</p><p>Sim</p><p>Sim</p><p>Sim</p><p>Sim</p><p>IQueryable</p><p>Sim</p><p>Sim</p><p>Sim</p><p>7.5+</p><p>Sim</p><p>Serialization</p><p>Sim</p><p>Sim</p><p>Sim</p><p>Sim</p><p>Sim</p><p>Data Annotations</p><p>4.0.3+</p><p>Sim</p><p>Sim</p><p>Não</p><p>Sim</p><p>image4.png</p><p>image5.png</p><p>image1.png</p><p>image2.png</p><p>image3.wmf</p>