Visão Geral do Gerenciamento de Aplicativo

Este tópico fornece uma visão geral dos serviços Windows Presentation Foundation (WPF) para criar e gerenciar aplicativos. O núcleo de um aplicativo WPF é a classe Application, que suporta uma variedade dos serviços principais de aplicativo. Este tópico fornece uma introdução ao mais importante desses serviços.

Este tópico contém as seguintes seções.

• A Classe do aplicativo
• A Definição de Aplicativo
• Obtendo o Aplicativo Corrente
• Tempo de vida do Aplicativo
• Outros Serviços de Aplicativos
• Tópicos relacionados

A Classe do aplicativo

Um aplicativo consiste em vários elementos particulares, como interface do usuário (UI), lógico de negócio, lógica de acesso a dados, controles, e dados. Estes elementos tipicamente diferem de um aplicativo para o outro. Entretanto, todos aplicativos tendem a compartilhar um conjunto comum de funcionalidades que facilitam a implementação e gerência do a aplicativo. Em WPF, esta funcionalidade comum de escopo de aplicativo é encapsulada na classe Application, que fornece os seguintes serviços:

• Criar e gerenciar infraestrutura comum de aplicativo

• Rastrear e interagir com tempo de vida do aplicativo

• Obter e processar parâmetros de linha de comando.

• Compartilhar propriedades e recursos de escopo de aplicativo.

• Detectar e responder a exceções não tratadas.

• Retornar códigos de saída.

• Gerenciar janelas em aplicativo autônomos (veja Visão geral do WPF do Windows).

• Rastrear e gerenciar navegação (veja Visão geral de navegação).

Para usar estes serviços no seu aplicativo, você precisa usar a classe Application para implementar uma definição de aplicativo.

A Definição de Aplicativo

Uma definição de aplicativo WPF é uma classe que deriva da Application e é configurada com um Mecanismo de compilação Microsoft (MSBuild) especial.

Implementando uma Definição de Aplicativo

Uma definição de aplicativo WPF típica é implementada usando tanto marcação como code-behind. Isto permite usar marcação para definir declarativamente propriedades de aplicativo, recursos, e registrar eventos, enquanto tratamento de eventos e implementação de comportamento específico do aplicativo no code-behind.

O exemplo a seguir mostra como implementar uma definição de aplicativo usando tanto marcação e code-behind.

<Application 
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml" 
  x:Class="SDKSample.App" />

using System.Windows;  // Application

namespace SDKSample
{
    public partial class App : Application { }
}

Para permitir que um arquivo de marcação e um arquivo de code-behind funcionem juntos, o seguinte precisa ocorrer:

• Na marcação, o elemento Application precisa incluir o atributo x:Class. Quando o aplicativo é construído, a existência do x:Class no arquivo de marcação causa o MSBuild a criar uma classe partial que deriva de Page e possui o nome que é especificado pelo atributo x:Class. Isto requer a adição de uma declaração de namespace XML no esquema XAML (xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml").

• No code-behind, a classe precisa ser uma classe partial com o mesmo nome que o especificado pelo atributo x:Class na marcação e precisa derivar de Application. Isto permite ao arquivo de lógica estar associado à classe partial que é gerada para o arquivo de marcação quando o aplicativo é construído (veja Building a WPF Application (WPF)).

Observação:
Quando você cria um novo Projeto WPF aplicativo ou WPF navegador aplicativo projeto Usando Microsoft Visual Studio, uma definição de aplicativo é incluída por padrão e é definida usando marcação e code-behind.

Este código é o mínimo exigido para implementar uma definição de aplicativo. Entretanto, uma configuração MSBuild adicional precisa ser feita à definição de aplicativo antes de construir e rodar o aplicativo.

Configurando a Definição de Aplicativo para o MSBuild

Aplicativos autônomos e aplicativos de navegador XAML (XBAPs) requerem a implementação de um certo nível de infraestrutura antes de poderem executar. A parte mais importante desta infraestrutura é o ponto de entrada. Quando um aplicativo é lançado por um usuário, o sistema operacional chama o ponto de entrada, que é uma função bem conhecida para iniciar aplicativos.

Tradicionalmente, desenvolvedores têm precisado escrever parte ou todo esse código por si mesmos, dependendo da tecnologia. However, WPF generates this code for you when the markup file of your application definition is configured as an MSBuild ApplicationDefinition item, as shown in the following MSBuild project file:

<Project 
  DefaultTargets="Build"
  xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
  ...
  <ApplicationDefinition Include="App.xaml" />
  <Compile Include="App.xaml.cs" />
  ...
</Project>

Porque o arquivo de code-behind contém código, ele é marcado como um item MSBuild Compile, como é normal.

A aplicação dessas configurações MSBuild nos arquivos de marcação e code-behind de uma definição de aplicativo causa o MSBuild a gerar código como o seguinte:

using System; // STAThread
using System.Windows; // Application

namespace SDKSample
{
    public class App : Application
    {
        public App() { }
        [STAThread]
        public static void Main()
        {
            // Create new instance of application subclass
            App app = new App();

            // Code to register events and set properties that were
            // defined in XAML in the application definition
            app.InitializeComponent();

            // Start running the application
            app.Run();
        }

        public void InitializeComponent()
        {


...


        }
    }
}

O código resultado aumenta sua definição de aplicativo com código de infraestrutura adicionais, que incluem o método de ponto de entrada Main. The STAThreadAttribute atributo é aplicado para a Main método para indicar que o principal UI thread para o WPF aplicativo é um segmento STA, que é necessário para WPF aplicativos. Quando chamado, Main cria uma nova instância de App antes de ligar o InitializeComponent método para registrar os eventos e conjunto as propriedades que são implementados na marcação. Porque InitializeComponent é gerado para você, não precisa chamar InitializeComponent explicitamente de uma definição de aplicativo como é feito para implementações Page e Window. Finalmente, o método Run é chamado para iniciar o aplicativo.

Obtendo o Aplicativo Corrente

Porque os serviços da classe Application são compartilhados através do aplicativo, só pode existir uma instância da classe Application por AppDomain. To enforce this, the Application class is implemented as a singleton class (see Implementing Singleton in C#), which creates a single instance of itself and provides shared access to it with the static Current property.

O código a seguir mostra como obter uma referência para o objeto Application do AppDomain corrente.

// Get current application
Application current = App.Current;

Current retorna uma referência para uma instância da classe Application. Se quiser uma referência para sua classe derivada de Application, você precisa converter o valor da propriedade Current, como mostrado no exemplo seguinte.

// Get strongly-typed current application
App app = (App)App.Current;

Você pode inspecionar o valor de Current em qualquer ponto do tempo de vida de um objeto Application. Entretanto, você deve ser cauteloso. Depois da classe Application ser instanciada, existe um período no qual o estado do objeto Application está inconsistente. Durante esse período, o Application é fazendo várias tarefas de inicialização necessárias para seu código executar, como estabelecendo uma infraestrutura de aplicativo, definindo propriedades, e registrando eventos. Se você tentar usar o objeto Application durante esse período, seu código pode ter resultados inesperados, em particular se ele depende das várias propriedades Application estarem definidas.

Quando Application completa seu trabalho de inicialização, seu tempo de vida realmente começa.

Tempo de vida do Aplicativo

O tempo de vida de um aplicativo WPF é marcado por diversos eventos disparados pelo Application para informá-lo quando seu aplicativo iniciou, foi ativado ou desativado e foi desligado.

Splash Screen

A partir de .NET Framework 3.5 SP1, você pode especificar uma imagem a ser usado em uma janela de inicialização, ou tela inicial de abertura. The SplashScreen classe torna fácil exibir uma janela de inicialização, enquanto o aplicativo é carregado. The SplashScreen janela é criada e mostrada antes Run é chamado. Para obter mais informações, consulte time de inicialização do aplicativo e Como: Adicionar uma tela inicial de abertura para um aplicativo do WPF.

Iniciando um Aplicativo

Depois que Run é chamado e o aplicativo inicializado, o aplicativo está pronto para executar. Este momento é sinalizado quando o evento Startup é disparado:

using System.Windows; // Application, StartupEventArgs, WindowState

namespace SDKSample
{
    public partial class App : Application
    {
        void App_Startup(object sender, StartupEventArgs e)
        {
            // Application is running


...


        }
    }
}

Nesse momento do tempo de vida do aplicativo, a coisa mais comum a se fazer é exibir a UI.

Exibindo a Interface de Usuário

A maioria dos aplicativos Windows autônomos abrem uma Window quando começam a executar. O tratador do evento Startup é um dos locais de onde você pode fazer isso, como demonstrado pelo código a seguir.

<Application
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App" 
  Startup="App_Startup" />

using System.Windows; // Application, StartupEventArgs

namespace SDKSample
{
    public partial class App : Application
    {
        void App_Startup(object sender, StartupEventArgs e)
        {
            // Open a window
            MainWindow window = new MainWindow();
            window.Show();
        }
    }
}

Observação:
O primeiro Window para ser instanciado em um aplicativo autônomo torna-se na janela principal do aplicativo por padrão. Esse objeto Window é referenciado pela propriedade Application.MainWindow. O valor da propriedade MainWindow pode ser alterado programaticamente se uma janela diferente da primeira Window instanciada deve ser a janela principal.

Quando um XBAP inicia a primeira vez, ele vai provavelmente navegar para uma Page. Isto é mostrado no código a seguir.

Se você trata Startup apenas para abrir uma Window ou navegar para uma Page, então você pode definir o atributo StartupUri em marcação ao invés.

O exemplo a seguir mostra como usar a StartupUri de um aplicativo autônomo para abrir uma Window.

<Application
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    StartupUri="MainWindow.xaml" />

O exemplo a seguir mostra como usar StartupUri de um XBAP para navegar para uma Page.

<Application
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    StartupUri="HomePage.xaml" />

Essa marcação tem o mesmo efeito que o código anterior para abrir uma janela.

Observação:
Para obter mais informações sobre navegação, s EE Visão geral de navegação.

Você precisa tratar o evento Startup para abrir uma Window se você necessita instanciá-la usando um construtor que não seja o padrão, ou se você precisa definir suas propriedades ou assinar seus eventos antes de exibí-la, ou precisa processar argumentos de linha de comando que foram passados quando o aplicativo foi lançado.

Processando Argumentos de Linha de Comando

Em Windows, aplicativos autônomos podem ser lançados a partir de um prompt de comando ou do desktop. Em ambos os casos, argumentos de linha de comando podem ser passados para o aplicativo. O exemplo a seguir mostra um aplicativo é iniciado com um único argumento de linha de comando "/ StartMinimized":

wpfapplication.exe /StartMinimized

Durante a inicialização do aplicativo, WPF obtém os argumentos de linha de comando do sistema operacional e os passa ao tratador de evento Startup via propriedade Args do parâmetro StartupEventArgs. Você pode obter e armazenar os argumentos de linha de comando usando código como a seguir.

<Application
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App"
  Startup="App_Startup" />

using System.Windows; // Application, StartupEventArgs, WindowState

namespace SDKSample
{
    public partial class App : Application
    {
        void App_Startup(object sender, StartupEventArgs e)
        {
            // Application is running
            // Process command line args
            bool startMinimized = false;
            for (int i = 0; i != e.Args.Length; ++i)
            {
                if (e.Args[i] == "/StartMinimized")
                {
                    startMinimized = true;
                }
            }

            // Create main application window, starting minimized if specified
            MainWindow mainWindow = new MainWindow();
            if (startMinimized)
            {
                mainWindow.WindowState = WindowState.Minimized;
            }
            mainWindow.Show();
        }
    }
}

O código trata Startup para verificar se o argumento de linha de comando /StartMinimized foi fornecido; caso tenha sido, ele abre a janela principal com um WindowState de Minimized. Note que como a propriedade WindowState precisa ser definida programaticamente, a Window principal precisa ser aberta explicitamente em código.

Para um exemplo que demonstra uma análise de linha de comando mais robusta usando expressões regulares, veja Exemplo de argumentos de linha de comando de processamento.

XBAPs não pode recuperar e processar argumentos de linha de comando porque eles são lançados usando implantação ClickOnce (veja Implantar um aplicativo WPF (WPF)). Entretanto, eles podem recuperar e processar parâmetros da string de consulta de URLs usadas para lança-los. Para um exemplo, consulte URI Consulta Cadeia de Caracteres parâmetros de exemplo.

Ativação e Desativação de Aplicativo

Windows permite que os usuários alternem entre aplicativos. A maneira mais comum é usar a combinação de teclas ALT+guia. Um aplicativo só pode ser alternado para se possuir uma Window visível que o usuário pode selecionar. O selecionado no momentoWindow é o janela ativa (também conhecido sistema autônomo a janela de primeiro plano) e é o Window entrada do usuário que recebe. O aplicativo com a janela ativa é o aplicativo ativo (or aplicativo de primeiro plano). Um aplicativo se torna o aplicativo ativo sistema autônomo seguintes circunstâncias:

• Ele é lançado e exibe uma Window.

• Um usuário alterna de outro aplicativo selecionando uma Window no aplicativo.

Você pode detectar se um aplicativo se tornou ativo tratando o evento Application.Activated.

Da mesma forma, um aplicativo ser torna inativo nas seguintes circunstâncias:

• Um usuário alterna para outro aplicativo diferente do corrente.

• Quando o aplicativo finaliza.

Você pode detectar se um aplicativo se tornou inativo tratando o evento Application.Deactivated.

O código a seguir mostra como tratar os eventos Activated e Deactivated para determinar se um aplicativo está ativo.

<Application 
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App"
  StartupUri="MainWindow.xaml"
  Activated="App_Activated" 
  Deactivated="App_Deactivated" />

using System; // EventArgs
using System.Windows; // Application

namespace SDKSample
{
    public partial class App : Application
    {
        bool isApplicationActive;

        void App_Activated(object sender, EventArgs e)
        {
            // Application activated
            this.isApplicationActive = true;
        }

        void App_Deactivated(object sender, EventArgs e)
        {
            // Application deactivated
            this.isApplicationActive = false;
        }
    }
}

Uma Window também pode ser ativada e desativada. Consulte Window.Activated e Window.Deactivated para mais informações.

Observação:
Nem Application.Activated nem Application.Deactivated é gerado para XBAPs.

Finalização de Aplicativo

A vida de um aplicativo se encerra quando ele é finalizado, o que pode ocorrer pelos seguintes motivos:

• Um usuário fecha todas as Window.

• Um usuário fecha a Window principal.

• Um usuário encerra a sessão Windows fazendo logoff ou desligando.

• Uma condição específica do aplicativo é atendida.

Para ajudá-lo a gerenciar a finalização do aplicativo, Application fornece o método Shutdown, a propriedade ShutdownMode, e os eventos SessionEnding e Exit.

Observação:
Shutdown pode ser chamado somente de aplicativos que possuem UIPermission. Aplicativos WPF autônomos sempre possuem essa permissão. Entretanto, XBAPs rodando em modo de segurança de confiança parcial da zona de Internet não.

Modo de Finalização

A maioria dos aplicativos se encerra ou quando todas as janelas são fechadas ou quando a janela principal é fechada. Algumas vezes, entretanto, outras condições específicas do aplicativo podem determinar quando um aplicativo finaliza. Você pode especificar as condições sob as quais seu aplicativo irá finalizar definindo ShutdownMode com um dos seguintes valores da enumeração ShutdownMode.

• OnLastWindowClose

• OnMainWindowClose

• OnExplicitShutdown

O valor padrão do ShutdownMode é OnLastWindowClose, que significa que um aplicativo encerra automaticamente quando sua última janela é fechada pelo usuário. Entretanto, se o seu aplicativo deve ser finalizado quando a janela principal é fechada, WPF faz isso automaticamente se você definir ShutdownMode como OnMainWindowClose. Isto é mostrado no exemplo a seguir.

<Application
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.App"
    ShutdownMode="OnMainWindowClose" />

Quando você possui condições de finalização específicas do aplicativo, você define ShutdownMode como OnExplicitShutdown. Nesse caso, é sua responsabilidade finalizar um aplicativo chamando o método Shutdown explicitamente; de outra forma, seu aplicativo permanecerá executando mesmo que todas janelas sejam fechadas. Note que Shutdown é chamado implicitamente quando o ShutdownMode é tanto OnLastWindowClose como OnMainWindowClose.

Observação:
ShutdownMode pode ser definido de um XBAP porém ele é ignorado; um XBAP sempre encerra quando é navegado para fora em um navegador ou quando o navegador que hospeda o XBAP é fechado. Para obter mais informações, consulte Visão geral de navegação.

Encerramento de Sessão

As condições de finalização descritas pela propriedade ShutdownMode são específicas para um aplicativo. Em alguns casos, porém, um aplicativo pode finalizar como resultado de uma condição externa. A condição externa mais comum ocorre quando um usuário encerra a sessão Windows pelas seguintes ações:

• Fazendo logoff

• Desligando

• Reiniciando

• Hibernando

Para detectar quando uma sessão Windows se encerra, você pode tratar o evento SessionEnding, como ilustrado no exemplo a seguir.

<Application 
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.App"
    StartupUri="MainWindow.xaml"
    SessionEnding="App_SessionEnding" />

using System.Windows; // Application, SessionEndingCancelEventArgs, MessageBox, MessageBoxResult, MessageBoxButton

namespace SDKSample
{
    public partial class App : Application
    {
        void App_SessionEnding(object sender, SessionEndingCancelEventArgs e)
        {
            // Ask the user if they want to allow the session to end
            string msg = string.Format("{0}. End session?", e.ReasonSessionEnding);
            MessageBoxResult result = MessageBox.Show(msg, "Session Ending", MessageBoxButton.YesNo);

            // End session, if specified
            if (result == MessageBoxResult.No)
            {
                e.Cancel = true;
            }
        }
    }
}

Nesse exemplo, o código inspeciona a propriedade ReasonSessionEnding para determinar como a sessão Windows está encerrando. Ele usa este valor para exibir uma mensagem de confirmação ao usuário. Se o usuário não quiser que a sessão se encerre, o código define Cancel para true para impedir que a sessão Windows se encerre.

Observação:
SessionEnding não é disparado par XBAPs.

Exit

Quando um aplicativo finaliza, ele pode precisar fazer algum processamento final, como persistir o estado do aplicativo. Para essas situações, você pode tratar o evento Exit.

<Application
    xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.App"
    StartupUri="MainWindow.xaml" 
    Startup="App_Startup" 
    Exit="App_Exit">


...


</Application>

using System.Windows; // Application, StartupEventArgs
using System.IO; // StreamReader, FileMode
using System.IO.IsolatedStorage; // IsolatedStorageFile, IsolatedStorageFileStream

namespace SDKSample
{
    public partial class App : Application
    {
        string filename = "App.txt";

For the complete example, see Como: Persistir e Restaurar propriedades de escopo de aplicativos em sessões de aplicativos.

Exit pode ser tratada tanto por aplicativos autônomos como por XBAPs. Para XBAPs, Exit é disparada nas seguintes circunstâncias:

• Um XBAP é navegado para fora.

• No Internet Explorer 7, quando a guia que hospeda o XBAP é fechada.

• Quando o navegador é fechado.

Código de Saída

Aplicativos na maioria das vezes são lançados pelo sistema operacional em resposta a uma solicitação do usuário. Entretanto, um aplicativo pode ser lançado por outro aplicativo para desempenhar uma tarefa específica. Quando o aplicado lançado finaliza, o aplicativo que o lançou pode querer saber a condição sob a qual ele foi finalizou. Nessas situações, Windows permite aos aplicativos retornar um código de saída do aplicativo na finalização. Por padrão, aplicativos WPF retornam um código de saída de valor 0.

Observação:
Quando você depurar a partir de Visual Studio, o código de sair aplicativo é exibido na sair janela quando o aplicativo é desligado, em uma mensagem se parece com o seguinte: The program '[5340] AWPFApp.vshost.exe: Managed' has exited with code 0 (0x0). em em aberto o Saída janela clicando em Saída sobre o View menu.

Para modificar o código de saída, você pode chamar a sobrecarga Shutdown(Int32), que aceita um inteiro como argumento para ser o código de saída:

// Shutdown and return a non-default exit code
Application.Current.Shutdown(-1);

Você pode detectar o valor do código de retorno, e alterá-lo, tratando o evento Exit. O tratador do evento Exit é passado uma ExitEventArgs que fornece acesso ao código de saída com a propriedade ApplicationExitCode. Para obter mais informações, consulte Exit.

Observação:
Você pode conjunto o código de sair em ambos os aplicativos autônomos e XBAPs. Entretanto, o valor do código de saída é ignorado para XBAPs.

Exceções Não Tratadas

Algumas vezes um aplicativo pode finalizar sob condições anormais, como quando uma exceção não esperada é atirada. Nesse caso, o aplicativo pode não ter o código para detectar e processar a exceção. Esse tipo de exceção é uma exceção não tratada; uma notificação similar à exibida na figura abaixo é mostrada antes que a aplicação seja fechada.

Pela perspectiva da experiência do usuário, é melhor que um aplicativo evite esse comportamento padrão fazendo um ou todos os seguintes:

• Mostrar informações amigáveis ao usuário.

• Tentar manter o aplicativo rodando.

• Gravar informações detalhadas, amigáveis ao desenvolvedor, no log de eventos Windows.

Implementar esse suporte depende em ser capaz de detectar exceções não tratadas, que é o propósito do evento DispatcherUnhandledException ser lançado.

<Application
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App"
  StartupUri="MainWindow.xaml"
  DispatcherUnhandledException="App_DispatcherUnhandledException" />

using System.Windows; // Application
using System.Windows.Threading; // DispatcherUnhandledExceptionEventArgs

namespace SDKSample
{
    public partial class App : Application
    {
        void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
        {
            // Process unhandled exception


...


            // Prevent default unhandled exception processing
            e.Handled = true;
        }
    }
}

Observação:
Para obter um exemplo mais detalhado de como lidar com DispatcherUnhandledException, consulte Exemplo de exceções sem tratamento aplicativo.

O tratador de evento DispatcherUnhandledException é passado um parâmetro DispatcherUnhandledExceptionEventArgs que contém informações contextuais sobre a exceção não tratada, incluindo a exceção em si (DispatcherUnhandledExceptionEventArgs.Exception). Você pode usar essa informação para determinar como tratar a exceção.

Quando você trata DispatcherUnhandledException, você deve definir a propriedade DispatcherUnhandledExceptionEventArgs.Handled para true; de outra forma, o WPF ainda considera a exceção como não tratada e reverte para o comportamento padrão descrito anteriormente. Se uma exceção não tratada for disparada e nem o evento DispatcherUnhandledException for tratado, nem o evento tratado e o Handled definido para false, o aplicativo será finalizado imediatamente. Além disso, nenhum outro evento Application é lançado. Consequentemente, você precisa tratar DispatcherUnhandledException caso seu aplicativo tenha código que precisa executar antes do aplicativo finalizar.

Apesar de um aplicativo poder finalizar como resultado de uma exceção não tratada, um aplicativo geralmente finaliza em resposta uma solicitação do usuário como discutido na próxima seção.

Eventos do Tempo de Vida do Aplicativo

Aplicativos autônomos e XBAPs não tem exatamente o mesmas as vidas úteis. A figura a seguir ilustra os principais eventos em tempo de vida de um aplicativo autônomo e mostra a sequência em que são gerados.

Da mesma forma, a figura a seguir ilustra os eventos chave no tempo de vida de um XBAP, e mostra a sequência na qual eles são disparados.

Outros Serviços de Aplicativos

Além de gerenciar o tempo de vida de um aplicativo, Application fornece serviços que incluem os seguintes:

• Propriedades compartilhadas de escopo de aplicativo

• Recursos compartilhados de escopo de aplicativo.

• Recursos de aplicativo, conteúdo, e arquivos de site de origem.

• Gerenciamento de janela

• Gerenciamento de Navegação.

Propriedades Compartilhadas de Escopo de Aplicativo

Application fornece a propriedade Propertiespara expor estado que pode ser compartilhado entre a abrangência de um aplicativo. Segue um exemplo de utilização do Properties:

// Set an application-scope property with a custom type
CustomType customType = new CustomType();
Application.Current.Properties["CustomType"] = customType;


...


// Get an application-scope property
// NOTE: Need to convert since Application.Properties is a dictionary of System.Object
CustomType customType = (CustomType)Application.Current.Properties["CustomType"];

Consulte o seguinte para mais informações:

• Como: Get and Set Application-Scope Properties

• Como: Persistir e Restaurar propriedades de escopo de aplicativos em sessões de aplicativos

Recursos Compartilhados de Escopo de Aplicativo.

Application fornece a propriedade Resources para permitir aos desenvolvedores compartilharem recursos UI através de um aplicativo. Segue um exemplo de utilização do Properties:

// Set an application-scope resource
Application.Current.Resources["ApplicationScopeResource"] = Brushes.White;


...


// Get an application-scope resource
Brush whiteBrush = (Brush)Application.Current.Resources["ApplicationScopeResource"];

Consulte o seguinte para mais informações:

• TryFindResource

• FindResource

• Como: Get and Set Application-Scope Resources

• Visão geral sobre Recursos

Recursos de Aplicativo, Conteúdo, e Arquivos de Site de Origem.

Aplicativos WPF podem gerenciar diversos tipos de arquivos de dados não código, incluindo arquivos de recursos, arquivos de conteúdo, e arquivos de site de origem. Os seguintes métodos auxiliares podem ser usados para carregar estes tipos de arquivos de dados:

• GetResourceStream

• GetContentStream

• GetRemoteStream

Gerenciamento de janela

Application e Window possuem um relacionamento estreito. sistema autônomo você viu o ciclo de vida de um aplicativo pode depender o tempo de vida de suas janelas, conforme especificado pelo ShutdownMode propriedade. Application registros de janela em que é designada () a janela principal do aplicativoApplication.MainWindow) e mantém uma lista de janelas atualmente instanciados (Application.Windows).

Para obter mais informações, consulte Visão geral do WPF do Windows.

Gerenciamento de Navegação.

Para aplicativos autônomos com navegação (usando NavigationWindow e Frame) ou XBAPs, Application detecta qualquer navegação dentro de um aplicativo e dispara os seguintes eventos quando apropriado:

• Navigating

• Navigated

• NavigationProgress

• NavigationFailed

• NavigationStopped

• LoadCompleted

• FragmentNavigation

Além disso, Application fornece a habilidade para aplicativos de qualquer tipo criar, persistir, e recuperar cookies, usando GetCookie e SetCookie.

Para obter mais informações, consulte Visão geral de navegação.

Consulte também

Conceitos

Visão geral do WPF do Windows

Visão geral de navegação

Arquivos de Recurso, Conteúdo e Dados de Aplicações Windows Presentation Foundation

Referência

Application

Date	History	Motivo
Julho de 2008	Adicionada a seção sobre o uso de uma tela inicial de abertura.	Alteração de recurso do SP1.