XAMARIN FORMS – USANDO XAMARIN EFFECTS

Este artigo tem como objetivo mostrar como usar efeitos no desenvolvimento de aplicações móveis usando a framework Xamarin Forms.

Introdução

A framework Xamarin Forms permite abstrair a camada de user interface entre as diversas plataformas, ie, através desta framework podemos escrever um único código que define toda a aplicação e que irá ter a sua representação gráfica respeitando é claro o controlos gráficos de cada plataforma. Refiro-me é claro às plataformas iOS, Android e Windows, cujo UX difere em alguns aspetos.

Figura 1: Elementos gráficos relativos a iOS e Android – diferenças ao nível controlos e icons

Para muitos a Figura 2 é reconhecida quando nos referimos à percentagem de código que podemos reutilizar entre usando o “tradicional desenvolvimento” – Xamarin.Android ou Xamarin.iOS e quando usamos a framework Xamarin Forms.


Figura 2: Xamarin vs Xamarin Forms

O uso da framework (Xamarin Forms) pode não se aplicar a todos os tipos de aplicações, pois os diversos requisitos e as especificidades técnicas da aplicação podem ser determinísticas na escolha – dou o exemplo de aplicações com muitas animações ou aplicações que a user interface usa controlos que são específicos da plataforma, e claro está dificulta no uso desta framework. Conceptualmente esta framework tem um interesse muito grande pela convergência que se tem vindo a sentir na reutilização de código e na redução do tempo de desenvolvimento. E claro está, que para o bom uso da mesma é necessário compreender toda a abstração inerente e também a forma como os diversos garbage collections são geridos pois isto é relevante na gestão de memória da aplicação e deteção de memory leaks (criados pelo próprio programadores) – muitas das vezes estes aspetos não são tido em conta durante o desenvolvimento.

Uma das funcionalidades fornecidas pela Xamarin ao nível desta framework, logo desde o início, foi o chamado “Renders” que permite alterar o controlo de base, ie, é possível através do render obter o controlo nativo da plataforma e claro está aplicar as alterações pretendidas. Sem dúvidas que os renders são muito interessantes, mas quando se começa a criar muitos renderes podemos concluir que o uso do tradicional desenvolvimento (Xamarin.iOS ou Xamarin.Android) poderá ser o melhor (depende muito de caso para caso).

Mais recentemente, a Xamarin desenvolveu uma nova funcionalidade chamada “Effects” que tem como finalidade facilitar a customização dos controlos nativos, e desta forma a criação de “renders” deixa de fazer sentido em muitos casos, e todo o desenvolvimento fica então mais simplificado.

Descrição
Para exemplificar o uso de “Effects”, usemos o controlo Button como exemplo – vejam a seguinte figura:

Figura 3: Classe Button e as diversas representações em cada plataforma

Do lado esquerdo temos a classe Button da framework Xamarin Forms e do lado direito temos o controlo gráfico e o namespace a que pertence o respetivo controlo em cada plataforma – Button em Android e Windows e IUButton em iOS.

Figura 4: A classe ButtronRenderer, definida no projeto target, será a classe que permite fazer a tradução entre o Button de Xamarin Form para o controlo nativo.

Antes de existirem os “Effects” os renders eram estendidos, ie, a class ButtonRenderer era estendida em cada um dos targets, para se poder alterar o controlo nativo. Em alguns casos, a extensão dos “Renders” obriga a criar um novo controlo do lado de Xamarin Forms, ie, MyButton que herda da classe Button, para que desta forma o “Render” se aplique apenas ao controlo especifico. Para diferenciar entre as duas funcionalidades, um bom exemplo do uso de “Effects” é aplicação e ajuste do theme da aplicação em que o controlo nativo se mantém e apenas se pretende ajustar algumas propriedades nativas – podendo ser definido de várias formas:

  • usando o nome do “Effects”
  • usando RoutingEffect

Por usa vez, podem ser afetos ao controlo de Xamarin Forms através da respetiva propriedade para o efeito ou através de attached properties.

Criação de um “Effect”
Suponhamos que temos um controlo que apresenta texto, uma Label, de seguida vamos ver como podemos definir o tipo de letra para cada target.

Começamos então por definir o effect em cada plataforma.

iOS


	[assembly: ResolutionGroupName("Xamarin")]
	[assembly: ExportEffect(typeof(MyCustomFontEffect), "CustomFontEffect")]
	namespace CustomFont.iOS 
	{
		class MyCustomFontEffect : PlatformEffect 
		{
			UIFont oldFont;
			protected override void OnAttached() {
			if (Element is Label == false) return;
			var label = Control as UILabel;
			oldFont = label.Font;
			label.Font = UIFont.FromName("Pacifico", label.Font.PointSize);
		}
	}
  
protected override void OnDetached() 
{
	if(oldFont != null) 
	{
		var label = Control as UILabel;
		label.Font = oldFont;
	}
}

Android


	[assembly: ResolutionGroupName("Xamarin")]
	[assembly: ExportEffect(typeof(MyCustomFontEffect), "CustomFontEffect")]
	namespace CustomFont.Droid 
	{
		class MyCustomFontEffect : PlatformEffect 
		{
			Typeface oldFont;
			protected override void OnAttached() 
			{
				if (Element is Label == false) return;
				var label = Control as TextView;
				oldFont = label.Typeface;
				var font = Typeface.CreateFromAsset(Android.App.Application.Context.Assets, "Pacifico.ttf");
				label.Typeface = font;
			}
		}
	}
   
	protected override void OnDetached() 
	{
		if (oldFont != null) 
		{
			var label = Control as TextView;
			label.Typeface = oldFont;
		}
	}

Windows


	[assembly: ResolutionGroupName("Xamarin")]
	[assembly: ExportEffect(typeof(MyCustomFontEffect), "CustomFontEffect")]
	namespace CustomFont.UWP 
	{
		class MyCustomFontEffect : PlatformEffect 
		{
			Windows.UI.Xaml.Media.FontFamily oldFontFamily;
			protected override void OnAttached() {
			if (Element is Label == false) return;
			TextBlock tb = Control as TextBlock;
			oldFontFamily = tb.FontFamily;
			tb.FontFamily = new Windows.UI.Xaml.Media.FontFamily(@"/Assets/Pacifico.ttf#Pacifico");
		}
	}
    
	protected override void OnDetached() 
	{
		if (oldFontFamily != null) 
		{
			TextBlock tb = Control as TextBlock;
			tb.FontFamily = oldFontFamily;
		}
	}

De salientar, que o método OnAttached é chamado quando o effect é atribuído a um controlo de Xamarin Forms, e o método OnDetached é chamando quando o effect deixa de estar associado ao controlo de Xamarin Forms. O método OnElementPropertyChanged é chamado quando ocorre alterações numa propriedade do controlo de Xamarin Forms que pode requerer alterações no controlo nativo associado.

De seguida vamos definir uma página em que vamos ter um Label à qual iremos aplicar o effect definido.

XAML





C#

Para adicionar o effect ao controlo de Xamarin Forms:


	private Effect _fontEffect;
	public MainPage() 
	{
		InitializeComponent();
		_fontEffect = Effect.Resolve("Xamarin.CustomFontEffect");
		labelWelcome.Effects.Add(_fontEffect);
	}

Para remover (em qualquer momento):


	labelWelcome.Effects.Remove(_fontEffect);

Em cada target é definido em cada effect o ExportEffect que conhece o tipo do effect criado e que tem um nome associado (CustomFontEffect), de salientar que esse nome deve ser comum nos diversos targets para que o effect quando aplicado em Xamarin Forms seja reconhecido.


	[assembly: ExportEffect(typeof(MyCustomFontEffect), "CustomFontEffect")]

Criação de um RoutingEffect

A criação de RoutingEffects acaba por ser muito interessante, pelo fato de deixamos de usar string com o nome do effect e passamos a usar um objecto que define o effect. Portanto o RoutingEffect não é mais do que uma classe que fica definida no projeto partilhado e que permite usar um objecto para definir o effect em vez de usar o método Resolve e a string do nome. A sua implementação de exemplo é a seguinte:


	class LabelFontEffect : RoutingEffect 
	{
		public LabelFontEffect() : base("Xamarin.CustomFontEffect") { }
	}

Nota: De salientar, que no RoutingEffects é usado o nome do render CustomFontEffect, mas também o seu nome do ResolutionGroupName definido em cada effect.


	[assembly: ResolutionGroupName("Xamarin")]

Desta forma, o efeito pode ser definido no controlo de Xamarin Forms da seguinte forma:

Um Effect pode ser associado a qualquer controlo que suporte effects, no entanto, este effect deve ser usado tendo em conta se está associado (a um Button ou a uma Label), pois não devemos atribuir effects cujo controlo nativo o não lhe corresponda. Quando é necessário criar um effect que possa ser usado por vários controlos porque as propriedades são comuns, ai podemos criar um effect ao nível da classe pai, ie, da classe Element (por exemplo).

Conclusão

Em conclusão, os “effects” vem facilitar toda a customização exigida pelos designers e desta forma, o desenvolvimento de aplicações móveis usando Xamarin Forms fica mais rápido, simplificado o desenvolvimento, e para além disso a qualquer momento podemos alterar os “effects” de cada controlo de Xamarin Forms, permitindo assim que em runtime seja aplicado o design que se pretende. Os effects para além de poderem ser atribuídos aos controlos podem ser definidos através de attached properties ou de styles o que é uma mais valia para a qualidade de código a desenvolver.

Algumas referências

 

TESTAR APLICAÇÕES MÓVEIS COM XAMARIN TEST CLOUD

Âmbito
Este artigo tem como objetivo mostrar como podemos testar as aplicações móveis usando Xamarin Test Cloud, sejam estas aplicações Xamarin ou aplicações nativas.

Introdução
O desenvolvimento móvel tem tido um crescimento exponencial, trazendo com isso um “booom” de aplicações para as diversas lojas. Claro está, que muitas das vezes quantidade não significa qualidade e quantas vezes nós próprios nos deparamos com potências aplicações que apenas precisam de melhorias, e em alguns casos a aplicação funciona bem numa plataforma e noutra não (por razões diversas). Com este crescimento e com base nas diversas necessidades muitas soluções têm surgido no mercado para que os programadores possam acompanhar o desempenho da aplicação durante a sua utilização.

Independentemente da forma como os programadores acompanham as suas aplicações para fazer manutenção corretiva, coloca-se a seguinte questão: será que isto é uma boa solução? Isto é, será que é bom serem os nossos utilizadores a encontrar os bugs e comportamentos não esperados? Porque isto é ou tem sido uma realidade… Ou será que os programadores devem-se preocupar com estratégias de testes antes de esta chegar ao utilizador final?

Seguindo boas práticas podemos dizer que cada aplicação deve ser testada antes de chegar ao utilizador final, e deve-se definir pelo menos os testes unitários e os testes de aceitação (em alguns casos pode haver necessidade de definir os testes de integração, com serviços externos, como por exemplo o BackEnd). Com a criação de testes vamos conseguir provar que o comportamento desenvolvido é o que está a ser testado, e se alguma alteração quebrar os testes ou o bom funcionamento da aplicação, é possível colocar em causa se houve um erro inicial, um erro no momento da alteração ou se o problema em causa não foi tido em conta, e claro está, proceder à correção.

Tipos de testes
A fase de testes é o processo que permite garantir que o desenvolvimento realizado faz efetivamente o que foi definido inicialmente. Esta fase pode incluir vários tipos de testes, tendo cada um o seu propósito, resumidamente podemos dizer que:

Os testes unitários são testes escritos normalmente pelo(s) programador(es) que visa validar as várias funcionalidades de forma isolada, ie, o programador cria vários testes para verificar que um determinado método, classe, módulo ou componente é válido de acordo com os requisitos e faz o que é expetável.
Os testes de integração são testes criados com o objetivo de validar a integração de classes, módulo ou componentes umas com as outras. No caso de aplicações móveis podemos dar como exemplo para testes de integração a comunicação entre o backend e a aplicação móvel.
Os testes de aceitação são testes criados maioritariamente pela equipa de QA, e que visa testar a aplicação como sendo uma caixa negra, ie, é sabido à partida que é possível realizar um conjunto de operações e ao efetuar essas operações é expetável um resultado final.
Na figura 1, podemos ver outros tipos de testes, e a relação custo/esforço e nº de testes, claro está que o mais comum é a criação de testes unitários, e nem sempre é feita a cobertura de todos os tipos de testes.

Xamarin Test Cloud: vários tipos de testes

Figura 1: Vários tipos de testes

Execução automática de testes
Outra questão extremamente relevante, é a execução dos diversos testes ser um processo automático, ie, à medida que as alterações se vão refletindo se possa confirmar que tudo o que estava a funcionar está efetivamente a funcionar, sem que se tenha que recorrer a processos manuais. Por esta razão, muitas vezes é criando um sistema de integração continua (usando por exemplo Team City ou TFS Online), em que na operação de checkin / push para o gestor de controlo de versões são executados todos os testes, referente à aplicação, e só após a confirmação de que todos os testes estão OK é que são aceites as novas funcionalidades ou alterações por parte do servidor.

Um programador mais atento vai questionar-se: é verdade que posso executar os testes unitários e de integração em processo automático, usando as ferramentas de desenvolvimento e de testes (seja NUnit ou MSTest), mas então, e os testes de aceitação? Uma vez que para verificar os diversos testes de aceitação é preciso executar a aplicação!? Vou ter constantemente uma equipa de QA a fazer o processo manualmente?

Neste artigo vamos ver como podemos escrever e executar os testes de aceitação de forma automática recorrendo à solução da Xamarin, o Test Cloud.

Descrição
Para dar suporte ao artigo, consideremos a aplicação TODO, desenvolvida com base na plataforma Xamarin, cujo código fonte pode ser obtido no seguinte endereço https://github.com/xamarin/xamarin-forms-samples/tree/master/Todo.

Xamarin Test Cloud: aplicação TODO

Figura 2: Aplicação TODO
Consideremos agora que foi terminada uma das fases de desenvolvimento, e que existe um conjunto de funcionalidades testadas recorrendo a testes unitários e de integração. Visto isto, a equipa de desenvolvimento e/ou a equipa de QA pretende proceder à criação de testes de aceitação, para validar todo o fluxo da aplicação e as diversas funcionalidades. Desta forma, vamos proceder à criação dos testes de aceitação, recorrendo à biblioteca Xamarin.UITest.

Xamarin.UITest
A Xamarin.UITest é uma biblioteca desenvolvida pela Xamarin que permite escrever os testes automáticos de aceitação, ao nível da UI, de aplicações desenvolvidas com base na plataforma Xamarin. Esta biblioteca é baseada em Calabash – uma biblioteca que permite escrever testes automáticos de aceitação, ao nível UI, para aplicações nativas iOS e Android.

Na figura 3, podemos ver o diagrama de decisão relativo às frameworks que podemos utilizar nas aplicações móveis.

Xamarin Test Cloud: escolha de framework de testes


Figura 3: Diagrama de decisão

Esta biblioteca:

É baseada em C# e usa a biblioteca NUnit (versão 2.6.4)
Está apenas disponível para Xamarin.iOS e Xamarin.Android
É suportada pelos diversos IDE (Xamarin Studio e Visual Studio)
O Xamarin Studio disponibiliza projetos template para Xamarin.iOS, Xamarin.Android e Cross-Platform
O Visual Studio apenas disponibiliza projetos template para projetos Cross-Platform
Está disponível através de pacote Nuget – cuja versão atual é Xamarin.UITest 1.2.0
É executado sobre um agente, Xamarin Test Cloud Agent, que vai permitir executar os testes sobre a aplicação (quer estejamos perante o simulador ou um dispositivo)
Criação de projeto
Comecemos por abrir o projeto TODO no Xamarin Studio, como podemos visualizar nas imagens seguintes.

Xamarin Test Cloud: adicionar novo projeto


Figura 4: Adicionar novo projeto
Xamarin Test Cloud: seleção do projeto


Figura 5: Seleção do projeto

Xamarin Test Cloud: definição do nome do projeto


Figura 6: Definição do nome do projeto
Xamarin Test Cloud: solução com o projeto de testes


Figura 7: Solução com o projeto de testes
O template do projeto de testes, que acabamos de criar, inclui dois ficheiros: AppInitializer.cs e Test.cs.

AppInitializer
A classe AppInitializer, com apenas um método (StartApp) irá:

Definir a aplicação sobre qual correm os testes
Com base no pacote APK, IPA ou bundle (.app)
app = ConfigureApp.iOS.AppBundle(“../../path/todo.app”);
app = ConfigureApp.Android.ApkFile(“../../path/todo.apk”);
Com base no nome da aplicação instalada no dispositivo
app = ConfigureApp.iOS.InstalledApp(“com.xamarin.todo”);
app = ConfigureApp.Android.InstalledApp(“com.xamarin.todo”);
Com base no projeto definido na solução
Definir o dispositivo que irá executar os testes (por omissão é usado o simulador)
Iniciar a aplicação, quando o método StartApp é invocado
Para saber mais detalhes, consulte a documentação fornecida pela Xamarin:

UITest.Configuration.iOSAppConfigurator Class
UITest.Configuration.AndroidAppConfigurator Class
Para o caso da aplicação TODO iremos ter o seguinte code snippet:


	public class AppInitializer
	{
			public static IApp StartApp (Platform platform)
			{
				// TODO: If the iOS or Android app being tested is included in the solution 
				// then open the Unit Tests window, right click Test Apps, select Add App Project
				// and select the app projects that should be tested. 
				// The iOS project should have the Xamarin.TestCloud.Agent NuGet package
				// installed. To start the Test Cloud Agent the following code should be
				// added to the FinishedLaunching method of the AppDelegate:
				//    #if ENABLE_TEST_CLOUD
				//    Xamarin.Calabash.Start();
				//    #endif
				if (platform == Platform.Android) {
					return ConfigureApp
						.Android

						.ApkFile ("../../../Todo.Droid/bin/Debug/TodoDroid.apk")
						.StartApp ();
				}

				return ConfigureApp
					.iOS
					.AppBundle ("../../../Todo.iOS/bin/iPhoneSimulator/Debug/TodoiOS.app")
					.StartApp ();
			}
	}

De realçar que na configuração inicial do pacote da aplicação para iOS, é possível surgir o erro

SetUp: System.Exception: The app bundle in XTC/Todo/PCL/Todo.iOS/bin/iPhoneSimulator/Debug/TodoiOS.app does not seem to be properly linked with Calabash. Please verify that it includes the Calabash component.
que significa que a aplicação iOS não contém a referência para o Xamarin Test Cloud Agent ou não contém a chamada ao método Xamarin.Calabash.Start() no event handler AppDelegate.FinishedLaunching. Para o caso em que este erro continue a surgir e esteja tudo bem configurado, é recomendável que se apague a pasta bin do projeto de iOS e se faça build novamente.

Xamarin Test Cloud: adicionar o pacote Xamarin Test Cloud Agent ao projeto de iOS


Figura 8: Adicionar o pacote Xamarin Test Cloud Agent ao projeto de iOS

Tests
A classe Tests define um método que é designado por setup que permite iniciar os testes sobre a UI da aplicação, e contém os vários testes para as diversas plataformas (na prática podem existir mais do que uma classe com testes, dependendo da organização destes).

Por omissão, esta classe está definida para lançar os testes nas duas plataformas, isto porque a classe está decorada com os seguintes atributos:


	[TestFixture (Platform.Android)]
	[TestFixture (Platform.iOS)]
	public class Tests { ... }

Isto significa, se os testes definidos estiverem a suportar mais do que uma plataforma, a sua execução originará que vários simuladores iniciem a aplicação ao mesmo tempo (em alguns casos poderá ter interesse analisar em simultâneo o comportamento da aplicação nas diversas plataformas, não sendo, no entanto, um cenário comum).

O IDE irá lançar a aplicação no simulador ou no dispositivo, consoante o que estiver configurado. No caso da plataforma Android é requisito haver pelo menos um dispositivo conectado ao ADB, para que assim seja possível executar a aplicação e consequentemente os testes. É também requisito que a aplicação tenha permissões de internet, independentemente se esta requer o envio/receção de dados, uma vez que a anatomia da biblioteca requer esta permissão.

Nota: Sendo a biblioteca Xamarin.UI.Tests baseada em NUnit, é possível usar o atributo [Category] para categorizar os testes e desta forma organizar os diversos testes.

Interface IAPP
A classe Tests pode ser alterada, sendo possível definir os testes que se pretender. A interface IApp acessível por esta classe, permitirá a interação com a UI da aplicação, e portanto, é possível localizar elementos gráficos (textbox, botões, …), lançar eventos (como por exemplo “Tapping”, “Typing”), entre outras operações como podemos ver na figura 9, e iremos descrever mais à frente neste artigo.

Xamarin Test Cloud: operações mais comuns


Figura 9: Operações mais comuns

Vejamos alguns code snippets:

Tirar screenshot à aplicação e atribuição do nome da imagem

app.Screenshot (“First screen.”);
Pressionar o botão com o texto ou id “Add”
app.Tap (c => c.Marked (“Add”));
Obtenção do botão (visível) com o texto ou id “Save”
AppResult[] matchedItems = app.Query( c => c.Button().Marked(“Save”));
Obtenção de controlos baseado no tipo por plataforma

Para iOS


	var matches = app.Query(c => c.Class("UILabel"));
	var matches = app.Query(c => c.Class("TextView"));

Para Android


	var matches = app.Query(c => c.Button());
	var matches = app.Query(c => c.TextField());

Execução de testes localmente
Atualmente o melhor cenário para correr os testes será usando o Xamarin Studio num Mac, uma vez que é a única forma de executar os testes para iOS. No Xamarin Studio é possível escolher a vista Unit Testing, como podemos ver na figura 10.

Xamarin Test Cloud: vista Unit Testing

Figura 10: Vista Unit Testing

No menu “Unit Testing”, do lado direito, é possível escolher o(s) teste(s) que pretendemos executar, como podemos ver na figura 11.

Xamarin Test Cloud: execução de testes

Figura 11: Execução de testes

Portanto, para o código fornecido pela classe Tests


    [TestFixture (Platform.Android)]
    [TestFixture (Platform.iOS)]
    public class Tests
    {
        IApp app;
        Platform platform;

        public Tests (Platform platform)
        {
            this.platform = platform;
        }

        [SetUp]
        public void BeforeEachTest ()
        {
            app = AppInitializer.StartApp (platform);
        }

        [Test]
        public void AppLaunches ()
        {
            app.Screenshot ("First screen.");
        }
}

O construtor da classe é invocado, e de seguida é invocado o método Setup que irá conhecer a plataforma para a qual os testes vão ser executados, e por fim o método AppLaunches é invocado e um screenshot é tirado. Considerando que vamos executar os testes apenas para iOS, a figura 12, mostra a aplicação no simulador de iOS.

Xamarin Test Cloud: Aplicação lançada pelo teste


Figura 12: Aplicação lançada pelo teste
O resultado da execução irá ser apresentado no painel Test Results, como podemos ver na figura 13.

Xamarin Test Cloud: resultado da execução dos testes


Figura 13: Resultado da execução do(s) teste(s)

Xamarin Test Record
Os testes de aceitação podem ser definidos manualmente, no entanto, a sua definição manual pode não ser um processo tão simples quanto isso. No lançamento do Xamarin 4, a Xamarin lançou a versão preview do Xamarin Test Record, que é uma aplicação que permite gravar as operações efetuadas na aplicação, ie, o Test Record irá escrever os testes, que irão verificar o comportamento da aplicação, que são obtidos pela execução manual da aplicação. Desta forma é possível replicar automaticamente o comportamento efetuado pelo utilizador.

À data da publicação deste artigo, o Xamarin Teste Record está apenas disponível para Mac, sendo possível obtê-lo em
https://xamarin.com/test-cloud/recorder.

XAMARIN 4.0 – TUDO O QUE PRECISA PARA CRIAR AS SUAS APLICAÇÕES MÓVEIS

Introdução

No primeiro semestre de 2014 a Xamarin lançou o Xamarin 3.0, que veio trazer às equipas de desenvolvimento de aplicações móveis muitas novidades, nomeadamente a framework Xamarin Forms que veio revolucionar a forma de desenvolvimento até então e para além disso possibilitou a criação de estratégias de reutilização de código, que permite diminuir o esforço de desenvolvimento entre as várias plataformas e claro está reduzir o tempo de manutenção.

Com isto, nos últimos meses muita tinta correu à volta das soluções oferecidas pela Xamarin, e com a publicação do Xamarin Test Cloud, Xamarin Insights e Xamarin Android Player, a Xamarin continuou a somar pontos.

Recentemente, em Novembro 2015, a Xamarin volta à carga com mais anúncios e apresenta o Xamarin 4.0, que apresenta muitas novidades que para quem está a fazer desenvolvimento de aplicações móveis deixa qualquer um soberbo, uma vez que a qualidade e leque de funcionalidades continua a crescer de forma exponencial, e consequentemente contribui para o bom desenvolvimento, e consequentemente boa qualidade e desempenho das aplicações.

Funcionalidades

O Xamarin 4.0 apresenta-se com uma nova versão da plataforma da Xamarin e da Xamarin Test Cloud, e torna público o Xamarin Insights, deixando este último de ser versão beta, como era até aqui.

As soluções da Xamarin vão fornecer ferramentas e APIs para facilitar o desenvolvimento, teste e monitorização, e claro está as estratégias de partilhar/reutilização de código permite que o desenvolvimento das aplicações para as várias plataformas seja mais rápido.

Xamarin 4: ciclo de uma aplicação móvel

Ao nível da framework Xamarin Forms, que se apresenta como Xamarin Forms 2.0, temos as principais novidades:

Melhorias de performance e de qualidade de API;
Suporte para pré compilação de ecrãs desenhados em XAML facilitando o carregamento da aplicação;
Suporte para Universal Windows Platform apps (ainda preview);
Suporte para iOS9 e Android Material Design;
Novas “gestures”: pinch e pull-to-refresh.
Para além destas novidades, a Xamarin apresenta melhorias no desenvolvimento de aplicações iOS usando Xamarin Plugin para Visual Studio, realizou atualizações na versão do Mono/.Net de forma a manter compatibilidades e aumentar a performance das suas soluções e melhorou a experiência ao nível de modo design para iOS (load and save XIB files) e Android (Android Material Design).

Ao nível do Xamarin Test Cloud, a Xamarin possibilita que as aplicações sejam testadas em +2k dispositivos reais de Android e iOS, o que sem dúvida é uma mais-valia para muitas equipas de desenvolvimento que muitas vezes só têm 2 ou 3 dispositivos. E é apresentado o Xamarin Test Recorder, aplicação “preview” disponível para Mac, que permite gravar todas as interações realizadas pelas aplicações iOS e Android e desta forma é possível criar scripts que depois podem correr no Xamarin Test Cloud ou importá-los para o Xamarin Studio/Visual Studio. Estes scripts baseiam-se em testes unitários que tiram partido da framework UITest e podem ser executados a partir de integração continua. Esta framework, Xamarin.UITest C#, é mais uma das novidades com o lançamento da sua primeira release e é completamente focada na criação de testes, é gratuita e sem limitações de utilização em simuladores ou devices. No entanto a combinação perfeita é o uso de Xamarin.UITest C# em conjunto com o Xamarin Test Cloud.

Xamarin 4: Xamarin Test Cloud

Ao nível do Xamarin Insights, a Xamarin orgulha-se na monitorização em tempo real e disponibiliza relatórios gratuitos para todos os utilizadores, no entanto com algumas limitações. Claro está fornece soluções mais avançadas para cenários que o exijam, o que é o caso das aplicações enterprise.

Para terminar, a Xamarin aproveitou este lançamento para estimar os seus clientes e ofereceu a todos os utilizadores ativos:

Relatórios de erros do Xamarin Insights, com retenção de dados até 30 dias;
60 minutos de Xamarin Test Cloud por mês;
30 dias de acesso à Xamarin University.
E para além disso a Xamarin apresenta novos planos sobre os seus produtos, planos estes mais direcionados a empresas.

Conclusão
Em conclusão, podemos concluir que a equipa da Xamarin continua a trabalhar arduamente para nos fornecer boas soluções de forma a facilitar o desenvolvimento de aplicações móveis e com o lançamento do Xamarin 4.0 nota-se a melhoria de qualidade e em muitos casos a voz do utilizador é tida em conta.

Referências

  • https://blog.xamarin.com/
  • http://developer.xamarin.com/
  • XAMARIN: O AMBIENTE DE DESENVOLVIMENTO EM WINDOWS & MAC

    Este artigo tem como objetivo mostrar como criar o ambiente de desenvolvimento cross-platform, em Windows & Mac, usando Xamarin.

    Introdução
    O ambiente de desenvolvimento de aplicações móveis depende da tecnologia em causa e os sistemas operativos em que estão disponíveis. Desta forma, os programadores de Objective-C terão de usar um Mac para fazer o desenvolvimento das suas aplicações, os programadores de Windows Phone e Windows Store Apps irão usar um Windows e os programadores de Android poderão fazê-lo tanto num Mac como num Windows.

    Usando a Xamarin Platform este cenário muda um pouco de figura, isto porque apesar de ser obrigatório ter um Mac para o desenvolvimento de iOS, é possível desenvolver aplicações iOS num Windows. De forma a clarificar como criar o ambiente para desenvolver e testar aplicações para Android, iOS e Windows ao mesmo tempo, irei apresentar os vários cenários possíveis.

    Descrição
    O ambiente de desenvolvimento disponível para um programador cross-platform é o maior fator de produtividade, influencia se o programador irá tirar partido desse mesmo desenvolvimento. Isto porque, se estamos a desenvolver para as várias plataformas, com o objetivo de partilhar o máximo código possível, vai haver momentos em que é necessário testar o comportamento das aplicações nas várias plataforma ao mesmo tempo.

    Ambiente Windows
    Consideremos um programador que tem disponível um Windows, neste cenário o programador poderá instalar o Xamarin Platform para Windows, que disponibiliza:

  • Xamarin Studio – ferramenta para o desenvolvimento (IDE) da Xamarin
  • Xamarim Studio

    Figura 1: Xamarin Studio

  • Xamarin Android – Android SDK fornecido pela Xamarin
  • Ao abrir no Xamarin Studio uma solução que contenha o projeto para as várias plataformas iremos obter algo do género:

    ENEI.SessionsApp Solution no Xamarin Studio para Windows

    Figura 2: ENEI.SessionsApp solution no Xamarin Studio para Windows
    Que nos permite constatar que no Xamarin Studio não existe suporte para aplicações iOS nem para Windows.

    O desenvolvimento de aplicações Windows é suportado pelas ferramentas e SDKs da Microsoft, sendo necessário instalar:

    Visual Studio 2013 ou Visual Studio 2015
    Windows Phone 8.1 SDK and Windows SDK for Windows 8.1
    O licenciamento do Xamarin Platform diz respeito à Xamarin, sendo que o licenciamento do Visual Studio já diz respeito à Microsoft e também deve ser tido em conta consoante estamos perante projetos open source/ensino ou aplicações comerciais.

    Abrindo a mesma solução no Visual Studio iremos ter neste momento:

    ENEI.SessionsApp solution no Visual Studio

    Figura 3: ENEI.SessionsApp solution no Visual Studio
    O que nos permite concluir que apenas podemos desenvolver aplicações para Windows, uma vez que os projetos para Android e iOS não são suportado. Desta forma, com base na figura 2 e figura 3 podemos constatar, que com o plano Free e Indie, temos que andar a saltar entre IDEs para fazermos o desenvolvimento de aplicações para Windows e Android.

    Com o objetivo de eliminar o problema apresentado acima, a Xamarin criou uma solução que está disponível para estudantes, programadores Open Source e utilizadores do plano Business:

    Xamarin Plugin para Visual Studio – plugin para dar suporte a projetos da Xamarin e permitir ligar ao Mac Build Host, e fazer deploy para simuladores e dispositivos
    Xamarin iOS – iOS SDK fornecido pela Xamarin
    Ao abrirmos a solução dos casos anteriores, iremos então obter:

    Suporte para Xamarin iOS e Android no Visual Studio


    Figura 4: Suporte para Xamarin iOS e Android no Visual Studio

    E desta forma, conseguimos ter compatibilidade das várias plataformas no mesmo IDE, o que sem dúvidas aumenta a produtividade do programador e a sua visão sobre o desenvolvimento cross-platform.

    Como mencionamos anteriormente, é necessário ter um Mac para fazer o build e deploy de aplicações de iOS, que é designado como Mac Build Host.

    Xamarin: Sem ligação ao Host


    Figura 5: Sem ligação ao Host

    Ao fazer Find Mac Build Host é necessário ter a aplicação do Build Host no Mac a correr:

    Xamarin: Aplicação Mac Build Host


    Figura 6: Aplicação Build Host
    E depois da ligação feita, usando o código fornecido, iremos ter:

    Xamarin: Build Host paired


    Figura 7: Build Host paired
    Xamarin: Ligado a um host


    Figura 8: Ligado a um host

    Neste caso, poderemos utilizar por exemplo um Mac Mini, para que o custo com o um Mac seja o mais baixo possível e depois só é preciso fazer um acesso remoto para usar o simulador de iOS e fazer as ligações com o Build Host. No caso de em que o programador usa dispositivo é preciso que este esteja conectado ao Mac para que seja possível fazer o deploy da aplicação.

    Xamarin: ligação Mac/iOS


    Figura 9: Host

    Ambiente Mac
    Consideremos um programador que tem disponível um Mac, neste cenário o programador poderá instalar o Xamarin Platform para Mac, que disponibiliza:

    Xamarin Studio – ferramenta para o desenvolvimento (IDE) da Xamarin
    Xamarin Studio para Mac


    Figura 10: Xamarin Studio para Mac

    Xamarin iOS – iOS SDK fornecido pela Xamarin
    Xamarin Android – Android SDK fornecido pela Xamarin
    E ao abrir a solução de exemplo, iremos obter:

    ENEI.SessionsApp no Xamarin Studio para Mac


    Figura 11: ENEI.SessionsApp no Xamarin Studio

    Com isto é possível constatar que num Mac é possível fazer o desenvolvimentos de aplicações de Android e iOS em simultâneo, não havendo no entanto suporte para aplicações Windows que requerem um dispositivo Windows.

    Ambiente Misto
    Nos casos anteriores, consigo ver o ambiente para desenvolver aplicações cross-platform, em Windows e Mac, usando Xamarin. Neste cenário, o objetivo consiste em mostrar como ter um ambiente misto com um nível de produtividade maior.

    Suponhamos que temos um Mac com 16GB de RAM e 512GB de disco, suponhamos também que temos VMWare ou Parallels, desta forma é possível criar uma máquina virtual com o Windows com por exemplo 8GB de Ram e 128GB de disco, permitindo desta forma ter uma performance e uso equivalente a um PC com Windows.

    Windows a correr no Parallels (Mac)


    Figura 12: Windows a correr no Parallels (Mac)
    O que ganhamos neste caso, é que temos um único PC com 2 sistemas operativos, e com isto temos o suporte para todas as plataformas com um conforto de trabalho elevado. No entanto, é preciso ter noção que não é muito recomendado ou até mesmo possível ter simuladores dentro de máquinas virtuais. Refiro-me ao simulador de Windows Phone e de Android, desta forma para resolver esta questão a solução passa por usar um dispositivo Windows Phone conectado à máquina virtual Windows, para que o Visual Studio reconheça o dispositivo e com a aplicação Project My Screen App é possível partilhar o ecrã do dispositivo Windows Phone. Ao nível do Android, a melhor solução passa por usar o Xamarin Android Player, a correr no Mac, que permite o Visual Studio fazer o deploy para este, usando a aplicação ADB fornecida pela Google.

    Xamarin: As várias plataformas num ambiente misto


    Figura 13: As várias plataformas num ambiente misto
    Para mais informações consulta as seguintes referências da Xamarin:

  • Installing Xamarin.iOS
  • Installing Xamarin.Android
  • Simuladores

    No desenvolvimento de aplicações móveis é muito comum os programadores usarem simuladores para realizar testes à aplicação, no entanto o feedback de um dispositivo real é muito diferente de um simulador e os programadores devem realizar testes mínimos em ambos os casos.

    Para desenvolvimento Windows e iOS é possível utilizar os simuladores fornecidos pela Microsoft e Apple (respetivamente), no entanto, no caso de Android os simuladores fornecidos pelo Android SDK (da Google) são muito lentos e pouco friendly, por esta razão muitos programadores têm escolhido os seguintes simuladores:

  • Xamarin Android Player
  • Genymotion
  • Que disponibilizam simuladores para vários dispositivos e resoluções.

    Conclusão
    Em conclusão, podemos concluir que o desenvolvimento cross-platform tem vantagens quando o seu ambiente de desenvolvimento está criado de forma a maximizar a rentabilidade do programador e minimizando o tempo necessário para desenvolve-lo e testa-lo, e consequente irá aumentar a capacidade para aumentar o código partilhado entre as várias plataformas.

    XAMARIN: SEM CUSTOS PARA ESTUDANTES

    Introdução

    Xamarin é uma empresa americana, mais especificamente de São Francisco, que foi criada em 2011, por engenheiros que trabalharam nos projetos  MonoMonoTouch e Mono for Android. Esta empresa tem foco no desenvolvimento de software que irá permitir que os programadores de aplicações móveis criem aplicações usando C# ou F#, que corram em dispositivos Android e IOS, como se de aplicações nativas se tratasse.

    Do leque de produtos da Xamarin, destacamos a Plataforma Xamarin (representa um conjunto de ferramentas e produtos para desenvolvimentos de aplicações móveis, onde o Xamarin.Android, o Xamarin.IOS, o Xamarin Studio e o Xamarin para Visual Studio se incluem), o Xamarin Test Cloud (serviço que permite testar aplicações em diversos dispositivos físicos), o Xamarin Insights (serviço que permite acompanhar em tempo real o funcionamento das aplicações, fornecendo relatórios de erros, eventos e ajuda a compreender como os utilizadores usam a aplicação, baseado nos eventos ocorridos na aplicação).

    Visão geral sobre o desenvolvimento

    As ferramentas da Xamarin, mais especificamente o IDE Xamarin Studio e o Xamarin para Visual Studio, vão permitir que os programadores façam um desenvolvimento cross-platform de aplicações para os dispositivos Android e IOS, permitindo assim a partilha de código comum e um desenvolvimento mais rápido das aplicações. Isto só irá ser possível através do Xamarin.Android e Xamarin.IOS que representa o conjunto de ferramentas e SDK necessário para desenvolver aplicações Android e IOS, respetivamente.

    Muitos dos programadores poderão não estar familiarizados com o conceito cross-platform, que de uma forma geral, consiste em partilhar um conjunto de funcionalidades comum às várias plataformas (a partilha da camada de acesso a web services é um bom exemplo, pois será igual para qualquer plataforma), fazendo com que todo o processo de desenvolvimento e manutenção seja mais reduzido. É claro que iremos ter funcionalidades específicas de cada plataforma (exemplo disso é a interface com o utilizador). Através do “Abstraction Pattern” é possível criar classes que representem funcionalidades comuns e em que a sua implementação será específica de cada plataforma. Para os mais interessados, que queiram ver um exemplo em concreto, consultem o projeto Open Source XFLabs, mais especificamente o serviço para tirar fotografias, a Camera.

    No primeiro semestre de 2014, foi lançado o Xamarin Forms que é uma biblioteca que define uma abstração da interface com o utilizador, permitindo que o código partilhado entre as diferentes plataformas seja ainda maior, não esquecendo que poderá haver sempre aspetos específicos da plataforma (o uso de “Renders” poderá minimizar esses aspetos específicos).

    Várias camadas de reutilização de código e especificidade de cada plataforma, usando Xamarin Forms.

    Nota: Para o desenvolvimento de aplicações Windows teremos que usar as ferramentas e SDKs fornecidos pela Microsoft, sendo isso externo aos produtos Xamarin. E todas as aplicações criadas podem ser submetidas na loja da Apple, na PlayStore, Windows Phone Store, entre outras.

    Para os interessados em consultar os preços dos vários produtos, devem consultar a loja da Xamarin em store.xamarin.com.

    Plataforma Xamarin para estudantes

    No passado mês de Novembro, a Xamarin anunciou que a Plataforma Xamarin passaria a ser gratuita para estudantes, o que significa que os estudantes passam a ter acesso gratuito às licenças INDIE do Xamarin.Android e Xamarin.IOS, antes deste anuncio o preço era de $99 anuais.

    Os interessados nesta oferta devem preencher o formulário na seguinte referência xamarin.com/student e aguardar que seja solicitada a verificação do estatuto de estudante. Em caso de dúvidas devem usar o email students@xamarin.com.

    Os professores poderão entrar em contacto com a Xamarin, para terem acesso às ferramentas e material didáctico, usando o email education@xamarin.com.

    Programa Xamarin Student Ambassador

    A Xamarin não ficou por aqui em relação aos anúncios para estudantes, e lançou o programa Xamarin Student Ambassador, programa este destinado para potenciais estudantes que gostem de criar aplicações, ensinar os outros, estar sempre na vanguarda da tecnologia e fazer apresentações. E claro, oferecendo em troca um conjunto de benefícios bastante interessantes.

    Os interessados devem preencher o formulário Xamarin Student Ambassador Application. E em caso de dúvida devem usar  o email education@xamarin.com.                              

    A Comunidade XamarinPT