Capítulo 1: O modelo de aplicativo "Longhorn"
Capítulo 1: O modelo de aplicativo "Longhorn"
Refatoração Brent
Wise Owl Consulting
Outubro de 2003
Sumário
Recursos do modelo de aplicativo "Longhorn"
A classe do aplicativo
A classe NavigationApplication
XAML (linguagem XAML)
Resumo
Por que precisamos de um novo modelo de aplicativo? Um dos principais motivos é preencher a lacuna entre o desenvolvimento de um aplicativo para o Microsoft® Windows® e o desenvolvimento de um aplicativo para a Web.
Hoje, ao escrever um aplicativo do Windows, você pode aproveitar os recursos do Windows. Seu aplicativo pode fornecer uma interface do usuário avançada e responsiva. Você pode instalar o aplicativo no computador cliente, o que permite que o aplicativo seja executado offline, sem uma conexão de rede. Os aplicativos do Windows podem aproveitar os recursos de hardware do computador cliente.
No entanto, os aplicativos tradicionais do Windows também têm várias desvantagens. Normalmente, você deve instalar um aplicativo do Windows. Isso dificulta a implantação do aplicativo e de todas as atualizações. Os aplicativos do Windows não são executados no navegador. Portanto, paradigmas familiares da interface do usuário da Web, como aplicativos orientados a páginas, navegação diretamente de uma página para outra, histórico de páginas e muito mais não estão disponíveis para seu aplicativo, a menos que você os crie do zero. Os aplicativos do Windows também não dão suporte a texto muito bem, especialmente quando você tenta misturar texto e elementos gráficos na mesma página. Criar um aplicativo do Windows que flui automaticamente texto em torno de elementos gráficos e que responde a alterações iniciadas pelo usuário no tamanho da janela e preferências do usuário para fontes e legibilidade é uma grande quantidade de trabalho.
Os aplicativos Web também têm seus próprios pontos fortes distintos. Quando você navega até uma página da Web, o navegador baixa apenas essa página e os componentes que a página requer. Quando você navega para uma nova página, o navegador baixa os requisitos da nova página. Em outras palavras, o navegador baixa progressivamente o aplicativo conforme necessário.
A implantação de um aplicativo Web é trivial. Qual implantação? Você coloca os componentes de aplicativo necessários em um servidor e o navegador os baixa conforme necessário. Não há nenhuma implantação em si.
Criar a interface do usuário para um aplicativo Web também é muito fácil. Você declara suas intenções usando marcação. Por exemplo, suponha que eu queira uma tabela em uma posição específica. Quero que uma imagem siga a tabela. Quero que um texto flua pela imagem. Misturar texto, elementos gráficos e mídia (som e vídeo) em um aplicativo Web é simples.
É claro que os aplicativos Web também têm seus pontos ruins. Não é possível instalar um aplicativo Web no sistema da área de trabalho; portanto, o aplicativo não pode ser executado offline. Você sempre deve ter uma conexão com o servidor. Determinadas operações de aplicativo exigem viagens de ida e volta para o servidor e isso diminui o desempenho. Uma seleção de controles de aplicativo Web é bastante primitiva em comparação com os controles disponíveis do Windows. Portanto, um aplicativo Web normalmente tem uma interatividade ruim. Também é difícil desenvolver uma interface do usuário atraente para um aplicativo Web porque você deve expressar qualquer layout não trivial usando tabelas.
Atualmente, os desenvolvedores que projetam novos aplicativos precisam tomar uma decisão inicial, enorme e irreversível: o aplicativo deve ser um aplicativo no estilo Web ou um aplicativo Clássico do Microsoft Win32®? Modelos de programação completamente separados (e habilidades!) são necessários dependendo de qual modelo de aplicativo você escolher.
"Longhorn" permite que você desenvolva aplicativos usando o melhor dos dois mundos. O modelo de aplicativo "Longhorn" usa os melhores recursos de aplicativos Web e os melhores recursos de aplicativos do Windows e os combina em um único modelo de programação unificado com base no código gerenciado.
Um segundo motivo importante para desenvolver um novo modelo de aplicativo é fornecer um único modelo de programação que possa criar a ampla variedade de "aplicativos" em uso hoje. Veja um de seus sites favoritos, como CNN ou MSNBC. O site é um aplicativo tradicional? É um documento? É uma apresentação multimídia? Em muitos casos, a resposta é sim para todas as três perguntas.
Quando um site inclui elementos de interface do usuário, como caixas de listagem, controles de edição e botões de opção, ele se parece com um aplicativo apresentando uma interface do usuário. No entanto, quando ele exibe imagens e texto fluindo ao redor das imagens, o site é semelhante a um documento. Quando apresenta conteúdo flash, elementos gráficos, áudio, vídeo e animação, o site parece ser uma apresentação multimídia.
É claro que sites tão avançados são difíceis de desenvolver. Você precisa corrigir uma descrição baseada em marcação HTML da página, com controles Do Microsoft ActiveX® para uma interface do usuário avançada, com animações Flash inseridas e possivelmente usando PDF (Portable Document Format) para suporte a documentos. Todas essas tecnologias usam uma arquitetura diferente, fornecem características de desempenho diferentes e exigem diferentes modelos e ferramentas de programação.
Isso normalmente significa que você deve contratar vários desenvolvedores com conjuntos de habilidades diferentes para desenvolver cada parte do aplicativo. Em seguida, os desenvolvedores devem mesclar os diferentes modelos em um único aplicativo de trabalho. O desenvolvimento do aplicativo já é difícil o suficiente. Depurá-lo muitas vezes é um pesadelo.
O "Longhorn" fornece uma arquitetura unificada que dá suporte a essas três camadas: documentos, aplicativos e mídia. Deseja criar sua interface do usuário declarativamente usando marcação? Vá em busca. Você precisa usar controles avançados do Windows? Então faça isso! Deseja escrever manipuladores de eventos em uma linguagem gerenciada fortemente tipada? Você pode fazer isso também. Deseja misturar texto, elementos gráficos e vídeo em um documento com layout inteligente e apresentação de acordo com as preferências do usuário e otimizado para melhor visualização e leitura no sistema cliente? Adivinha? Você também tem isso.
O modelo de aplicativo "Longhorn" possibilita escrever um aplicativo usando um único modelo de programação que dá suporte à funcionalidade de interface do usuário no estilo do aplicativo, à apresentação em estilo de documento de texto e elementos gráficos e à integração de várias mídias. Além disso, você pode criar a interface do usuário usando marcação como um aplicativo Web. Você também obtém a facilidade de implantação (ou falta de implantação) de um aplicativo Web. No entanto, você ainda tem o desempenho e a capacidade de instalar o aplicativo para uso offline como um aplicativo do Windows. Seu aplicativo pode ser executado como um aplicativo autônomo ou hospedado em um navegador da Web simplesmente recompilando uma base de código-fonte. Em ambos os casos, seu aplicativo pode ser baseado em formulário, como muitos aplicativos tradicionais do Windows ou baseados em página, como aplicativos Web.
Recursos do modelo de aplicativo "Longhorn"
O modelo de aplicativo "Longhorn" define o que é um aplicativo:
- Seus pontos de entrada
- Seu fluxo de controle – como navegar de uma página para outra
- Seu estado e recursos compartilhados
- Eventos em todo o aplicativo
- Seu isolamento de outros aplicativos
O modelo de aplicativo "Longhorn" define como implantar e manter um aplicativo:
- Implantação como um ou vários arquivos
- Atualizar, reverter e administração
O modelo de aplicativo "Longhorn" define a experiência do usuário com o aplicativo:
- Instalação de impacto zero
- Autônomo (estilo Windows) ou integrado no navegador
- Executa online ou offline
- Modelo de navegação
Aplicativos Web "Longhorn"
O modelo de aplicativo "Longhorn" permite que você escreva um aplicativo avançado da mesma forma que você escreve os aplicativos Web atuais. Isso fornece um caminho de migração fácil para desenvolvedores Web, pois o código que eles escrevem é semelhante ao código para páginas da Web DHTML (HTML dinâmico). Eles podem (estremecer) colocar marcação e script no mesmo arquivo. Eles podem implantar os arquivos do aplicativo em um servidor Web. As páginas do aplicativo são executadas no navegador da Web.
No entanto, o modelo de objeto para um aplicativo no estilo Web "Longhorn" é muito mais simples e muito mais poderoso do que o DHTML. O código do aplicativo pode usar a camada de apresentação completa "Longhorn". Portanto, um aplicativo Web "Longhorn" pode usar controles de cliente avançados, dar suporte a multimídia e gráficos na página, manipular eventos localmente— basicamente tudo o que um aplicativo cliente normal pode fazer. Na verdade, um aplicativo Web "Longhorn" não é muito diferente de um aplicativo de área de trabalho "Longhorn" diferente do que os arquivos residem em um servidor; um navegador normalmente, mas não necessariamente, hospeda a interface do usuário; e o aplicativo é executado com permissões restritas porque o usuário não o instalou no sistema cliente.
Aplicativos da área de trabalho "Longhorn"
O modelo de aplicativo "Longhorn" também define como escrever aplicativos da área de trabalho. Um aplicativo da área de trabalho"Longhorn" é um aplicativo que o usuário instalou localmente. Esses aplicativos podem ser executados online ou offline. Esses aplicativos podem se registrar com o shell, colocar ícones na área de trabalho, adicionar atalhos ao menu Iniciar e muito mais.
Um aplicativo da área de trabalho também pode ser executado na janela do navegador ou em uma janela autônoma. Na verdade, um aplicativo da área de trabalho pode dar suporte a muitos recursos tradicionalmente associados a um aplicativo Web, incluindo o seguinte:
- Definir explicitamente pontos de entrada externos, ou seja, podem ser iniciados em qualquer página
- Compartilhar estado entre páginas
- Manipular vários eventos, incluindo eventos de navegação de página
- Controlar o fluxo do aplicativo
- Adicionar/remover entradas de um histórico de páginas/log de navegação de viagem
- Iniciar janelas de aplicativos
Criando um aplicativo "Longhorn"
Para criar um aplicativo "Longhorn", defina o modelo de objeto para seu aplicativo. Você pode definir o modelo programaticamente escrevendo código ou declarativamente escrevendo marcação em uma linguagem chamada XAML (Extensible Application Markup Language). Você compila seu código e/ou marcação em um ou mais assemblies .NET, um arquivo de manifesto do aplicativo e um arquivo de manifesto de implantação.
Opcionalmente, você pode empacotar seu aplicativo em um novo formato de arquivo, chamado de contêiner. Os arquivos de aplicativo em um contêiner podem ser compactados, criptografados e assinados digitalmente.
Discuto a criação de um aplicativo "Longhorn" em detalhes no Capítulo 2, mas por enquanto a ideia main é que a criação de um aplicativo "Longhorn" fornece o código do aplicativo, um manifesto do aplicativo que descreve todos os componentes que o aplicativo usa e um manifesto de implantação que informa ao sistema como instalar e manter o aplicativo.
Implantando um aplicativo "Longhorn"
O modelo de aplicativo "Longhorn" fornece uma implantação fácil e econômica do seu aplicativo. No caso mais simples, basta copiar os arquivos de aplicativo para um servidor. Da mesma forma, a instalação do aplicativo é simples e não impactante.
Uma opção é não instalar o aplicativo. O usuário pode navegar até o manifesto do aplicativo em um servidor e executá-lo. "Longhorn" baixa incrementalmente seu aplicativo e o executa. Você não recebe nenhuma solicitação de confirmação, nenhum requisito de reinicialização e nenhuma DLL hell. Na verdade, você nem precisa de direitos de Administrador para instalar ou executar o aplicativo.
Como alternativa, o usuário pode navegar até o manifesto de implantação do aplicativo no servidor e executá-lo. "Longhorn" baixa incrementalmente seu aplicativo, instala-o e o executa. Por padrão, todos os aplicativos "Longhorn" são executados em um ambiente de permissão limitado chamado SEE (Ambiente de Execução Segura).
Os aplicativos em execução no SEE recebem um conjunto de permissões restrito que é aproximadamente equivalente às permissões concedidas aos aplicativos atuais associados à zona da Internet. Um aplicativo que requer permissões adicionais que "Longhorn" fornece por padrão deve solicitar essas permissões adicionais no manifesto do aplicativo.
Na primeira vez que o usuário executar esse aplicativo, o Gerenciador de Confiança "Longhorn" avaliará a solicitação de permissão elevada, notificará o usuário sobre um nível de risco sugerido associado à concessão da solicitação de permissão do aplicativo e fornecerá uma resposta sugerida para esse nível de risco. Quando o usuário permite que o Gerenciador de Confiança conceda ao aplicativo suas permissões solicitadas, o Gerenciador de Confiança registra essas informações. As execuções subsequentes do aplicativo instalado prossseguem sem o aviso de segurança.
Hoje, quando você instala um aplicativo localmente, ele recebe o conjunto de permissões FullTrust simplesmente porque ele é carregado da zona LocalComputer. A CAS (Segurança de Acesso ao Código) funciona de forma diferente para aplicativos "Longhorn". Um aplicativo local (ou instalado) é executado sob a política de segurança do site do qual o usuário o baixou em vez de receber o FullTrust automaticamente simplesmente porque ele está instalado localmente.
Ao carregar um aplicativo, seus componentes e seus recursos, "Longhorn" fornece evidências para o sistema de segurança CLR (Common Language Runtime), como
- Zona da Internet e site de origem (do Uniform Resource Identifier [URI])
- Nome do editor e do módulo (do manifesto de implantação)
O CAS fornece a imposição baseada em política de segurança sobre privilégios de acesso com base nas evidências do aplicativo.
O manifesto de implantação de um aplicativo pode especificar o intervalo de atualização que "Longhorn" deve usar ao verificar se há uma nova versão do aplicativo. Quando "Longhorn" detecta que uma nova versão está disponível, ela baixa e instala a nova versão em segundo plano. Na próxima vez que o usuário executar o aplicativo, ela receberá a nova versão.
Ao instalar um aplicativo, "Longhorn" preserva a versão anterior, se houver. Caso precise, você pode reverter sem dor para a versão anterior ou até mesmo desinstalar completamente o aplicativo usando Adicionar/Remover Programas. Os departamentos de TI podem enviar por push a instalação de um aplicativo para um sistema cliente para uma implantação de mãos livres.
Você especifica como implantar o aplicativo ao compilar o projeto e pode alterar o cenário de implantação recompilando, normalmente com poucas ou nenhuma alteração no código-fonte.
O programa de um desenvolvedor interage inicialmente com grande parte do suporte a aplicativos "Longhorn" por meio de uma instância da classe MSAvalon.Windows.Application , portanto, vamos examinar essa classe.
A classe application
Um programa "Longhorn" sempre contém uma única instância de um objeto de aplicativo. Esse objeto deriva direta ou indiretamente da classe MSAvalon.Windows.Application e executa as seguintes funções:
- Fornece um ponto de entrada, encapsulamento e escopo para o aplicativo
- Permite que um aplicativo compartilhe código e estado entre as páginas que compõem o aplicativo
- Fornece eventos no nível do aplicativo
- Mantém uma coleção de janelas do aplicativo
- Fornece um modelo de segurança
- Define todos os recursos que o aplicativo usa
A classe MSAvalon.Windows.Application fornece suporte básico ao aplicativo para um aplicativo. Normalmente, você o usa quando seu aplicativo precisa de baixa sobrecarga e não usa recursos de navegação de página. No entanto, a maioria dos aplicativos de plataforma "Longhorn" usa a classe MSAvalon.Windows.NavigationApplication intimamente relacionada, que herda de MSAvalon.Windows.Application e adiciona suporte para navegação. Discutirei a classe NavigationApplication em detalhes na seção a seguir. Normalmente, você definirá uma classe que herda a classe base apropriada, substitui os métodos de classe base conforme necessário e, em seguida, registra eventos para fornecer procedimentos personalizados de inicialização ou desligamento.
A listagem de arquivos de origem SimpleApplication1.cs, mostrada aqui, demonstra o uso do objeto Application . O método EntryClass.Main cria meu objeto de aplicativo especializado, MyApp, e chama seu método Run para iniciar o aplicativo. A classe MyApp substitui o método OnStartingUp , que recebe o controle quando o aplicativo está sendo inicializado. Quando o sistema invoca o método OnStartingUp, eu chamo um método auxiliar que cria a janela main do aplicativo, adiciona algum texto à janela e exibe a janela.
SimpleApplication1.cs
using System;
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Media;
namespace IntroLonghorn {
public class MyApp : MSAvalon.Windows.Application {
MSAvalon.Windows.Controls.SimpleText txtElement;
MSAvalon.Windows.Window mainWindow;
protected override void OnStartingUp (StartingUpCancelEventArgs e) {
base.OnStartingUp (e);
CreateAndShowMainWindow ();
}
private void CreateAndShowMainWindow () {
// Create the application's main window
mainWindow = new MSAvalon.Windows.Window ();
// Add a dark red, 14 point, "Hello World!" text element
txtElement = new MSAvalon.Windows.Controls.SimpleText ();
txtElement.Text = "Hello World!";
txtElement.Foreground = new
MSAvalon.Windows.Media.SolidColorBrush (Colors.DarkRed);
txtElement.FontSize = new FontSize (14,
FontSizeType.Point);
mainWindow.Children.Add (txtElement);
mainWindow.Show ();
}
}
internal sealed class EntryClass {
[System.STAThread]
private static void Main () {
MyApp app = new MyApp ();
app.Run ();
}
}
}
Usei a linha de comando a seguir para compilar o código-fonte SimpleApplication1.cs em um aplicativo executável. Talvez seja necessário ajustar os caminhos para os assemblies referenciados.
csc /r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\PresentationCore.dll
/r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\PresentationFramework.dll
/r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\WindowsBase.dll
SimpleApplication1.cs
A classe Application contém várias outras propriedades, métodos e eventos úteis. Por exemplo, sua classe de aplicativo pode substituir o método virtual OnShuttingDown para fornecer um comportamento de desligamento personalizado. A classe de aplicativo também fornece os eventos StartingUp e ShuttingDown para que outras classes possam se registrar para notificações de inicialização e desligamento. O método Shutdown permite que você inicie o desligamento do aplicativo programaticamente.
Talvez você queira fazer referência ao objeto de aplicativo de vários locais no código-fonte. Portanto, a classe Application fornece a propriedade estática Current que retorna uma referência ao objeto de aplicativo. O fragmento de código a seguir usa a propriedade Current para localizar o objeto de aplicativo e registrar-se para uma notificação de evento de desligamento:
MyApp app = (MyApp) MSAvalon.Windows.Application.Current;
app.ShuttingDown += new
Application.ShuttingDownEventHandler (ShutDownHandler);
§
private static void
ShutDownHandler (object sender, MSAvalon.Windows.ShuttingDownEventArgs e) {
§
}
A classe NavigationApplication
Quando você quiser suporte de navegação para seu aplicativo, normalmente usará a classe MSAvalon.Windows.Navigation.NavigationApplication , que estende a classe MSAvalon.Windows.Application . Embora você possa criar um aplicativo baseado em navegação sem usar a classe NavigationApplication , o uso da classe fornece os seguintes recursos adicionais para seu aplicativo:
- Simplifica a escrita de aplicativos baseados em navegação; normalmente não é necessário subclasse da classe
- Determina quando uma conexão está disponível
- Fornece eventos de navegação, como Navegação, NavigationProcess, Navegador, NavigationError, LoadCompleted e Parado, que são acionados quando o evento apropriado ocorre em qualquer uma das janelas do aplicativo
- Estado de compartilhamentos entre páginas
- Fornece um contêiner para valores de propriedade compartilhados entre páginas
- Implementa uma política que abre uma janela inicial por padrão
Externamente, o usuário de um aplicativo de navegação pode navegar apenas para pontos de entrada bem definidos do aplicativo. Internamente, no entanto, o desenvolvedor controla a navegação conectando eventos. Você pode determinar quando uma janela ou quadro tenta navegar até uma nova página e quando a navegação é concluída. Você pode cancelar ou redirecionar qualquer navegação. Você pode descobrir a identidade da página de destino. Você pode lidar com erros de navegação.
O modelo de navegação familiar facilita o uso de um aplicativo. Um aplicativo de navegação fornece um comportamento semelhante à Web. Seu aplicativo pode usar hiperlinks, fornecer botões Encaminhar e Voltar, exibir uma lista Favoritos e manter um Histórico de páginas. A classe NavigationApplication "Longhorn" e as classes relacionadas fornecem todo o suporte para esses recursos.
Um aplicativo de navegação funciona online ou offline e funciona da mesma forma se um navegador hospeda o aplicativo ou o aplicativo é executado como autônomo. Além disso, você tem controle total sobre esse comportamento weblike. Você pode personalizar a experiência do usuário conforme necessário. Você pode inserir, remover e modificar entradas do Travelog para controlar para onde vão as operações Avançar e Voltar. Você pode definir quais páginas (pontos de entrada) estão registradas no Histórico.
Um aplicativo de navegação normalmente cria uma ou mais instâncias da classe MSAvalon.Windows.Navigation.NavigationWindow . A listagem SimpleApplication2.cs, mostrada aqui, demonstra o uso dessas classes. Essa listagem é a mesma que SimpleApplication1.cs, exceto que usa as classes NavigationApplication e NavigationWindow .
SimpleApplication2.cs
using System;
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Media;
using MSAvalon.Windows.Navigation;
namespace IntroLonghorn {
public class MyApp : MSAvalon.Windows.Navigation.NavigationApplication {
protected override void OnStartingUp (StartingUpCancelEventArgs e) {
base.OnStartingUp (e);
CreateAndShowMainWindow ();
}
private void CreateAndShowMainWindow () {
// Create the application's main window
mainWindow = new MSAvalon.Windows.Navigation.NavigationWindow ();
// Fill window with appropriate controls
§
// Show the window
mainWindow.Show ();
}
}
internal sealed class EntryClass {
[System.STAThread]
private static void Main () {
MyApp app = new MyApp ();
app.Run ();
}
}
}
O código que você viu até agora é apenas mais uma variação em modelos de programação tradicionais. O único aspecto novo são as classes reais que usei. Na maioria das vezes, no entanto, você não escreverá muito desse código. Vamos fazer um pequeno desvio e aprender sobre uma nova linguagem de programação que permite que você escreva esse mesmo código de uma maneira muito mais compacta e, para mim, pelo menos, mais compreensível.
XAML (linguagem XAML)
Em muitos aplicativos, grande parte do código que você escreve pertence à criação e atualização da interface do usuário do aplicativo. Na verdade, nos exemplos anteriores, não havia nenhum código diferente daquele necessário para criar a interface do usuário. Nos últimos anos, muitos desenvolvedores aprenderam a escrever e até mesmo a preferir definir a interface do usuário de um aplicativo usando uma das várias linguagens de marcação disponíveis. A plataforma "Longhorn" define uma nova linguagem de marcação chamada XAML (Extensible Application Markup Language; pronunciada "Zamel", que rima com "camel").
Usar uma linguagem de marcação para definir uma interface do usuário tem várias vantagens em relação ao uso de uma linguagem de programação de procedimento. Essas vantagens incluem o seguinte:
- Hierarquias de controle mais aparentes
- Herança de propriedade mais aparente
- Processamento e interpretação mais fáceis da linguagem de marcação por ferramentas
- Possível separação da interface do usuário e do código de procedimento
Gosto de XAML e prefiro usá-la para definir minhas interfaces do usuário em vez de usar a codificação de tipo de procedimento que mostrei até agora neste capítulo. No entanto, não pense que você será capaz de fazer tudo o que precisa usando nada além de XAML.
Considere esta instrução na documentação: "Os documentos geralmente podem ser escritos inteiramente em XAML e exibidos no navegador". Destaco às pressas que essa frase usa a palavra documentos, não aplicativos, e qualifica a instrução com o termo com frequência. Ao escrever um documento que exibe conteúdo estático, você pode criá-lo em XAML puro. Você pode até mesmo escrever um documento que usa a associação de dados para exibir e atualizar o conteúdo de uma fonte de dados usando nada além de XAML. Você pode definir animações e efeitos sobre o mouse usando nada além de XAML. Você pode fazer muita coisa usando nada além de XAML. (Na verdade, tento fazer o máximo possível em XAML e o mínimo possível no código. Meus aplicativos parecem ser menos bugs e funcionam mais rapidamente quanto menos código eu escrever!) No entanto, para escrever um aplicativo de produção, você normalmente precisará reagir a eventos, fornecer lógica de decisão personalizada ou incluir muitas outras operações que não sejam de interface do usuário, portanto, você precisará misturar XAML e código. Felizmente, isso é extremamente fácil de fazer.
Descreverei os arquivos XAML mais detalhadamente no Capítulo 3; por enquanto, vamos examinar uma cartilha para XAML:
- Um nome de elemento XAML é um nome de classe .NET Framework. Ao definir um elemento XAML, você está efetivamente criando uma instância da classe .NET Framework com o mesmo nome que o elemento XAML.
- Um nome de atributo XAML é mapeado para a propriedade ou campo com o mesmo nome, normalmente na instância de classe.
No programa SimpleApplication1.cs, crio uma janela e adiciono alguns controles a ela usando o seguinte código:
// Create the application's main window
mainWindow = new MSAvalon.Windows.Window ();
// Add a dark red, 14 point, "Hello World!" text element
txtElement = new MSAvalon.Windows.Controls.SimpleText ();
txtElement.Text = "Hello World!";
txtElement.Foreground = new
MSAvalon.Windows.Media.SolidColorBrush (Colors.DarkRed);
txtElement.FontSize = new FontSize (14, FontSizeType.Point);
mainWindow.Children.Add (txtElement);
mainWindow.Show ();
O documento XAML a seguir produz exatamente essa mesma interface do usuário.
HelloWorld.xaml
<Window xmlns="https://schemas.microsoft.com/2003/xaml" Visible="true">
<SimpleText Foreground="DarkRed" FontSize="14">Hello World!</SimpleText>
</Window>
O elemento Window raiz cria uma instância de uma classe chamada MSAvalon.Windows.Window. De alguma forma, o sistema de build precisa saber que o elemento XAML chamado Window se refere a uma instância da classe chamada MSAvalon.Windows.Window. O valor do atributo xmlns fornece esse mapeamento.
Os analisadores XML interpretam nomes de elementos não qualificados em relação ao namespace especificado no atributo de namespace padrão mais recente, no escopo, xmlns. Quando você especifica um valor xmlns de "https://schemas.microsoft.com/2003/xaml", o sistema de build interpreta um nome de elemento não qualificado no elemento definidor ou um de seus elementos subordinados, como o nome de uma classe em um conjunto predefinido de namespaces.
Deixe-me reafirmar isso em termos mais concretos, usando C# como exemplo. A declaração xmlns adiciona efetivamente uma série de instruções using ao seu código. Em seguida, o sistema de build interpreta cada nome de elemento XAML não qualificado como um nome de classe com as declarações using fornecendo o contexto para os namespaces possíveis. Embora a lista possa ser alterada, no momento desta gravação, especificar o valor padrão para o atributo de namespace padrão causa a inclusão das seguintes instruções using :
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Controls.Primitives;
using MSAvalon.Windows.Data;
using MSAvalon.Windows.Documents;
using MSAvalon.Windows.Shapes;
using MSAvalon.Windows.Media;
using MSAvalon.Windows.Media.Animation;
using MSAvalon.Windows.Navigation;
A declaração de namespace padrão padrão também faz com que o sistema de build faça referência aos assemblies PresentationFramework e PresentationCore , que contêm classes nos namespaces listados anteriormente.
Defina o atributo Visible do elemento Window como true. Isso corresponde ao meu código original que exibe a janela chamando seu método Show .
Aninhado um elemento SimpleText na definição do elemento Window . Isso instrui o sistema a instanciar um objeto MSAvalon.Windows.Controls.SimpleText, torná-lo um filho do objeto Window e definir o valor do objeto de texto simples como a cadeia de caracteres "Olá, Mundo!".
Salve o código XAML anterior em um arquivo chamado HelloWorld.xaml e execute o arquivo. O navegador interpretará o código XAML no arquivo e exibirá a interface do usuário, conforme mostrado na Figura 1-1.
.gif)
Figura 1-1. O navegador que exibe a versão XAML do Olá, Mundo (clique em imagem para ver uma imagem maior)
Talvez você queira usar uma classe .NET que não esteja definida em um dos namespaces padrão listados anteriormente. Um exemplo típico é usar uma classe de um assembly que você cria. O sistema de build precisa ser capaz de mapear o nome do elemento especificado no arquivo de origem XAML para a classe .NET apropriada no assembly correto. O XAML define uma instrução de processamento XML (PI) chamada ? Mapeamento que você usa para fazer essa associação.
O ? O mapeamento de PI permite que você defina um prefixo de namespace XML mapeado para um namespace e assembly CLR. Ao qualificar um nome de elemento XAML com esse prefixo de namespace, você informa ao sistema de build, na verdade, para tomar o nome do elemento, adicionar o prefixo CLR ao nome e criar uma instância da classe com o nome resultante. O compilador fará referência ao assembly especificado para que ele possa encontrar a definição da classe .
O exemplo a seguir cria uma instância da classe WiseOwl.Statistics.PoissonDeviate , a definição da qual reside no assembly WiseOwl.Statistics.Library :
<?Mapping XmlNamespace="stat" ClrNamespace="WiseOwl.Statistics"
Assembly="WiseOwl.Statistics.Library" ?>
<Window xmlns="https://schemas.microsoft.com/2003/xaml" Visible="true">
<SimpleText Foreground="DarkRed" FontSize="14">Hello World!</SimpleText>
<stat:PoissonDeviate Mean="5.0" />
</Window>
Não consigo enfatizar o suficiente de que o XAML é simplesmente outra maneira de produzir código que usa as classes de interface do usuário .NET Framework. Na verdade, você pode ter uma ferramenta que exibe uma especificação de interface do usuário XAML graficamente usando um designer visual. Outra ferramenta pode fazer o inverso e permitir que você crie a interface do usuário graficamente e salve-a como um arquivo XAML. Outra ferramenta pode salvar o design da interface do usuário como código de procedimento, que é semelhante ao funcionamento do designer WinForms. Todas essas abordagens são apenas métodos diferentes para especificar as mesmas informações.
Anteriormente neste capítulo, mencionei que o navegador poderia renderizar um arquivo XAML em sua janela. O navegador só pode fazer isso quando o arquivo XAML não contém nada além de marcação, como o exemplo simples acabou de ser mostrado. À medida que a interface do usuário se torna mais complicada, normalmente você precisará usar manipuladores de eventos e outro código-fonte não dinamarquês, além do XAML que descreve a interface do usuário. Sempre que você tiver uma base de código-fonte mista, ou seja, marcação e código-fonte não dinamarquês, deverá compilar a marcação e o código-fonte usando o utilitário MSBuild. Após a compilação, você pode executar o aplicativo como um componente autônomo ou fazer com que o navegador exiba a interface do usuário resultante.
Resumo
Muito bem! Agora você entende as noções básicas do novo modelo de aplicativo. Você aprendeu a usar a marcação para criar uma interface do usuário declarativamente, embora uma interface do usuário muito simples. Você pode escrever o equivalente a páginas da Web usando arquivos XAML e implantar esses arquivos em um servidor para um usuário procurar. No entanto, cenários mais interessantes normalmente exigirão que você compile o aplicativo antes de implantá-lo. Portanto, vamos entrar e aprender a criar e implantar um aplicativo "Longhorn".
Continue para o Capítulo 2: Criando um aplicativo "Longhorn".
© 2003 Microsoft Corporation. Todos os direitos reservados.
IntelliSense, Microsoft, MSDN, MS-DOS, Visual Basic .NET e Visual Studio .NET são marcas registradas ou marcas registradas da Microsoft Corporation no Estados Unidos e/ou em outros países. Outros nomes de produtos e empresas mencionados aqui podem ser as marcas registradas de seus respectivos proprietários.