Ontem (9/2/2012) apresentei uma palestra na Campus Party 2012 e, ao final da palestra, mostrei uma série de recursos para aprendizado desta plataforma. Estou repetindo aqui, para que vocês possam verificar a quantidade disponível e aprender a desenvolver para Winddows Phone.

• Windows SDK and Tools – http://create.msdn.com – Ponto de partida do AppHub, onde você pode baixar gratuitamente todas as ferramentas para desenvolver para Windows Phone
• Windows Phone 7 Developer Portal – http://bit.ly/tIPZK3 – Portal de desenvolvimento do Windows Phone, com inúmeros recursos. Vale a pena começar com o Getting Started, onde há links para artigos, blogs e vídeos
• Windows Phone 7 Training Kit – http://bit.ly/uKo8Fg – Link para download do training kit, contendo programas, exercícios para iniciar o aprendizado na prática
• Livro Windows Phone 7 Development – Charles Petzold – http://charlespetzold.com/phone/index.html – Livro de 1000 páginas para download gratuito sobre desenvolvimento de Windows Phone
• Videos Windows Phone 7 JumpStart – http://bit.ly/wp7jumpstart – Curso em vídeo com quase 20 horas sobre desenvolvimento para Windows Phone
• Portal de Windows Phone da Microsoft em português – http://bit.ly/yxE8Po

Todos estes recursos são gratuitos, vocês não tem desculpas para não começar a aprender já!

Um dos benefícios indiretos de ser um MVP é que muitos produtores de ferramentas ou componentes cedem cópias de seus produtos para os MVPs para uso pessoal, para que possam usar, avaliar e, eventualmente, recomendar.

Eu uso muitas dessas ferramentas no meu dia a dia, e gosto muito delas. Assim, nada mais justo que fazer um post sobre elas e como elas ajudam meu dia-a-dia.

Sem dúvida, a ferramenta que eu mais uso é o ReSharper (http://www.jetbrains.com/resharper/), um add-in para o Visual Studio para aumentar sua produtividade. Ao usar o Visual Studio, ela está sempre lá, ativa, me ajudando a escrever o código.

Análise de código

Ao abrir um projeto, o ReSharper analisa seu código e começa a dar sugestões para melhorá-lo. Abrindo um projeto console, já vemos o seguinte no editor:

Do lado direito, é adicionada uma barra com as indicações de ajuda para seu código. O quadrado amarelo mostra que há avisos para melhoria de código. Se houver erros de compilação, o quadrado fica vermelho e, se seu código estiver ok, o quadrado fica verde. Abaixo do quadrado, estão linhas com os pontos onde há problemas. Se você passar o mouse sobre estas barras, uma tooltip irá mostrar o problema.

Para corrigir o erro, é muito fácil. É só clicar na barra e o editor é posicionado no local do erro. Uma lâmpada vermelha indica o erro e podemos clicar nela para ver as ações disponíveis. Esta lista pode ser selecionada com Alt-Enter. Aliás, se eu tivesse a possibilidade de escolher um único atalho de teclado para lembrar, seria este. Com o ReSharper e o Alt-Enter o seu código irá melhorar bastante!

Selecionamos a ação desejada e o ReSharper corrige o código (no caso, eliminando as cláusulas using desnecessárias). Para o erro seguinte, podemos ver que o parâmetro args de Main está ém cinza. Isto quer dizer que ele não está sendo usado na função. Quando colocamos o mouse em args aparece uma pirâmide, mostrando que há um refactoring a ser feito.

Aqui ele irá remover o parâmetro não usado. Além desta mudança, ele irá verificar todos os lugares onde a função é chamada e mudar a chamada a ela. Isto é ótimo quando colocamos um parâmetro e verificamos que ele não é mais necessário e queremos retirá-lo. Se fizermos isso, o código irá quebrar em todos os lugares onde a funçao é chamada. Com este refactoring, as chamadas são alteradas automaticamente. Fazendo esta mudança, nosso código fica ok, como mostra a figura abaixo.

O ReSharper está constantemente analisando nosso código e verifica a consistência na nomenclatura de variáveis e métodos. Você pode dizer como gosta de nomear os campos, propriedades e métodos e ele irá verificar a consistência para você.

Por exemplo, eu gosto de nomear meus campos privados usando CamelCase, iniciados com minúscula (sem um sublinhado antes). Assim, se eu colocar um campo com nomenclatura diferente, o ReSharper irá me avisar e se prontificar para alterar. Nada que um Alt-Enter não resolva. E ele irá mudar todas as referências para essa variável.

Melhoria do código

Além da consistência de nomes, ele ainda verifica a qualidade do seu código. Sim, eu sei que seu código (como o meu) é impecável, mas será que dá para melhorar? Veja na figura abaixo, uma aplicação WPF onde implementei o manipulador do evento Click do botão em codigo, com button1.Click += <tab><tab>.

O ReSharper mostra dois avisos e um lembrete. O primeiro aviso é sobre MainWindow. Ele indica que o tipo pai (Window) já foi declarado em outro lugar desta classe parcial e é desnecessário. Devemos lembrar que quando criamos uma janela WPF estamos criando uma classe parcial, declarada em dois lugares: no XAML e no arquivo de code behind. O XAML já declara que MainWindow é derivado de Window e podemos tirar esta declaração redundante do code behind. O segundo aviso é devido ao fato que podemos eliminar a criação do delegate ao adicionar o manipulador. O lembrete é para indicar que temos uma exceção de “não implementado”, indicação clara que devemos colocar código ali. Dois Alt-Enter e nosso código fica assim:

O ReSharper analisa seu código, verificando possíveis erros e melhorias. Ao digitar este código

Vemos na barra lateral um aviso e uma possível melhoria. O aviso indica que ToString é redundante e que devemos especificar uma cultura para a conversão. O fato de ser redundante faz com que ele possa ser eliminado. Alt-Enter e lá se vai ele. A melhoria está no for, indicando que pode ser convertido para uma expressão LINQ. Ao teclar Alt-Enter mais uma vez ficamos com o código assim:

Outras melhorias de código muito comuns são otimização de if e de return: quando colocamos um código como

if (x == 3)
  y = 2;
else
  y = 5;

o ReSharper otimiza para:

y = x == 3 ? 2 : 5;

Ou então este código:

if (x == 3)
  return 2;
else
  return 5;

Aqui teríamos duas otimizações: eliminar o else

if (x == 3)
  return 2;
return 5;

ou então usar o operador ternário:

return x == 3 ? 2 : 5;

Refactoring

Mas isto não é tudo o que o ReSharper pode fazer por você. Seus recursos de refactoring e criação de código são fantásticos. Queremos extrair o código do manipulador de eventos para um novo método. Podemos teclar Ctrl-Shift-R (Refactor this) e o ReSharper irá mostrar os refactorings disponíveis.

Selecionamos o refactoring de extração de métodos e a seguinte tela é mostrada:

Podemos indicar os parâmetros, o nome da função e seu tipo de retorno. Ao clicar em Next, obtemos algo como

Criação de código

Podemos ainda inserir código a partir de templates. O ReSharper permite criar templates com código para novos arquivos ou snippets de texto.

Temos três tipos de templates:

• Live templates – templates de snippets de código, inseridos como snippets normais do Visual Studio. Para acionar, teclamos o snippet e <tab> para inserir. Outra maneira de acionar estes templates é usando Ctrl-E-L. Na figura, criei o snippet propnp, que cria uma propriedade com backing field e chama o manipulador de PropertyChanged
• Surround templates, que permitem envolver o código selecionado com um template, por exemplo, para envolver o código com try…catch. Eles são acionados com Ctrl-E-U.
• File templates – que criam novos arquivos no nosso projeto, como classes, interfaces. Eles são acionados com Ctrl-Alt-Ins.

Vamos criar uma nova classe em nosso projeto. Teclamos Ctrl-Alt-Ins e criamos uma nova classe. Chamamos de NewClass. Teclamos Alt-Ins e inserimos o construtor para a classe. Nos parâmetros do construtor colocamos uma dependência:

Note que IDependency está em vermelho, pois não está definida. Teclamos Alt-Enter e as opções mostradas são as seguintes

Note que ele verificou que colocamos o nome do tipo iniciado com I, indicando uma interface e sugere a criação desta. Podemos então criar a interface a partir daqui. Após criar a interface, teclamos Alt-Enter novamente em IDependency e podemos declarar o campo para guardar a dependência:

A nossa interface foi criada no mesmo arquivo da classe. Podemos ir para sua declaração e teclar Alt-Enter. O ReSharper oferece para movê-la para um arquivo separado. É criado um arquivo IDependency.cs com a interface. Como vocês podem ver, é muito fácil criar e refatorar o código com o ReSharper. Ele facilita também a declaração de variáveis. Por exemplo, ao incluirmos o código

total = -1;

no construtor, vemos que total está em vermelho. Teclando Alt-Enter, temos as seguintes opções:

Podemos então criar um campo total no nosso código. Como vimos, temos diversas maneiras de mudar e melhorar nosso código.

Auxílio no XAML

Mas isso não é tudo. Podemos usar o ReSharper também no XAML, o que facilita bastante. Por exemplo, se criamos um Converter no código:

public class DebugConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        return value;
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        return value;
    }
}

Quando queremos usá-lo no XAML devemos seguir uma série de passos: namespace, declaração nos recursos, etc. Para isso, temos algumas facilidades.

Teclamos Alt-Enter em DebugConverter e selecionamos Create resource in type element <Window>. Ele cria a seção Resources e cria o recurso. Colocamos o nome DebugConverter. Não colocamos o namespace. Aparece uma tooltip indicando o namespace

Teclamos Alt-Enter e o namespace é declarado e colocado no elemento. Se não gostarmos do nome do namespace, podemos renomeá-lo com Ctrl-R-R. Pronto, a declaração do converter, o namespace, tudo está pronto, como necessário. Se tivermos um DataContext associado ao componente e ele não tiver uma propriedade chamada Valor, podemos usar o ReSharper para criar esta propriedade na classe do DataContext.

Navegação no código

O ReSharper possui atalhos para navegação no código, que facilitam muito. Por exemplo, Ctrl-T navega para um tipo. Abre-se uma tela como a seguinte

Digitamos parte do nome e ele mostra os símbolos definidos que casam com a pesquisa. Da mesma maneira, podemos usar Shift-Alt-T para ir para um símbolo ou Ctrl-Shift-T para ir a um arquivo. A pesquisa é feita em todos os arquivos da solução. A navegação entre os membros de uma classe pode ser feita com Alt-`. Você pode ir ao membro anterior ou posterior com Alt-Up ou Alt-Down. Se você quiser, pode até navegar em código .NET descompilado. O ReSharper tem um descompilador que descompila o código e permite navegar até ele.

Utilidades diversas

Mas isto não é tudo o que o ReSharper oferece. Você tem um unit test runner, onde pode rodar os seus testes unitários. Você pode estar pensando quo o Visual Studio já tem um test runner, mas o que o VS oferece é exclusivo para testes com MSTest. O runner do ReSharper funciona com outros frameworks de teste, como o NUnit, QUnit ou xUnit. Uma outra funcionalidade interessante é o Explore Stack Trace. Você tem o stack trace de uma exceção, obtido através de uma ferramenta de log qualquer. Basta copiar o stack trace para a área de transferência e, no Visual Studio, usar Ctrl-E-T. O stack trace é mostrado com links para o seu código, e você pode assim verificar onde ocorreu a exceção.

Conclusão

Esta é só parte da funcionalidade oferecida pelo ReSharper, há muito mais para explorar, mas isto eu deixo para vocês. A ferramenta é paga, mas você pode baixar uma versão de avaliação por 30 dias, em http://www.jetbrains.com/resharper/download/index.html.

Em conclusão, eu acho que esta é uma ferramenta indispensável para quem desenvolve com o Visual Studio, e só tenho um ponto contrário: ela é realmente viciante, e uma vez que você se acostuma a usar o Resharper, é muito difícil voltar a desenvolver sem ele

No post anterior mostramos os behaviors em Blend e apresentamos os dois tipos de behaviors: Actions e Behaviors.

Ali, mostramos como criar uma Action, que atua sobre um elemento Target, fazendo uma ação sobre ele. Neste post, iremos mostrar os Behaviors e como podemos criar um behavior para ser usado (e reutilizado) no Blend.

Um behavior atua sobre um elemento associado e executa uma determinada ação, que não precisa ser sobre outro elemento, pode ser inclusive sobre ele mesmo. Aqui iremos mostrar como criar um behavior para movimentar elementos de uma listbox arrastando e soltando-os na nova posição.

Antes de iniciar o desenvolvimento do behavior, devemos saber como fazer o Drag & Drop em WPF. Para que um componente possa suportar Drag & Drop, devemos configurar sua propriedade AllowDrop para True. Em seguida, devemos manipular dois eventos: DragOver, que é ativado quando algo está sendo arrastado sobre o elemento e Drop, quando algo é solto sobre o elemento.

No evento DragOver devemos dizer qual é o cursor que deve ser apresentado quando há algo sendo arrastado sobre o elemento. Usamos o segundo parâmetro do manipulador de eventos, do tipo DragEventArgs, configurando a propriedade Effects com um código semelhante a este:

void ListboxDragOver(object sender, DragEventArgs e)
{
  e.Effects = DragDropEffects.Move;
}

Este código faz que o cursor de movimentação seja mostrado. No evento Drop devemos concluir a ação.

Com esta pequena introdução, podemos criar nosso behavior. Desta vez, iremos iniciar nosso projeto no Blend. Crie um novo projeto WPF, do tipo WPF Application

Em seguida, vá para o menu Project e selecione Add New Item, escolhendo a opção Behavior. Dê o nome de DragListItemBehavior

O Blend cria um código semelhante ao seguinte:

using System;
using System.Collections.Generic;
using System.Text;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Shapes;
using System.Windows.Interactivity;
//using Microsoft.Expression.Interactivity.Core;

namespace WpfApplication5
{
  public class DragListItemBehavior : Behavior<DependencyObject>
  {
    public DragListItemBehavior()
    {
      // Insert code required on object creation below this point.

      //
      // The line of code below sets up the relationship between the command and the function
      // to call. Uncomment the below line and add a reference to Microsoft.Expression.Interactions
      // if you choose to use the commented out version of MyFunction and MyCommand instead of
      // creating your own implementation.
      //
      // The documentation will provide you with an example of a simple command implementation
      // you can use instead of using ActionCommand and referencing the Interactions assembly.
      //
      //this.MyCommand = new ActionCommand(this.MyFunction);
    }

    protected override void OnAttached()
    {
      base.OnAttached();

      // Insert code that you would want run when the Behavior is attached to an object.
    }

    protected override void OnDetaching()
    {
      base.OnDetaching();

      // Insert code that you would want run when the Behavior is removed from an object.
    }

    /*
    public ICommand MyCommand
    {
      get;
      private set;
    }
     
    private void MyFunction()
    {
      // Insert code that defines what the behavior will do when invoked.
    }
    */
  }
}

Devemos sobrescrever dois métodos, OnAttached e OnDetaching. No método OnAttached iremos fazer o processo de inicialização do nosso behavior: conectar manipuladores, configurar propriedades, etc. No método OnDetaching fazemos a limpeza do processo.

Agora que já temos nosso projeto criado, podemos editar seu código no Visual Studio. No painel Projects, clique com o botão direito do mouse sobre a solução e selecione Edit in Visual Studio. O projeto é aberto no Visual Studio.

Abra o arquivo do behavior para editá-lo. Queremos que o behavior só atue sobre ListBoxes. Para isto iremos alterar seu tipo:

public class DragListItemBehavior : Behavior<ListBox>

Em seguida, devemos colocar, no método OnAttached, o código de inicialização, onde iremos configurar as propriedades e conectar os manipuladores:

protected override void OnAttached()
{
  base.OnAttached();

    AssociatedObject.AllowDrop = true;
    AssociatedObject.PreviewMouseLeftButtonDown += ListboxPreviewMouseLeftButtonDown;
    AssociatedObject.DragOver += ListboxDragOver;
    AssociatedObject.Drop += ListboxDrop;
}

Note que conectamos os eventos DragOver e Drop, mas também usamos o evento PreviewMouseLeftButtonDown. Isto é necessário por que iremos iniciar a ação de Drag & Drop quando o usuário clica num item da Listbox. O behavior tem uma propriedade AssociatedObject, que é o objeto associado ao behavior. Como definimos que esse é um Behavior<ListBox>, o AssociatedObject é uma Listbox.

No método OnDetaching iremos fazer a limpeza:

protected override void OnDetaching()
{
  base.OnDetaching();

    AssociatedObject.PreviewMouseLeftButtonDown -= ListboxPreviewMouseLeftButtonDown;
    AssociatedObject.DragOver -= ListboxDragOver;
    AssociatedObject.Drop -= ListboxDrop;
}

Podemos então criar o código para fazer o Drag & Drop nos manipuladores dos eventos. No evento PreviewMouseLeftButtonDown obtemos o item que foi clicado e iniciamos o processo de Drag & Drop:

private object dragItem;

private void ListboxPreviewMouseLeftButtonDown(object sender, MouseButtonEventArgs e)
{
    var parent = (ListBox)sender;
    dragItem = GetDataFromListBox(parent, e.GetPosition(parent));

    if (dragItem != null)
        DragDrop.DoDragDrop(parent, dragItem, DragDropEffects.Move);
}

O método GetDataFromListBox procura na árvore de elementos e retorna o item que foi clicado:

private object GetDataFromListBox(ListBox source, Point point)
{
    var element = source.InputHitTest(point) as UIElement;
    if (element == null) return null;
    object data = DependencyProperty.UnsetValue;
    while (data == DependencyProperty.UnsetValue)
    {
        data = source.ItemContainerGenerator.ItemFromContainer(element);
        if (data == DependencyProperty.UnsetValue)
            element = VisualTreeHelper.GetParent(element) as UIElement;
        if (element == source)
            return null;
    }
    return data != DependencyProperty.UnsetValue ? data : null;
}

No evento DragOver iremos configurar o cursor. Se o Drag & Drop é da própria Listbox, deixamos arrastar, senão configuramos o cursor para None:

private void ListboxDragOver(object sender, DragEventArgs e)
{
    e.Effects = e.Source == sender ? DragDropEffects.Move : DragDropEffects.None;
}

Finalmente, no evento Drop fazemos a movimentação do item arrastado:

private void ListboxDrop(object sender, DragEventArgs e)
{
    var parent = (ListBox)sender;
    var dropItem = GetDataFromListBox(parent, e.GetPosition(parent));
    var dragItemIndex = parent.Items.IndexOf(dragItem);
    var dropItemIndex = dropItem == null ? parent.Items.Count - 1 : parent.Items.IndexOf(dropItem);
    if (dragItemIndex != dropItemIndex)
    {
        parent.Items.RemoveAt(dragItemIndex);
        parent.Items.Insert(dropItemIndex, dragItem);
    }
}

Verificamos onde o item arrastado foi solto e, se for numa posição diferente da atual, movemos o item para uma nova posição. Nosso behavior está pronto. Compile o projeto e abra o Blend para recarregá-lo. Nosso behavior está lá e pode ser usado.

Coloque uma Listbox na janela e coloque alguns itens nela. Arraste um DragListItemBehavior para a Listbox. Execute o programa. Você pode ver que podemos arrastar os itens da Listbox para movê-los de lugar. Este behavior é reutilizável e pode ser usado em qualquer Listbox, mesmo por aqueles que não tem conhecimento de C#. Como você pode ver, um behavior pode modificar o comportamento de outros componentes, estendendo-os e trazendo novos comportamentos, sem que seja necessário criar um controle derivado.

No último post mostramos como animar transições usando o Blend e Visual States. Uma parte importante naquele mecanismo é o uso de behaviors. Com behaviors, podemos executar ações bastante complexas, apenas arrastando um behavior para um componente da janela. Isto, além de poderoso, traz outros benefícios:

• É reutilizável. Podemos incluir o mesmo behavior em diversas situações
• Permite que os designers possam incluir funcionalidade no design sem necessidade de código

Temos dois tipos de behaviors:

• Actions – executam uma ação associado a um evento. Por exemplo, você pode criar uma Action que, associada a uma TextBox, emite um “click” a cada tecla pressionada, ou outra action que faz um controle crescer quando o mouse está sobre ele
• Full behaviors – neste caso, há um comportamento mais complexo, não necessariamente associado a um único trigger. Um exemplo disso é o MouseDragElementBehavior, que permite movimentar um elemento, arrastando-o com o mouse

No Blend, encontramos os dois tipos de behaviors, com o final do nome indicando o tipo (ex. CallMethodAction ou FluidMoveBehavior).

Além dos pré-instalados, você pode encontrar outros behaviors, na galeria do Blend, em http://gallery.expression.microsoft.com (quando verifiquei, existiam 114 behaviors disponíveis lá).

Os behaviors estão associados a um objeto e podem ter propriedades adicionais, além do trigger que os ativa. Por exemplo, o GoToStateAction tem como propriedades adicionais o componente destino e o estado a ser ativado, além da propriedade booleana UseTransitions, para usar as transições para mudar de um estado a outro.

Além de configurar as propriedades da Action, você pode especificar condições para que ela possa ser ativada. Por exemplo, usando o projeto do post anterior, podemos usar uma checkbox para permitir a ativação da transição. Para isso, basta clicar no botão “+” de Condition List, clicar no botão de propriedades avançadas da condição, criar um Data Binding com a checkbox e fazer um binding com a propriedade IsChecked. Desta maneira, a animação só será ativada se a checkbox estiver checada.

Além das Actions padrão, podemos criar Actions personalizadas para fazer o que queremos. No post anterior, usamos as Actions padrão, mas precisamos criar os Visual States. Além disso, temos um outro inconveniente: se quisermos fazer as animações para cima ou para baixo, temos que criar novos Visual States. Assim, criaremos nossa Action para fazer o que queremos, sem a necessidade de configuração especial.

No Visual Studio, crie um novo projeto WPF. Vamos adicionar agora a nossa Action. O Visual Studio, por padrão, não tem o template para criar uma Action. Poderíamos fazer isso usando o Blend. Ao abrir o projeto no Blend e selecionar a aba Project, você pode dar um clique com o botão direito do mouse, selecionar Add New Item e adicionar uma Action ao projeto.

Outra maneira de fazer isso é usar os templates online do Visual Studio. No Solution Explorer do Visual Studio, clique com o botão direito do mouse no projeto e selecione Add New Item. Na tela, vá para Online Templates e tecle action na caixa de pesquisa. Selecione o template C# Action Template for WPF e dê o nome de TransitionControlAction.

O template adiciona uma referência a System.Windows.Interactivity e gera uma classe semelhante a este código:

using System;
using System.Collections.Generic;
using System.Text;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Shapes;
using System.Windows.Interactivity;

namespace WpfApplication4
{
    //
    // If you want your Action to target elements other than its parent, extend your class
    // from TargetedTriggerAction instead of from TriggerAction
    //
    public class TransitionControlAction : TriggerAction<DependencyObject>
    {
        public TransitionControlAction()
        {
            // Insert code required on object creation below this point.
        }

        protected override void Invoke(object o)
        {
            // Insert code that defines what the Action will do when triggered/invoked.
        }
    }
}

Temos dois tipos de actions: TriggerAction e TargetedTriggerAction. TriggerAction é uma action que não se refere a outro controle. Por exemplo, se quisermos criar uma action que executa o Notepad quando acontece um evento, usaríamos uma TriggerAction. TargetedTriggerAction refere-se a um outro elemento, chamado de Target. Este elemento é uma propriedade da action e pode ser acessado no Blend.

Nós iremos criar uma TargetedTriggerAction. Portanto devemos mudar o código para derivar de TargetedTriggerAction, como mostra o comentário no início da classe. Esta action irá executar o mesmo código que criamos no primeiro post para fazer a animação. Devemos alterar também o tipo de objeto em que ela atua. Usaremos o FrameworkElement, pois este elemento tem as propriedades ActualWidth e ActualHeight.

public class TransitionControlAction : TargetedTriggerAction<FrameworkElement>

Inicialmente, iremos criar a enumeração para as posições e duas DependencyProperties com o tipo de animação desejada e a duração, de modo que ela possa ser selecionada no Blend.

public enum TipoAnimacao
{
    Direita,
    Esquerda,
    Cima,
    Baixo
}

[Category("Common Properties")]
public TipoAnimacao Tipo
{
    get { return (TipoAnimacao)GetValue(TipoProperty); }
    set { SetValue(TipoProperty, value); }
}

public static readonly DependencyProperty TipoProperty =
    DependencyProperty.Register("Tipo", typeof(TipoAnimacao), typeof(TransitionControlAction));


[Category("Common Properties")]
public TimeSpan Duracao
{
    get { return (TimeSpan)GetValue(DuracaoProperty); }
    set { SetValue(DuracaoProperty, value); }
}

public static readonly DependencyProperty DuracaoProperty =
    DependencyProperty.Register("Duracao", typeof(TimeSpan), typeof(TransitionControlAction), 
    new UIPropertyMetadata(TimeSpan.FromMilliseconds(500)));

Note que colocamos o atributo Category nas propriedades Tipo e Duração para que elas apareçam junto com o grupo Common Properties. Ao compilarmos o projeto e abri-lo no Blend, vemos que nossa action aparece na aba Assets.

Ao arrastarmos uma TransitionControlAction para um botão, as propriedades aparecem no editor de propriedades:

Mas nossa action ainda não faz nada. Para fazer algo, devemos sobrescrever o método Invoke da action, colocando ali o código que deve ser executado. Usaremos o código que escrevemos na primeira postagem, modificando um pouco para usar o controle Target:

private void AnimaControle(FrameworkElement controle, TimeSpan duração, TipoAnimacao tipo)
{
    double xFinal = 0;
    double yFinal = 0;
    if (tipo == TipoAnimacao.Esquerda)
        xFinal = -controle.ActualWidth;
    else if (tipo == TipoAnimacao.Direita)
        xFinal = controle.ActualWidth;
    else if (tipo == TipoAnimacao.Cima)
        yFinal = -controle.ActualHeight;
    else if (tipo == TipoAnimacao.Baixo)
        yFinal = controle.ActualHeight;
    // cria a transformação e atribui ao controle
    var translate = new TranslateTransform(0, 0);
    controle.RenderTransform = translate;
    // cria a animação e anima-a
    if (tipo == TipoAnimacao.Esquerda || tipo == TipoAnimacao.Direita)
    {
        var da = new DoubleAnimation(0, xFinal, new Duration(duração));
        translate.BeginAnimation(TranslateTransform.XProperty, da);
    }
    else
    {
        var da = new DoubleAnimation(0, yFinal, new Duration(duração));
        translate.BeginAnimation(TranslateTransform.YProperty, da);
    }
}

Finalmente, basta chamar o método AnimaControle a partir do método Invoke:

protected override void Invoke(object o)
{
    AnimaControle(Target, Duracao, Tipo);
}

Com isto, nosso behavior está completo. Podemos abrir o projeto no Blend, arrastar a action para o botão, configurar o objeto Target apontando para a grid e executar o projeto. Ao clicar o botão, a grid faz uma transição animada para a direção selecionada. Note que não precisamos fazer nada. Basta arrastar a action para o botão, configurar o elemento Target e as propriedades. A action está pronta para ser executada.

Conclusão

Foi um longo trajeto até aqui. Vimos quatro maneiras diferentes de animar a transição, começamos com código e terminamos usando o mesmo código. No meio do caminho vimos diversos conceitos: partir de um código fixo para um código mais refatorado e flexível, usar componentes para transição, eliminar o code behind usando MVVM, usando o Nuget, Templates Implícitos, usar Visual States para criar animações sem usar código e, finalmente, behaviors, para criar ações que podem ser usadas por designers, de maneira flexível e sem usar código. Espero que tenham gostado!

Nos dois últimos posts, mostrei como animar uma transição usando código. O primeiro post mostrou como animar a transição usando code behind, criando uma animação em código. O segundo post mostrou o uso de componentes para facilitar estas transições. Embora o uso de componentes seja uma boa alternativa a criar as animações em código, ainda tem algumas desvantagens:

• É necessário incluir uma referência à dll do componente ou incluir o código do componente no projeto.
• Está sujeito a bugs – embora muitas pessoas usem estes componentes nada impede que eles tenham bugs. O fato de serem open source e terem seu código disponível pode minimizar isto, mas nem sempre é fácil debugar este código.
• Pode ficar defasado. Com novas versões do Silverlight e WPF, um componente que não é mantido há muito tempo pode não funcionar nas novas versões

Assim, vamos ver aqui uma nova opção para animar as transições, que não usam código. “Como assim, não usam código?”, você deve estar se perguntando. Sim, o WPF 4 (ou o 3.5, com o WPF Toolkit) e o Silverlight introduziram um novo recurso, que dispensa o uso de código em C# ou VB para animar as transições: os Visual States. Com Visual States, você define qual é o estado de seu controle em diversas situações e transiciona entre eles sem usar código. Tudo é feito com o XAML.

Para este projeto, não usaremos o VisualStudio. A criação de Visual States é muito mais fácil usando o Blend.

Abra o Blend e crie um novo projeto WPF.

Neste projeto, inclua uma linha na Grid principal, na parte de baixo da janela, com 40 pixels de altura e, na segunda linha, coloque um botão com a propriedade Content configurada para o texto Esconde. Na primeira linha da grid, coloque outra grid, com fundo vermelho.

No painel do projeto, escolha a aba States. Ela deve estar vazia.

Clique no primeiro botão da barra superior da aba para adicionar um novo grupo de estados. Mude o nome do grupo para EstadosGrid. Clique no segundo botão deste grupo para adicionar um novo estado. Mude seu nome para Aparente. Adicione um novo estado e mude o nome dele para Escondido.

Note que o tempo padrão de transição (mostrado na frente do texto Default Transition) é de 0s

Mude este tempo para 1. Mude também o Easing Function para CubicInOut, clicando no segundo botão

Olhando a figura acima, você pode notar que estamos em modo de gravação, “gravando” o estado Escondido. Quando selecionamos um estado, todas as alterações que fazemos no layout são atribuídos a este estado. Assim, podemos mudar a aparência de nossos controles apenas mudando de um estado para outro. O estado Aparente é o nosso estado padrão. No estado Escondido iremos esconder a grid. A transição é feita automaticamente quando mudarmos de um estado para outro.

Selecione a grid e mude a propriedade RenderTransform X para –625, a propriedade Opacity para 0 e a propriedade Visibility para Collapsed. Desta maneira, a grid irá para a esquerda, ao mesmo tempo que fica cada vez mais transparente. Nossos estados estão prontos. Poderíamos mudar de estado usando o code behind, colocando o seguinte código no event Click do botão:

private void button_Click(object sender, System.Windows.RoutedEventArgs e)
{
  VisualStateManager.GoToElementState(LayoutRoot, "Escondido", true);
}

Mas assim estaríamos na mesma situação do post anterior, onde temos code behind. Além disso, eu prometi que não iríamos colocar código. E promessa é dívida!

O Blend tem um recurso muito interessante para executar ações sem a necessidade de código: Behaviors. Behaviors são ações personalizadas, usadas diretamente nos componentes, sem que seja preciso escrever código para executá-las (na realidade, você precisa escrever código para escrever um behavior mas, uma vez criado, basta arrastá-lo para um componente para ser usado). O Blend venm com diversos behaviors pré definidos. Para usá-los, basta ir na janela do projeto, na aba Assets e selecionar a opção Behaviors.

Usaremos o behavior GoToStateAction. Atribuímos este behavior a um componente, dizemos qual é o evento que o ativa e qual é o novo estado que se deve ativar quando o evento foi acionado. Selecione o GoToStateAction e arraste-o para o botão. Note que um GoToStateAction é adicionado ao botão, no inspetor de objetos.

No editor de propriedades, iremos configurar a ação.

O Trigger já está configurado: queremos ativar a action quando o evento Click do botão foi acionado. Falta apenas configurar o estado que queremos selecionar quando o botão for clicado. Para isto, basta configurar a propriedade StateName para Escondido.

Nossa aplicação está pronta. Ao executá-la e clicar no botão, ocorre a transição animada, que movimenta a grid para fora. E tudo isso sem uma única linha de código!

Vamos fazer agora uma pequena mudança para dar um pouco mais de funcionalidade à nossa aplicação. Mude a visualização do editor para Split, clicando no terceiro botão de mudança de visualização.

Com isso, podemos alterar o código XAML diretamente e alterar o nosso botão. Queremos que ele não seja um botão normal, e sim um ToggleButton. Para isso, altere o componente no XAML, mudando o seu tipo de Button para ToggleButton:

<ToggleButton x:Name="button" Content="Esconde" Grid.Row="1" HorizontalAlignment="Center" 
    VerticalAlignment="Center" Width="65" Height="25">
  <i:Interaction.Triggers>
    <i:EventTrigger EventName="Click">
      <ei:GoToStateAction StateName="Escondido"/>
    </i:EventTrigger>
  </i:Interaction.Triggers>
</ToggleButton>

O ToggleButton pode estar checado ou não. Faremos que quando ele está checado, mostre o estado Escondido e, quando não está checado, mostre o estado Aparente.

Para isso, devemos mudar o evento que ativa o estado Escondido. No inspetor de objetos, selecione o GoToStateAction e mude a propriedade EventName para Checked. Na paleta do projeto, selecione o GoToStateAction e arraste um segundo GoToStateAction para o botão. Configure a propriedade EventName para Unchecked e a propriedade StateName para Aparente. Execute o programa.

Agora temos uma animação para esconder a grid quando o botão é checado e outra para mostrar a grid, quando o botão não está checado. Fácil, não?

Aqui pudemos ver a quantidade de recursos que temos à disposição para criar estados e ativá-los, tudo feito visualmente, sem precisar escrever código. Ainda não terminamos nossa jornada, ainda temos maneiras de animar transições, mas isto é assunto para um outro post. Até lá!

No post anterior vimos como animar uma transição usando código. Como falei, não acho aquela a melhor solução, pois obriga a usar code behind, o que não é de fácil manutenção. Poderíámos refatorar o código, criando uma classe para a animação e usá-la. Isto traria um pouco mais de separação, mas ainda teríamos de usar code behind.

Nesta segunda parte, usaremos um enfoque diferente: o uso de componentes prontos. Podemos usar diversos componentes, como o Kevin Bag-O-Tricks (https://github.com/thinkpixellab/bot), FluidKit (http://fluidkit.com), Silverlight Toolkit (http://silverlight.codeplex.com – só para Silverlight), o Transitionals (http://transitionals.codeplex.com).

Usaremos aqui o Transitionals, para WPF. Se quisermos fazer animações em Silverlight, devemos escolher outro dos componentes acima.

Seu uso é muito simples: após baixar o componente e adicionar uma referência ao projeto para a dll Transitionals.dll, devemos adicionar um componente TransitionElement no local onde queremos a animação, configurar a animação e colocar um conteúdo para o componente. Ao mudar o conteúdo, ocorre a transição selecionada.

Vamos então fazer o nosso projeto de animação. Crie um novo projeto WPF e adicione uma referência a Transitionals.dll. Em seguida, coloque um TransitionElement na grid principal:

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="*" />
        <RowDefinition Height="40" />
    </Grid.RowDefinitions>
    <transc:TransitionElement x:Name="TransitionBox">
        <transc:TransitionElement.Transition>
            <transt:TranslateTransition  StartPoint="1,0" EndPoint="0,0" Duration="0:0:1"/>
        </transc:TransitionElement.Transition>
       
    </transc:TransitionElement>
    <Button Width="65" Grid.Row="1" Content="Esconde" Margin="5" Click="Button_Click" />
</Grid>

Devemos definir os namespaces para o TransitionElement e para a TranslateTransition na definição da janela:

<Window x:Class="WpfApplication2.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:transc="clr-namespace:Transitionals.Controls;assembly=Transitionals"
        xmlns:transt="clr-namespace:Transitionals.Transitions;assembly=Transitionals"
        Title="MainWindow" Height="350" Width="525">

Em seguida, é só colocar um conteúdo no TransitionElement:

<transc:TransitionElement x:Name="TransitionBox">
    <transc:TransitionElement.Transition>
        <transt:TranslateTransition  StartPoint="1,0" EndPoint="0,0" Duration="0:0:1"/>
    </transc:TransitionElement.Transition>
    <Grid Background="Red" />
</transc:TransitionElement>

O código do botão muda o conteúdo do TrasitionElement e, com isso ativa a transição:

private void Button_Click(object sender, RoutedEventArgs e)
{
    TransitionBox.Content = new Grid() {Background = Brushes.Blue};
}

Desta maneira, o código fica muito mais fácil, só precisamos mudar o conteúdo do elemento. Além disso, o componente Transitionals tem muitos tipos de transições, e podemos configurá-las de diversas maneiras. Por exemplo, o TranslateTrasition tem as propriedades StartPoint e EndPoint, dizendo onde começa e onde termina a transição. Para fazer da esquerda para direita, StartPoint deve ser –1,0 e EndPoint, 0,0. De cima para baixo, StartPoint deve ser 0,-1 e EndPoint, 0,0. Podemos inclusive fazer uma transição diagonal usando os pontos 1,1 e 0,0.

Eliminando o Code Behind

Uma das coisas que podem ser melhoradas aqui é a eliminação do code behind, usando o padrão de projeto MVVM. Para isso, usaremos o framework MVVM Light, que pode ser obtido gratuitamente em http://galasoft.ch, ou ainda instalado diretamente no projeto usando o Nuget, uma extensão para o Visual Studio que facilita o download e instalação de bibliotecas e ferramentas no Visual Studio. Se você ainda não baixou o Nuget, vá imediatamente para http://nuget.org e baixe-o. Vale a pena!

Uma vez instalado o Nuget, clique com o botão direito em References, no Solution Explorer e  selecione “Manage Nuget Packages”. Tecle “mvvm” na caixa de pesquisa e instale o pacote MVVM Light:

Isto instala o MVVM Light em nosso projeto, adiciona as referências necessárias e cria uma pasta ViewModel, com dois arquivos, MainViewModel.cs e ViewModelLocator.cs. MainViewModel.cs é o ViewModel referente à janela princiapl e ViewModelLocator é um localizador de ViewModel, referente à View.

Em MainViewModel.cs, colocamos uma propriedade, do tipo ViewModelBase, que conterá os ViewModel referente à View do conteúdo atual:

private ViewModelBase conteudo;

public ViewModelBase Conteudo
{
    get { return conteudo; }
    set
    {
        conteudo = value;
        RaisePropertyChanged("Conteudo");
    }
}

Criaremos em seguida dois ViewModels, que serão referentes à nossas Views. Os dois ViewModels são muito semelhantes e têm apenas uma propriedade:

public class ViewModelA : ViewModelBase
{
    private string texto;

    public string Texto
    {
        get { return texto; }
        set
        {
            texto = value;
            RaisePropertyChanged("Texto");
        }
    }
}

public class ViewModelB : ViewModelBase
{
    private string texto;

    public string Texto
    {
        get { return texto; }
        set
        {
            texto = value;
            RaisePropertyChanged("Texto");
        }
    }
}

Em seguida, crie no Solution Explorer um diretório chamado View e coloque lá dois UserControls, com apenas uma Grid com um TextBlock:

<UserControl x:Class="WpfApplication2.View.ViewA"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
             mc:Ignorable="d" 
             d:DesignHeight="300" d:DesignWidth="300">
    <Grid Background="Red">
        <TextBlock Text="{Binding Texto}" FontSize="36" />
    </Grid>
</UserControl>

Para eliminar o code behind, precisamos fazer um data binding da propriedade Content do TransitionElement com a propriedade conteúdo do ViewModel:

<transc:TransitionElement x:Name="TransitionBox" Content="{Binding Conteudo}">
    <transc:TransitionElement.Transition>
        <transt:TranslateTransition  StartPoint="1,0" EndPoint="0,0" Duration="0:0:1"/>
    </transc:TransitionElement.Transition>
</transc:TransitionElement>

e eliminar o clique do botão, substituindo-o por um Command:

<Button Width="65" Grid.Row="1" Content="Esconde" Margin="5" Command="{Binding EscondeCommand}" />

O command é definido no MainViewModel:

private ICommand escondeCommand;
public ICommand EscondeCommand
{
    get { return escondeCommand ?? (escondeCommand = new RelayCommand(MudaConteudo)); }
}

private void MudaConteudo()
{
    Conteudo = conteudo is ViewModelA ? 
        (ViewModelBase)new ViewModelB() { Texto = "ViewModel B"} : 
        (ViewModelBase)new ViewModelA() {Texto = " ViewModel A"};
}

Finalmente, devemos definir o DataContext para a View principal:

<Window x:Class="WpfApplication2.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:transc="clr-namespace:Transitionals.Controls;assembly=Transitionals"
        xmlns:transt="clr-namespace:Transitionals.Transitions;assembly=Transitionals" 
        Title="MainWindow" Height="350" Width="525"
        DataContext="{Binding Source={StaticResource Locator}, Path=Main}">

Ao executar o programa, temos algo como mostrado na figura abaixo:

A view não é mostrada, apenas o nome da classe do conteúdo. Isso era de se esperar, pois a propriedade Conteúdo é do tipo ViewModelBase e sua representação é o método ToString(). Poderíamos ter colocado a View como sendo o conteúdo, mas isto vai contra o padrão MVVM: o ViewModel não deve conhecer a View. Uma solução para mostrar a View a partir do ViewModel é usar um recurso disponível no WPF ou no Silverlight 5: Data Templates implícitos. Em um Data Template implicito, não explicitamos a Key, apenas dizemos qual é o DataType e, com isso o WPF/Silverlight renderezam este DataTemplate toda vez que um conteúdo for do tipo referente a ele.

Definimos então os DataTemplates na seção Resources da janela:

<Window.Resources>
    <DataTemplate DataType="{x:Type ViewModel:ViewModelA}" >
        <View:ViewA />
    </DataTemplate>
    <DataTemplate DataType="{x:Type ViewModel:ViewModelB}" >
        <View:ViewB />
    </DataTemplate>
</Window.Resources>

Agora, ao executar, temos a transição entre as duas views, sem o uso de code behind.

Conclusões

Usando componentes de animação de transições, temos a possibilidade de fazer transições muito sofisticadas, de maneira muito simples bastando mudar o conteúdo do componente.

Em seguida, vimos como tirar o código do code behind, colocando-o em um ViewModel, o que facilita na manutenção e permite maior testabilidade do código. Como bonus, vimos como usar implicit templates para ligar uma view a um viewmodel sem usar código. Este recurso está disponível apenas no WPF e no Silverlight 5. Embora você possa achar que não vale a pena (eliminamos apenas uma linha de código e incluímos dois viemodels, duas views, um novo componente MVVM, entre outros), minha intenção aqui foi mostrar como usar outros recursos, como a introdução do MVVM ao invés do code behind e como usar novos recursos, como o DataTemplate implícito. Numa aplicação maior, que requer maiores cuidados, estas mudanças se justificam plenamente.

Mas estas não são as únicas maneiras de se fazer transições de controles. Nos próximos artigos, veremos quais são as outras maneiras. Até lá!