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.

    Using Entity Framework First Migration in Azure Mobile Services

    Scope
    The purpose of this article is to show how to use Entity Framework Code First Migrations Jump in Azure Mobile Services to create and update the database used in the model.

    Introduction
    Microsoft Azure Mobile Services is an Azure service offering designed to make it easy to create highly-functional mobile apps using Azure. Mobile Services brings together a set of Azure services adding back-end capabilities to your apps.

    In Azure Mobile Services, there are multiple ways to create the database, it can be created manually in SQL Server Management Studio or Visual Studio, or from code using Code First Migrations Jump or IDatabaseInitializer Jump . By default, Azure Mobile Service uses database initializers, like as can be seen in the following WebApiConfig class from the project created:

    
    namespace AzureMobileService
    {
        public static class WebApiConfig
        {
            public static void Register()
            {
                // Use this class to set configuration options for your mobile service
                ConfigOptions options = new ConfigOptions();
         
                // Use this class to set WebAPI configuration options
                HttpConfiguration config = ServiceConfig.Initialize(new ConfigBuilder(options));
         
                // To display errors in the browser during development, uncomment the following
                // line. Comment it out again when you deploy your service for production use.
                // config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
         
                Database.SetInitializer(new MobileServiceInitializer());
            }
        }
         
        public class MobileServiceInitializer : DropCreateDatabaseIfModelChanges
        {
            protected override void Seed(MobileServiceContext context)
            {
                List todoItems = new List
                {
                    new TodoItem { Id = Guid.NewGuid().ToString(), Text = "First item", Complete = false },
                    new TodoItem { Id = Guid.NewGuid().ToString(), Text = "Second item", Complete = false },
                };
         
                foreach (TodoItem todoItem in todoItems)
                {
                    context.Set().Add(todoItem);
                }
         
                base.Seed(context);
            }
        }
    }
    
    

    As we can see, the MobileServiceInitializer implements the DropCreateDatabaseIfModelChanges Jump
    , it is an implementation of IDatabaseInitializer Jump that will DELETE, recreate and optionally re-seed the database only if the model has changed, since the database was created. If the model doesn’t change we can use it, but “Are we sure that the model will not change in future?” this way maybe this solution is not the best solution to create the database.
    Note: There are other IDatabaseInitializers that can be used, but the problem is the same, data will be lost if the model changes.

    In this article we will use Entity Framework – Code First Migrations, that means we create the model first and then create the database based in the model structure, this process happens when we do a deploy and we will see common issues related with migrations in Azure Mobile Services.

    Description
    Create a .Net Backend as in the following:

    Figure 1 Creating an Azure Mobile Service

    Then create a class diagram as in Figure 2, to understand the project.

    Note: Read more about creating the class diagram in the article Class diagram: an easy way to understand code.

    Figure 2 The class diagram

    This way, we can conclude, by default an Azure Mobile Service has at least the following classes:

  • TodoItem: define the model and at the same time the DTO
  • MobileServiceContext: implement the DbContext from the Entity Framework
  • TodoItemController: define the service to expose CRUD operation to the TodoItem
  • And the model defined by TodoItem is the DTO provided by the service defined in the TodoItemController.

    Notes:

  • 1. We could create another model but it is not important for the article, this way we will use the model provided by default.
  • 2. TodoItem implements the EntityData from the Azure Mobile Service SDK and each DTO should implement this class because it is necessary to use the offline feature provided by Azure Mobile Services and to create a TableController we need it.
  • Enable Migrations
    At this moment we understand the model and the DbContext, but before starting with the migrations process we need to define the connection string to a New database in WebConfig. Now we need to enable the project to have migrations, for that open the “Package Manager Console” as in the following:


    Figure 3 Opening Package Manager Console

    The following window will be opened:

    Figure 4 Package Manager Console

    To enable migration it is necessary to run “Enable-Migrations” in the “Package Manager Console” and the “Default project” should be selected based on the project that contains the DbContext:

    Figure 5 Enable Migrations

    This operation will result in a new folder, called Migrations with a new class, in the project, like we can see in the Figure 6.

    Figure 6 Migrations folder

    The class added, the Configuration, is defined by:

    
    internal sealed class Configuration : DbMigrationsConfiguration
    {
        public Configuration()
        {
            AutomaticMigrationsEnabled = false;
        }
        
        protected override void Seed(AzureMobileService.Models.MobileServiceContext context)
        {
            //  This method will be called after migrating to the latest version.
        
            //  You can use the DbSet.AddOrUpdate() helper extension method 
            //  to avoid creating duplicate seed data. E.g.
            //
            //    context.People.AddOrUpdate(
            //      p => p.FullName,
            //      new Person { FullName = "Andrew Peters" },
            //      new Person { FullName = "Brice Lambson" },
            //      new Person { FullName = "Rowan Miller" }
            //    );
            //
        }
    }
    
    

    And this class will be responsible for creating, updating or deleting the database depending on the migration provided and it is possible to populate the database with the initial data using the seed method. The seed method can be used to create fake data or add initial data to the database and all developers should be aware that the method can run more than one time, with it it is necessary to verify that the data is not cloned.
    Let’s define some data in the Seed method, as in the following:

    
    internal sealed class Configuration : DbMigrationsConfiguration
    {
        /// 
        /// Initializes a new instance of the  class.
        /// 
        public Configuration()
        {
            AutomaticMigrationsEnabled = false;
        }
        
        /// 
        /// Seeds the specified context.
        /// 
        /// The context.
        protected override void Seed(Models.MobileServiceContext context)
        {
            context.TodoItems.AddOrUpdate(
                  p => p.Id,
                  new TodoItem { Id = Guid.NewGuid().ToString(), Text = "Clean the car." },
                  new TodoItem { Id = Guid.NewGuid().ToString(), Text = "Read a book" }
                );
        }
    }
    
    

    Add Migration
    Before adding the migration all developers should be aware that in the MobileServiceContext class we have the method.

    
    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        string schema = ServiceSettingsDictionary.GetSchemaName();
        if (!string.IsNullOrEmpty(schema))
        {
            modelBuilder.HasDefaultSchema(schema);
        }
        
        modelBuilder.Conventions.Add(
            new AttributeToColumnAnnotationConvention(
                "ServiceTableColumn", (property, attributes) => attributes.Single().ColumnType.ToString()));
    }
    
    

    And in this method will be defined the name of the schema used by the database and the name of the schema is defined in the WebConfig file, as in the following:

    
        
        
    
    

    Where the value “migrations” is the name of the Azure Mobile Service, if the schema name and the Azure Mobile Service’s name does not match the migration, it will fail because of the default user, used by the Azure Mobile Service created, do not have permissions to change the schema name or is possible to get an error saying that the user do not have permission to access the master database.

    We can then add the migration and for that, we need to run “Add-Migration Initial” in “Package Manager Console”, this command will use the model defined in the project and will compare it with the database, to create the migration.


    Figure 7 Adding migration Initial

    The result will be something as in the following:

    Figure 8 The migration

    The Initial class will define the migration and the Up method to create the database and the table “AzureMobileService.TodoItems” and the Down method will do the reverse. The Initial class will be defined by:

    
    public partial class Initial : DbMigration
    {
        public override void Up()
        {
            CreateTable(
                "migrations.TodoItems",
                c => new
                    {
                        Id = c.String(nullable: false, maxLength: 128,
                            annotations: new Dictionary
                            {
                                { 
                                    "ServiceTableColumn",
                                    new AnnotationValues(oldValue: null, newValue: "Id")
                                },
                            }),
                        Text = c.String(),
                        Complete = c.Boolean(nullable: false),
                        Version = c.Binary(nullable: false, fixedLength: true, timestamp: true, storeType: "rowversion",
                            annotations: new Dictionary
                            {
                                { 
                                    "ServiceTableColumn",
                                    new AnnotationValues(oldValue: null, newValue: "Version")
                                },
                            }),
                        CreatedAt = c.DateTimeOffset(nullable: false, precision: 7,
                            annotations: new Dictionary
                            {
                                { 
                                    "ServiceTableColumn",
                                    new AnnotationValues(oldValue: null, newValue: "CreatedAt")
                                },
                            }),
                        UpdatedAt = c.DateTimeOffset(precision: 7,
                            annotations: new Dictionary
                            {
                                { 
                                    "ServiceTableColumn",
                                    new AnnotationValues(oldValue: null, newValue: "UpdatedAt")
                                },
                            }),
                        Deleted = c.Boolean(nullable: false,
                            annotations: new Dictionary
                            {
                                { 
                                    "ServiceTableColumn",
                                    new AnnotationValues(oldValue: null, newValue: "Deleted")
                                },
                            }),
                    })
                .PrimaryKey(t => t.Id)
                .Index(t => t.CreatedAt, clustered: true);
                
        }
            
        public override void Down()
        {
            DropIndex("migrations.TodoItems", new[] { "CreatedAt" });
            DropTable("migrations.TodoItems",
                removedColumnAnnotations: new Dictionary>
                {
                    {
                        "CreatedAt",
                        new Dictionary
                        {
                            { "ServiceTableColumn", "CreatedAt" },
                        }
                    },
                    {
                        "Deleted",
                        new Dictionary
                        {
                            { "ServiceTableColumn", "Deleted" },
                        }
                    },
                    {
                        "Id",
                        new Dictionary
                        {
                            { "ServiceTableColumn", "Id" },
                        }
                    },
                    {
                        "UpdatedAt",
                        new Dictionary
                        {
                            { "ServiceTableColumn", "UpdatedAt" },
                        }
                    },
                    {
                        "Version",
                        new Dictionary
                        {
                            { "ServiceTableColumn", "Version" },
                        }
                    },
                });
        }
    }
    
    

    Run the migration
    Now that we have the migration defined we can run the project but the database will not be created, because we did not define how the project will run the migration or we do not update the database using “Update-Database” or “Update-Database -script” as we can see in Figure 9.

    Figure 9 Creating the SQL script

    This operation will create a SQL script that can be used to create or even update the database if the developer would like.

    In Azure Mobile Services, we use.

    
    var migrator = new DbMigrator(new Configuration());
    migrator.Update();
    
    

    To run the migration that will be defined in WebApiConfig.
    To avoid the issue about “Not found bootstrapper”, we need to change the WebApiConfig to:

    
    public class WebApiConfig : IBootstrapper
    {
        /// 
        /// Defines the entry point for the application. It is the responsibility of this entry point
        /// to call  which will start the configuration of the application.
        /// 
        public void Initialize()
        {
            // Use this class to set configuration options for your mobile service
            ConfigOptions options = new ConfigOptions();
        
            // Use this class to set WebAPI configuration options
            HttpConfiguration config = ServiceConfig.Initialize(new ConfigBuilder(options));
        
            // To display errors in the browser during development, uncomment the following
            // line. Comment it out again when you deploy your service for production use.
            config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
        
            var migrator = new DbMigrator(new Configuration());
            migrator.Update();
        }
    }
    
    

    And then we need to change the WebApiApplication, as in the following:

    
    public class WebApiApplication : System.Web.HttpApplication
    {
        /// 
        /// The _web API configuration
        /// 
        private readonly WebApiConfig _webApiConfig;
        
        /// 
        /// Initializes a new instance of the  class.
        /// 
        public WebApiApplication()
        {
            _webApiConfig = new WebApiConfig();
        }
        
        /// 
        /// Application_s the start.
        /// 
        protected void Application_Start()
        {
            _webApiConfig.Initialize();
        }
    }
    
    

    Each developer should be aware that when the Initialize method is run, each time the application starts, it will create or update the database based in the migrations defined by the current model.
    Publishing the services:

    Figure 10 publishing the service

    It is possible to use the following publishing process using the “Web Publish Activity”, as we can see in Figure 11.

    Figure 11 Web Publish Activity

    Note: When we do the publish the Azure Mobile Service will replace some configuration from WebConfig, if you want to see the final WebConfig see this article
    article

    The browser will be opened, as in the following:

    Figure 12 Azure Mobile Service running

    And we can request the TodoItems in “try this out”, like we can see in the Figure 13.


    Figure 13 Try it out

    Or in the database:


    Figure 14 Data in database

    Figure 15 Log

    Handle errors
    Changing the model

    The backend can change and with it the model can change. If we change the model without creating the respective migration we will receive an error like this.

    Error:
    Boot strapping failed: executing ‘WebApiConfig’ caused an exception: ‘Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.”

    Figure 16 Azure Mobile Service with errors

    Let’s change the model to something as in the following:

    
    public class TodoItem : EntityData
    {
        public string Text { get; set; }
        
        public string Name { get; set; }
        
        public bool Complete { get; set; }
    }
    
    

    Then we need to add a new migration, for that we need to run “Add-Migration SecondMigration” in “Package Manager Console”, as in the following:
    PM> add-migration SecondMigration

    Scaffolding migration ‘SecondMigration’.

    The Designer Code for this migration file includes a snapshot of your current Code First model. This snapshot is used to calculate the changes to your model when you scaffold the next migration. If you make additional changes to your model that you want to include in this migration, then you can re-scaffold it by running ‘Add-Migration SecondMigration’ again.

    PM>

    And the result will be:

    
    public partial class SecondMigration : DbMigration
    {
        public override void Up()
        {
            AddColumn("migrations.TodoItems", "Name", c => c.String());
            DropColumn("migrations.TodoItems", "DueDate");
        }
            
        public override void Down()
        {
            AddColumn("migrations.TodoItems", "DueDate", c => c.DateTime(nullable: false));
            DropColumn("migrations.TodoItems", "Name");
        }
    }
    
    

    If we change the seed method to:

    
    protected override void Seed(Models.MobileServiceContext context)
    {
        context.TodoItems.AddOrUpdate(
              p => p.Id,
              new TodoItem { Id = Guid.NewGuid().ToString(), Text = "Clean the car.", Name = "MyTask"},
              new TodoItem { Id = Guid.NewGuid().ToString(), Text = "Read a book", Name = "MyHobbies" }
            );
    }
    
    

    After that we can publish the Azure Mobile Service and the result will be:

    Figure 17 Try this out

    And:

    Developers should be aware that the seed method added new items that has the same “Text” as the first items added but in this case the “Name” is filled. This was a sample from a common issue we can create when populating data during multiple migrations.

    Note: If the connecting string, defined in WebConfig, is not using the correct reference, this process can fail with the following error.

    PM> add-migration SecondMigration

    Unable to generate an explicit migration because the following explicit migrations are pending: [201501162340213_Initial]. Apply the pending explicit migrations before attempting to generate a new explicit migration.

    PM>

    Deleting the Database
    If during the process, we delete the database and then we try to run the services we will get:


    This way, the default user, used by the Azure Mobile Service created, does not have permissions to access the master database.

    The errors we got with the default user are related to the fact the user only has a few permissions for security reasons. Creating a database user will avoid this kind of issue.

    Conclusion
    In conclusion, we can conclude that EF CodeFirst Migration is a good way to manage the various changes made in the model and this way any time an Azure Mobile Service is deployed it will create or update the associated database without additional work, with initial data or not.

    If we are using the default user to access the database:

  • The user cannot access the master to re-create the database.
  • The database schema must have the same name as the Azure Mobile Service.
  • If we create a database user to avoid the two last problems, you need to ignore the default connection string (MS_TableConnectionString) and you need to create your own connection string (for example: MyTableConnectionString where you need to define all required fields to the database and should be added the user created to avoid the issues).
    Personal opinion + Disclaimer:
    I have lost so much time from this problem and in the end I prefer to create and use my own database user to simplify the process and define my own key to the connection string (that can be defined in the configuration panel). In my experience the user is changed time to time and it happened to me more than one time. Never found it in the documentation.

    Azure Mobile Services: how to update a .NET back end project

    Scope
    This article has the goal to show how to update a .NET back end project from Azure Mobile Services, this means we will update the project references using Nuget packages.

    Introduction
    Microsoft Azure Mobile Services is an Azure service offering designed to make it easy to create highly-functional mobile apps using Azure. Mobile Services brings together a set of Azure services that enable back end capabilities for your apps.

    When a developer creates a .NET back end project from Azure Mobile Services, several NuGet packages will be installed, for example, if the project is created in Visual Studio 2013 – Update 4, like we can see in the Image 1:

    Image 1 Creating the Azure Mobile Service

    The default package files will be like as follows:

    
    
    
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
    
    

    But if we “Manage NuGet Packages” and select “Updates”, the windows will show that there are updates that we can do like we can see in the Image 2:

    Image 2 Manage NuGet Packages – Available Updates

    the first thing we can try to do is to click in the “Update All” button, that will make sense for the developers, but then we will get something as we can see in the Image 3:

    Image 3 Error updating all

    And you have a world of nightmares. Updating the NuGet packages from Azure Mobile Services start adds 36 NuGet packages to the project and is extremely challenging to understand the dependencies between the different NuGet packages. If we start updating one by one we will get errors as in Image 4 below. It is not practical to update this one by one – this article shows how to avoid the problem.

    Image 4 Azure Mobile Service with errors

    It means the reference added to the project is not the same version used by any NuGet and can be hard to understand which is the right version.

    Description

    To understand the NuGet packages and because our project is an Azure Mobile Service project, we can start by analyzing the packages.

    In the NuGet website, we found.

    Microsoft Azure Mobile Services .NET back end 1.0.405 

    Has the dependencies:

    Has the dependencies:

    Has the dependencies:

    This way, we can conclude the Microsoft Azure Mobile Services .NET Backend Entity Framework Extension 1.0.405   NuGet depends on the WindowsAzure.MobileServices.Backend.Tables   NuGet and this depend on the WindowsAzure.MobileServices.Backend   NuGet. This mean if we update the Microsoft Azure Mobile Services .NET Backend Entity Framework Extension   NuGet the references related with Azure Mobile Service will be updated.

    In the “Manage NuGet Package” click on update the Microsoft Azure Mobile Services .NET Backend Entity Framework Extension   NuGet, as we can see in the Image 5:


    Image 5 Updating Nuget
    And then, click “I Accept”

    Image 6 License

    We get

    Image 7 NuGet packages updated

    With this another question can be raised, “Did we update all NuGet packages we can?” and this question can be found by uninstalling the Microsoft Azure Mobile Services .NET Backend Entity Framework Extension Jump NuGet, as in the Image 8.


    Image 8 Uninstall Nuget

    Uninstall this NuGet will request a confirmation to uninstall all dependencies, as in the Image 9, where we will click in “Yes”.


    Image 9 Nuget packages to remove

    The result will be

    Image 10 The service running in localhost

    And the package file updated to

    
    
    
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
    
    
    

    Returning back to the “Updates”, we will see the NuGet packages, in the Image 11 that we can update, but for the reasons we saw, it is not possible to update all.


    Image 11 Manage NuGet Packages

    Conclusion
    In conclusion, each developer should be aware of the dependencies between NuGet packages and more than one package can depend from the same NuGet package but for different versions, this means is required to keep the versions used by each one.

    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

    Azure Mobile Services: How to Create a Dev and Prod Environment

    Scope

    This article has the goal to show how to create a development and production environment for a .Net Backend from Azure Mobile Services.

    Introduction

    From the MSDN Documentation  ,

    Microsoft Azure Mobile Services is an Azure service offering designed to make it easy to create highly-functional mobile apps using Azure. Mobile Services brings together a set of Azure services that enable backend capabilities for your apps. Mobile Services provides the following backend capabilities in Azure to support your apps:

    • Client libraries support mobile app development on various devices, including Windows 8, Windows Phone 8, iPhone, and iPad.
    • Simple provisioning and management of tables for storing app data.
    • Integration with notification services to deliver push notifications to your app.
    • Integration with well-known identity providers for authentication.
    • Precise control for authorizing access to tables.
    • Supports scripts to inject business logic into data access operations.
    • Integration with other cloud services.
    • Supports the ability to scale a mobile service instance.
    • Service monitoring and logging.

    Azure Mobile Services is great for mobile application development with client libraries for both Apple and Microsoft mobile platforms.

    There are various scenarios where one requires multiple environments for an Azure Mobile Service.
    These include:

    • Breaking changes between published versions of an app.
    • Different configurations for test and production.

    Different environments are necessary in order to have different configurations for a given Azure Mobile Service. Azure Mobile Services allows testing in localhost, but do not provide a way to have different environments.  

    Description

    To create a development and production environment for a .Net Backend – Azure Mobile Services is required to create a Dev and Prod Backend and then is possible to create the Dev and Prod profiles based on transform files.

    Let’s see it in more detail.

    Creating the Azure Mobile Services

    In Azure Portal, create two .Net Backend – Azure Mobile Service, let’s call it as following

    • For the development environment:
      • MyAMSDev – the Azure Mobile Service name
      • MyAMSDev_db – the database name
    • For the production environment:
      • MyAMSProd – the Azure Mobile Service name
      • MyAMSProd_db – the database name

    In Azure Portal, the result will be azure portal

    And

    azure portal

    Is possible to use the same database, but it is necessary to use different schemas and if different databases are provided is easier to manage each environment (update or even delete). A Backend that uses Entity Framework migrations will recreate the service from the scraps and with it any time it can be deleted, deployed and recreated.

    To read more about the steps required to create an Azure Mobile Service, read the following article

    How to create the MyMenuApp Azure Mobile Service  .

    Creating a Transform File

    In Visual Studio, select the solution and open the context menu as following

    azure mobile service

    After it, click in Configuration Manager as following

    azure mobile service

    And then create a new configuration as following

    azure mobile service
    azure mobile service

    In this case, a Dev configuration is defined based on Debug configuration and to the Prod configuration should be used the Release configuration as following

    azure mobile service

    At this moment, is possible to define Debug, Dev, Prod and Release configuration

    azure mobile service

    For each configuration is possible to define the conditional compilation. For example, in Dev is possible to have

    azure mobile service

    In reality, it means, we can do

    #if Dev

    // for example can fill the database with fake data

    #else

    // in another environment different from Dev

    #endif

    To have advantages of this configuration using the Web.Config, let’s add the config transform as following

    azure mobile service

    Which the result will be

    azure mobile service

    Now is possible

    – To set in the Web.Config, the connection string to the local database, used by the localhost

     <connectionStrings>
        <add name="MS_TableConnectionString1" connectionString="Data Source=LT114925;Initial Catalog=MyAMSLocal;Integrated Security=True;MultipleActiveResultSets=true" providerName="System.Data.SqlClient" />
       </connectionStrings>

    – To set in the Web.Dev.Config, the connection string to the MyAMSDev_db database, used by the Dev environment (or even the localhost!)

    <connectionStrings>
          <add name="MS_TableConnectionString1"
    connectionString="<connection string from MyAMSDev_db>"
    xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
        </connectionStrings>

    – To set in the Web.Prod.Config, the connection string to the MyAMSProd_db database, used by the Prod environment

       <connectionStrings>
          <add name="MS_TableConnectionString1"
    connectionString="<connection string from MyAMSProd_db>"
    xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
        </connectionStrings>

    And in each deploy, the respective configs will be used.

    Let’s publish the service to the Azure.

    Select the project and using the context menu click in Publish, as following

    azure mobile service

    Then connect to Azure Mobile Service, using the Azure Account, and select the MyAMSDev as following

    azure mobile service

    In Settings, set the configuration and the file publish options (only!)

    azure mobile service

    And then publish it!

    Do the same process to Prod, as following

    azure mobile service

    And then publish it!

    Is possible to see the Web Publish Activity that shows the publish process

    Jump

    At this moment, both environments are deployed and running and are not required to define or change each environment in the future, only is needed to have attended each one is set before deploy.

    Notes

      1. In this case, was using the MS_TableConnectionString1 name for defining the connection string and the default value MS_TableConnectionString, defined in Azure Portal, will be ignored.
      A developer can to set different connect string or even change the name, but needs to be defined with the same name in all environments.
      1. With the Visual Studio 2013 – update 4 is possible to change the database in Settings separator but in this case, it will be ignored!

    For more information about the transform file, read the following article

    How to: Transform Web.config When Deploying a Web Application Project 

    Conclusion

    In conclusion, creating different environments for a .Net Backend – Azure Mobile Service is an easy task that is a plus in the development, which allow testing new features before it goes to production and it allows to make sure the tests done in localhost will keep working in the Azure Mobile Service without to affect the production environment.

    Microsoft’s Windows App Studio Beta : Connecting a Menu App to Azure Mobile Service

    Scope

    This article aims to connect the Menu App from Windows App Studio with Azure Mobile Service, using .Net back end.

    Introduction

    Windows App Studio   is a service that allows any person without programming skills to create applications for Windows Phone and Windows. In just 4 steps: have an idea, add content, choose the style and use the application. The service provides a set of templates to help the users in creating various applications, theses templates are great starting points for specific uses which are more frequently used.

    To understand all the steps for creating an app using App Studio   see the article Creating Windows Phone and Window 8.1 applications using Microsoft App Studio. This article explains the Contoso Template and the Web Template.

    Menu Template

    Menu Template is one template provide by App Studio  , and it is used for the following scenario:

    “Do you own a restaurant, or have a favorite place you go every week? Use this template to show your customers or your friends about the delicious meal they’ll find there. With easy-to-navigate sections and pictures for starters, main courses and desserts.”

    The template provides

    • A menu for
      • Starters

        Contains a list of all starters

      • Mains

      Contains a list of all mains

      • Desserts

        Contains a list of all desserts

      • Beverages

      Contains a list of all beverages

    • A list of special offers

    When the template is created, the default data uses static resources

    If we click in “Edit data”, we will see the following screen

    Windows App Studio   allows us to export and import data, but each time we need to edit data, we need to publish the new version in the Store unless we select dynamic resources. For help in this process we will create a .Net Backend in Azure Mobile Service that allows us to manage the data that will be consumed by the Menu App.

    See the default Menu App, for Windows Phone 8.1 and Windows 8.1 that was generated by 
    Step 1: Add default Menu App generated by AppStudio. 

    Understanding the source code

    The source code provided has a solution that contains the following projects:

    • AppStudio.Windows – project for Windows Store App
    • AppStudio.WindowsPhone – project for the Windows Phone App
    • AppStudio.Shared – shared project used for both target (it allow to reuse code)
    • AppStudio.Data – project that contains the model and data source.

    In AppStudio.Data project is possible to generate the class diagrams for understand the model and the data sources used in the application. This will be useful later.

    The Model
    The model contains all classes that represent the structure of the data used in the application.

    Each class has more properties (DefaultTitle, DefaultSummary, DefaultImageUrl and DefaultContent), that uses the properties showed in class diagram and these properties only helps the automation used by App Studio  , for this reason it was ignored.

    The data sources

    The data sources contains all classes that will provide the data that will fill the UI.

    Each data source has a LoadDataAsync method that is called by each target to fill the data in UI.

    Code

    See the changes made in default Menu App, here:Step 2: Add class diagrams and fixes issues related with nomenclature. Jump

    Note: It is possible to change any code in the solution, but it is not possible to upload those changes back to Windows App Studio  . Any change in AppStudio should be merged with changes made in Visual Studio.

    Requirements

    To use Azure Mobile Services it’s required to have an Azure Account and the Azure SDK should be installed.

    Azure Account

    Before starting the backend development it’s required to create an Azure account in the Azure Website  . For new users there is a trial version that can be used, see more about it here  .

    Azure SDK

    Get the Azure SDK and install it, from Downloads Jump .

    How to create the Azure Mobile Service in Azure Portal

    For see details about how to create an Azure Mobile Service in Azure Portal and how to create the Visual Studio 2013 project, see the article

    How to create the MyMenuApp Azure Mobile Service. 

    How to create the Azure Mobile Services

    In the topic, “Understanding the source code > the model” we saw the model used in the Menu App, and it is important for the services. Recap, the model has theses classes

    Each class represents specific information inside of the app and the service should allow us to store data for each class (this is the insert operation) and of course support for getting all items, get item by id, update an item and delete an item.Based in these classes, we will create the follow services

    • MainSchemaController – the service for managing the MainSchemas
    • SpecialOffersSchemaController – the service for managing the SpecialOffersSchemas
    • DessertsSchemaController – the service for managingthe DessertsSchemas
    • StartersSchemaController – the service for managing the StartersSchemas
    • BeveragesSchemaController – the service for managing the BeveragesSchemas

    Each service ends with the word “Controller” because this is a pattern from WebApi  , which is the base for Azure Mobile Services and starts with the name of the related object, normally called Dto  . Each developer should be aware of this, because these names will be used internally and if it does not match with the kind of pattern it can cause some problems in consuming the services, in serialization, or when client apps request specific queries.The data objects (Dtos) will be:

    • MainSchema
    • SpecialOffersSchema
    • DessertsSchema
    • StartersSchema
    • BeveragesSchema

    Each one will have the same structure as in the client app and they will inherit from EntityData which is the class from Azure Mobile Service that represents the system properties and are useful for offline mode.

    To simplify the sample, we will map the dtos to the database.

    Other solutions could be, to have the Dtos mapped with the model. This article, Build a service using an existing SQL database with the Mobile Services .NET backend  , shows an example that has Dtos and a model, which are mapped to each other and the model is related with the database.

    The first class created is a base class for the Dtos that contains shared properties.

    Represents a base class for all Dtos and it inherits from EntityData.

    
    	public class DtoBase : EntityData
    	{
    		   public string Title { get; set; }
    		   public string Subtitle { get; set; }
    		   public string Image { get; set; }
    		   public string Description { get; set; }
    	}
    
    

    The BeveragesSchema class

     
        
    	public class BeveragesSchema : DtoBase   {   }
    	
    

    The DessertsSchema class

    
    	public class DessertsSchema : DtoBase   {   }
    	
    

    The MainSchema class

    
    	public class MainSchema :  DtoBase   {   }
    	
    

    The StartersSchema class

    
    	public class StartersSchema : DtoBase   {   }
    	
    

    The SpecialOffersSchema class

    This class inherits from EntityData and not from the DtoBase because it does not share all properties like the others objects.

    
    	public class SpecialOffersSchema : EntityData
    	{
    		public string Dessert1 { get; set; }
    		public string Main1 { get; set; }
    		public string Starter1 { get; set; }
    		public string Title { get; set; }
    		public string Subtitle { get; set; }
    	 }
      
    

    Class Diagram

    Here are the class diagrams

    Note: All Dtos must be created inside the DataObject folder because when we create the table controller this object will be searched for there.

    Services

    Each service will be an Azure Mobile Service Table Controller
    http://www.saramgsilva.pt/wp-content/uploads/2014/09/090914_1243_MicrosoftsW13.png

    Each service should be defined as the following
    http://www.saramgsilva.pt/wp-content/uploads/2014/09/090914_1243_MicrosoftsW14.png

    The BeveragesSchemaController

    Which the output will be something like

    
    public class BeveragesSchemaController : TableController
    {
        protected override void Initialize(HttpControllerContext controllerContext)
        {
            base.Initialize(controllerContext);
            MobileServiceContext context = new MobileServiceContext();
            DomainManager = new EntityDomainManager(context, Request, Services);
        }
     
        //GET tables/BeveragesSchema1
        public IQueryable GetAllBeveragesSchema()
        {
            return Query();
        }
           
        // GET tables/BeveragesSchema1/48D68C86-6EA6-4C25-AA33-223FC9A27959
        public SingleResult GetBeveragesSchema(string id)
        {
            return Lookup(id);
        }
           
        //PATCH tables/BeveragesSchema1/48D68C86-6EA6-4C25-AA33-223FC9A27959
        public Task PatchBeveragesSchema(string id, Delta patch)
        {
            return UpdateAsync(id, patch);
        }
           
        // POST tables/BeveragesSchema1/48D68C86-6EA6-4C25-AA33-223FC9A27959
        public async Task PostBeveragesSchema(BeveragesSchema item)
        {
            BeveragesSchema current = await InsertAsync(item);
            return CreatedAtRoute("Tables", new { id = current.Id }, current);
        }
     
        //DELETEtables/BeveragesSchema1/48D68C86-6EA6-4C25-AA33-223FC9A27959
        public Task DeleteBeveragesSchema(string id)
        {
            return DeleteAsync(id);
        }
      
        }
    }
    
    

    For the other services, the process is the same, only change the dto selected and the name of the controller. Note: The service will be inside the Controllers folder.

    Class diagram

    After creating all service, we will have

    Validate data
    Each service should validate the input data, to make sure that the following operation will not fail because the input is wrong. For example, suppose that the input object wasn´t sent in the right way, for this reason the serialization fails, it can be a request with n null input, that is not correct and it will throw an NullReferenceException in our service. Other case is when a required property is not filled and the service try to save or edit it and then it throw an DbEntityValidationException

    Here is the code for insert a BeverageSchema that validate data

    
    		public async Task PostBeveragesSchema(BeveragesSchema item)
            {
              if (item == null)
              {
                  throw new ArgumentNullException("item");
              }
     
              if (string.IsNullOrEmpty(item.Title)
                  || string.IsNullOrEmpty(item.Subtitle)
                  || string.IsNullOrEmpty(item.Image)
                  || string.IsNullOrEmpty(item.Description))
              {
     
                  return BadRequest("There are properties that are not defined.");
     
              }
     
              var current = await InsertAsync(item);
              return CreatedAtRoute("Tables", new { id = current.Id }, current);
     
          }
    
    

    The same validation can be done in the others dtos.

    The DomainManager

    Each service has an Initialize method where it defined the DomainManager as following
    DomainManager =new EntityDomainManager(context, Request, Services);
    This property is an IDomainManager and is used internally for all operations in the database, in this case it will be an EntityDomainManager of Beverages Schema.

    The EntityDomainManager<T>

    This class is an implementation of IDomainManager that contains the implementation for all operations required for the database, using the MobileServiceContext.

    The MobileServiceContext

    This class represents the DbContext Jump for the services that allow us to do the CRUD operation in the database the easy way. This class will be used by EntityDomainManager. The MobileServiceContext was changed because when each service was created. It was also automatically added the following DataSets

    
    	public DbSet BeveragesSchemas { get; set; }
    	 
    	public DbSet DessertsSchemas { get; set; } public DbSet MainSchemas { get; set; }
    	 
    	public DbSet SpecialOffersSchemas { get; set; }
    	 
    	public DbSet StartersSchemas { get; set; }
    
    

    With this, we are mapping the Dto to the database. To understand more about this concept, which is related with Entity Framework, see the documentation about it,DbContext Class Jump .

    The Database

    There are different ways to create the database, it can be created manually in SQL Server Management Studio  in Visual Studio or can be created using Code First  .

    This article will use Code First, that means we create the model first and then create the database based in the model structure.this process happens when we do a deploy. Like was mentioned earlier, our model is defined by the Dtos class.

    When the project was created, we removed some code that was ignored, and with it we deleted the code related with the Database Initializer, that uses the classDropCreateDatabaseIfModelChanges   it is an implementation of IDatabaseInitializer   that will DELETE, recreate, and optionally re-seed the database only if the model has changed since the database was created.

    If the model doesn’t change we can use it.

    Are we sure that the model will not change in future?

    Maybe this is not the best solution for create the database. For create the database and prevent future changes in model (in our case the dtos), we will use Entity Framework Migrations  .

    Note: There are others IDatabaseInitializer   that can be used, but the problem is same, data will lost if the model changes.

    Before we enable migration, we need to get the connection string to connect to the database and need to allow our IP to access the database.

    Defining the connection string

    The connection string must be defined in Web.config and can be a connection string from a local database, for local usage, or from the database created with the Azure Mobile Service.

    The connection string from MyMenuApp_db database can be find in the Portal  , by selecting the MyMenuApp Azure Mobile Service and then in Configure, as following

    And then scroll to

    In the project to go the Web.Config file and paste there the connection string

    Note: Later, in the deployment process, this value is overridden with the connection string defined in Azure Mobile Service.

    Defining the allowed IP for the database

    For localhost tests it is required to allow our IP to access to the database.we need to go to the Portal Jump , select the database MyMenuApp_db and then click in Dashboard, as following

    Scroll down until to find the following menu in the right

    And then allow the current IP

    Migration

    To have migration support we need to start with Enable-Migration. To do this, open the Tools menu in Visual Studio and then open the Package Manager Console

    Now, in the Package Manager Console enable migration and add migration as following

    The Migration folder was added to the project and it contains the configurations file and the migration V_0. This migration contains all information to create the database and the tables, it is used for revert the process if necessary.

    Seed

    In the Configuration file, it is possible to find the Seed method, that fills the database with some initial data or when there is any change in the model. it can be useful to update data in the database.

    In our case, we will use it to fill the database with the static data from the Menu App.

    Each data source in AppStudio.Data project, has the _data field that contains it. Here are the changed made

    Now we need to add the DbMigrator Jump  to the WebApiConfig.Register method, as following

    var migrator = newDbMigrator(newConfiguration());

    migrator.Update();

    s this that will create the database or will update the database following the current model.

    Be aware that the seed method is called each time this code runs!

    See more about it in this article How to make data model changes to a .NET backend mobile service  .

    Running the Services

    Now that the services are ready, we can run the services in localhost or in the server. For testing it could useful to use the localhost first.

    Localhost

    To run the services in localhost, press the key F5. The following page will be shown

    Click on “Try it out” to see the documentation page

    This documentation is generated automatically, it allows us to know what is available, and the type of requests and responses we can do. We can play a bit with this, by clicking on one option, let’s see one case

    Click on “try it out”, and the following window should appear

    This allows us to make a request to get all the special offers from the service. Attention, there are a limit of items we can get, the best practice is to request some items and will request more when they are needed (It is used for create pagination).Click in the “send” and we will get the following response

    This data is the data defined in Seed method.

    Server

    To deploy the services to the server, click on the project and open the context menu, then click on Publish as following

    The then select Microsoft Azure Mobile Services to associate the project to the MyMenuApp Azure Mobile Service.

    After it, click on the Publish button and then it is possible to follow the deployment in Web Publish Activity

    Our default browser will open a window with the service.

    If we click on “try it out”, it requires a key to access the documentation, that key is provided in the Portal  , by selecting the MyMenuApp Azure Mobile Service and then at the bottom has the option for it

    By clicking in the Manage Keys we will get

    How to see details about errors

    When we run the service, we get this windows

    That means there is a problem. To understand what happened we can use the Logs from the MyMenuApp for see the errors.

    Go to the Portal  , by selecting the MyMenuApp Azure Mobile Service and then click on Logs, as follows

    And then we get the list

    Select the error and click at the bottom on the “details” button, and we will see the error

    This error was made by adding an additional property in the model and wasn´t added the migration for update it in the database. See more about this subject in this articleTroubleshoot the Mobile Services .NET Backend Jump .

    How to do the remote debugging

    When we run the code in localhost we can debug Jump  the services, but in some cases it can be useful to debug the code that is running in the server, it is called remotedebugging. In the MyMenuApp Azure Mobile Service > Configure be sure you have this on

    Note: For how uses Visual Studio 2013 Update 2 or later it is turn on automatically In Visual Studio, open the View menu and the click in Server Explorer that will open the window as following

    Then expand the Mobile Service and select the MyMenuApp service and click in attach debugger

    The default browser will open the service and we shouldn´t close it until the debugging is done! Note: For it work we should deploy to the server using Debug Mode, in Release Mode it will not work. See more about it in Runtime Debugging Jump . Set the breakpoint and do the request, then the breakpoint will be hit

    Note: The services should be published as in debug mode.

    Code

    See the code created for AppStudion.Menu.Backend, here

    Step 4: Changes the BackEnd project: add the Dtos, add Services, changes the MobileServiceContext and add support for migrations. 

    Manage Images

    In Azure Mobile Service, is best practice is to use Azure Blob Storage   for saving the images used in the client apps. We only need to save, in the Azure SQL Database (MyMenuuApp_db), the image url.

    This article will not cover this topic. To see how to implement this feature see the following article Upload images to Azure Storage by using Mobile Services  . Which covers the topic for .Net Back End & Windows Store and .Net Back End & Windows Phone.

    How to consume the Azure Mobile Services in Menu App

    Now that we have the services running in the server, with the default data, is time to connect the Menu App with the MyMenuApp Azure Mobile services.

    There two ways to add the Azure Mobile Service Client: installing the Nuget Package or using Connected Service.

    Using Managed Nuget Pacakges

    Select the AppStudio.Data project, and then open the Manage Nuget Packages

    Install the Windows Azure Mobile Services Jump  nuget package like the following

    Is required to install this package in each target (Windows 8.1 and Windows Phone 8.1 apps).

    Using Connected Service

    Click in the target project, and with the mouse open the context menu, then click in “Add” and “Connect Service…”

    After it, login in using your Azure account and you will see your Azure Mobile Services as following

    By clicking in the MyMenuApp Azure Mobile Service we will add the Nuget package for Azure Mobile Service

    <package id="WindowsAzure.MobileServices" version="1.2.2" targetFramework="wpa81" />
    
    
    The MobileService<T>

    After it, create the MobileService<T> class in DataSource folder in the AppStudio.Data project, as following

    
    ///
    ///DefinestheMobileServicewrapper.
    ///
    ///ThetypeoftheDTO.
    publicsealedclassMobileService
    {
    	privatestaticMobileServiceClient_appStudioBackEnd;
    	  
    	///
    	///Getstheapplicationstudiobackend.
    	///
    	///Theapplicationstudiobackend.
    	privatestaticMobileServiceClientAppStudioBackEnd
    	{
    	get
    	{
    	return_appStudioBackEnd??(_appStudioBackEnd=newMobileServiceClient("",""));
    	}
    	}
    	  
    	///
    	///Initializesanewinstanceoftheclass.
    	///
    	publicMobileService()
    	{
    	Table=AppStudioBackEnd.GetTable();
    	}
    	  
    	///
    	///Getsorsetsthetable.
    	///
    	///
    	///Thetable.
    	///
    	publicIMobileServiceTableTable{get;set;}
    }
    
    
    Then for each data source do something like
    
    public async override Task> LoadDataAsync() 
    {
        var mobileService = new MobileService(); 
        return await mobileService.Table.ToListAsync(); 
    }
    
    
    After this, run the Menu App.

    Now the app has dynamic data that can be changed without changing the Menu App.

    How to create the Azure Mobile Service in Azure Portal

    Scope

    This article aims to show how to create an Azure Mobile Service in the portal and how to create the Visual Studio 2013 Project.

    This article complements the article

     Microsoft’s Windows App Studio Beta : Connecting a Menu App to Azure Mobile Service

    Creating the Azure Mobile Service

    Go to the Portal  , login and click on “+ New”, at the bottom

    Do the following steps

    The mobile service settings

    Then we will see the following screen that should be completed:

    Note: In this case we selected the free database with 20 MB, be sure that is enough. Each Azure account only can have one free database.

    The database settings

    In this screen, define all settings for the database

    At the end of this process we will have created the Azure Mobile Services and others related items.

    The MyMenuApp items created in Azure Account

    When the Azure Mobile Service is created, it will create in your account:

    • An Azure Mobile Service
    • The Notification Hub
    • The Database

    Here are the starting points for each.

    MyMenuApp Azure Mobile Service

    This is the start point for the Azure Mobile Service created.

    MyMenuAppHub-ns Notification Hub

    Each Azure Mobile Service automatically creates a Notification Hub.   This topic is outside the scope of this article.

    This is the start point for the Notification Hub related with Azure Mobile Service created.

    MyMenuuApp_db database

    This is the start point for the database related with the Azure Mobile Service created.

    By default this database is an Azure SQL Database, but the Azure Mobile Service supports MongoDb   database (NonSQL database), but this scenario is outside the scope of this article. For see more about this, see the following article

    Note: Azure SQL Database has differences from SQL Server Database, but in general the main features are supported.  

    How to create the Azure Mobile Service project for Visual Studio 2013

    There are two ways to have the Azure Mobile Service project:

    • Creating the project in Visual Studio, using Web or Could Template for Mobile Azure Service
    • Download the project from the Portal that is generated in MyMenuApp – Azure Mobile Service web page.

    Creating the project in Visual Studio

    Open the Visual Studio 2013, and create a new Web project, as seen below

    And then select the Azure Mobile Service template

    Here it is possible to define the project for “Host in the cloud”, but for now it will be ignored. Later the project will be associated with the MyMenuApp Azure Mobile Service.

    When the project is created it gives us some default classes for the To-do list sample, but it will be removed and ignored. More relative, in this article we will be creating similar classes for the Menu App.

    Here is the base project that we will use for the back end development

    At this moment, the project is completely empty, it only has

    • WebApiConfig – Defines some configuration for the WebApi
    • MobileServiceContext – Is the DbContext   for the services
    • Global.asax – This will called when the project is deployed
    • WebConfig – The configuration for the project will be in this file

    Code

    See the source code for the AppStudio.Menu.BackEnd, here

    Step 3: Add the base project for AppStudio.Menu.BackEnd. 

    Download the project from the Portal

    Go to the Portal Jump , and select the MyMenuApp mobile service

    And then click in “CREATE A NEW WINDOWS STORE APP” (could be other target), as following

    Because we have the default Menu App from App Studio  , it would be better to create the Azure Mobile Service using Visual Studio.

    Nuget Package​

    The Azure Mobile Service project, for .Net back end, by default is created using Entity Framework and the main Nuget package used in this kind of project is

    Microsoft Azure Mobile Services .NET Backend Entity Framework Extension 

    Note: If the project shows errors related with references it’s possible to remove this Nuget package and then install it again to restore references, in some cases it is required to close the project and open it again.