Soyatec - Open Solution Company: XAML for Java, UML for Eclipse and BPMN designer

eFace is the Worldwide First XAML solution for Java. It provides an unified programming model for building both rich client application and RIA. It keeps insulation for applications from the technology/environment change such as Swing, SWT or Web/Ajax.

Application Management Overview

 

This topic provides an overview of these services, starting with an introduction to the Application class, how to define an application, application lifetime, and the additional services provided by Application.

This topic contains the following sections.

The Application Class

In eFace, an application is encapsulated by the Application class. The Application provides the following fundamental services:

 

Implementing an Application

A typical eFace application is defined using both markup and corresponding java code. This allows you to use markup to declaratively set application properties, resources, and register events, while handling the events and implementing application-specific behavior in corresponding java code. The following example show how to define an application using both markup and java code.

xaml:

<Application

   x:Class="userguide.App"

   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">

   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

</Application>

Java code:

public class App extends Window {

}

To allow a markup file and java code file to work together, the following needs to happen.

 

Application Lifetime

When an application starts, and may be deactivated and activated many times during its lifetime before it finally stops running in response to either user or programmatic conditions.

Starting an Application
When an Application starts, it establishes a set of infrastructure that is commonly required by all applications. When the infrastructure is in place, Application raises the Startup event, which signifies the moment when an eFace application has started:

xaml:

<Application

   x:Class="userguide.App"

   xmlns:java="clr-namespace:userguide"

   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

   Startup="Startup">

</Application>

Java code:

public class App extends Window {

   public void Startup(Object sender, RoutedEventArgs eventArgs) {

   }

}

Showing a User Interface
Because most Windows applications open a user interface when they begin running the Startup event handler is an ideal location to do so. For standalone applications, this involves showing a window:

public class App extends Window {

   public void Startup(Object sender, RoutedEventArgs eventArgs) {

      MainWindow mianWindow = new MainWindow();

      mainWindow.show();

   }

}

It is possible to set the MainWindow property from XAML, if the only reason you handle Startup is to show a window, you can set the StartupUri attribute in markup instead.

<Application

   x:Class="userguide.App"

   xmlns:java="clr-namespace:userguide"

   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

   StartupUri="MainWindow.xaml">

</Application>

Application can also create an instance of NavigationWindow and navigates it to the specified page. You could also set StartupUri with a custom NavigationWindow.
With respect to showing a UI, the main reason that you need to handle Startup, instead of setting StartupUri, is to instantiate the class that implements the UI by using a non-default constructor, or to set properties on it before showing it.
You will also need to handle Startup to retrieve and process the command-line arguments for your application.

Application Activation and Deactivation
During the lifetime of an application, users may switch between them and other applications that they may currently have running. A user switches to another application by activating one of its windows, at which point the current application becomes deactivated. This situation can be detected by handling Deactivated. Likewise, when a user switches back to the application by selecting one of its windows, the application activates and, consequently, Activated is raised. Both Activated and Deactivated can be handled like os:

xaml:

<Application

   x:Class="userguide.App"

   xmlns:java="clr-namespace:userguide"

     xmln ="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    StartupUri="MainWindow.xaml"

    Activated="Activated"

   Deactivated="Deactivated">

</Application>

Java Code:

 public class App extends Window {

      boolean isApplicationActive;

      public void Activated(Object sender, RoutedEventArgs eventArgs) {

             this.isApplicationActive = true;

  }

      public void Deactivated(Object sender, RoutedEventArgs eventArgs) {

          this.isApplicationActive = false;

       }

}

 

Unhandled Exception
While an application is running, application code may thrown an exception that is unanticipated and potentially, unhandled.
From the user experience perspective, it is better for an application to avoid the default behavior by doing some or all of the following:

xaml:

 <Application x:Class="userguide.App"

   xmlns:java="clr-namespace:userguide"

   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   DispatcherUnhandledException="DispatcherUnhandledException"

   Startup="Startup" >

</Application>

 

Java Code:

 public class App extends Window {

   public void DispatcherUnhandledException(Object sender,

        RoutedEventArgs eventArgs) {

      // Process unhandled exception

      // Prevent default unhandled exception processing

   }

}

 

Application Shutdown
When an unhandled exception occurs, the application will shut down if the exception remains unhandled. An application is far more likely to be shut down, though, for the following reasons:

In all these cases, the Shutdown method is called. Whether Shutdown is called by you or eFacedepends on how you configure Application.

Shutdown Mode
In general, the lifetime of a standalone application encapsulates the lifetime of the windows that it shows. Depending on the type of application, the application will shutdown when either all the windows are closed, or when the main window is closed. Because these two scenarios are the most common, you can configure Application to automatically shut down when they happen by setting ShutdownMode to one of the following ShutdownMode enumeration values:

For example, if you wanted to configure your application to shut down when the main window has closed, you would do the following:

 <Application

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    ShutdownMode="OnMainWindowClose"

    Startup="Startup">

</Application>

 

Setting ShutdownMode specifies when Shutdown is called, and by who. When ShutdownMode is set to either OnLastWindowClose or OnMainWindowClose, eFace will automatically call Shutdown when either of the conditions specified by these enumeration values is set.
If ShutdownMode is set to OnExplicitShutdown, it is your responsibility to call Shutdown, otherwise your application will continue running even if all the windows are closed.

Session Ending
Whereas setting ShutdownMode is an internal mechanism for shutting an application down, applications can also shutdown due to external conditions:

When a user ends their session, Windows gives the opportunity for each currently running application to detect when they do and, if required, prevent the session from ending. Applications that allow users to edit data are most likely to take advantage of this capability. Consequently, applications can use this opportunity to check that their application data is saved and, if not, give the user the opportunity to prevent Windows from shutting down.
Application detects when Windows raises the session ending notification and raises the SessionEnding event when it happens. You can handle SessionEnding to detect, respond to, and cancel session ending, as shown in the following example:
xaml:

 <Application

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    SessionEnding="SessionEnding"

    Startup="Startup">

</Application>

 

Java Code:

public class App extends Window {

public void SessionEnding(Object sender, RoutedEventArgs eventArgs) {

          ...

        //Ask the user if they want the session to end.

         MessageBox.Show("The application is shutting down.", "An Application",

         MessageBoxButton.YesNoCancel, MessageBoxImage.Question,

         MessageBoxResult.Cancel, MessageBoxOptions.RtlReading);

         // If they don’t, prevent both the session from ending and

         // the  application from shutting down.

   }

}

 

Exit
If shutdown is initiated by an application - that is, does not shut down due to unhandled exceptions or when the user session ends - the lifetime of an application will end. Before ending, applications may need to perform final processing such as persisting application state. For these situations, you can handle the Exit event.

XAML:

 <Application

    x:Class="com.soyatec.databinding.ApplicationTest"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Exit="App_Exit" >

     ...

</Application>

 

Java:

 public void App_Exit(Object sender, RoutedEventArgs eventArgs) {

      // you can write the code you perform final processing here.

}

 

Exit Code
Applications are mostly launched by the operating system in response to a user request. However, an application can be launched by another application to perform some specific task. In this case, both calling and called applications operate in separate processes. One issue with this situation occurs when the calling application’s execution depends on how the called application terminated. In these situations, the called application can return a value that indicates how it terminated by using a special integer code known as the exit code. By default, Application will return a default exit code value of 0. To change this value, you can call an overload of Shutdown that accepts an integer argument to be the exit code:

Java:

  //Shutdown and return a custom exit code

 application.getCurrent().shutdown(-1);

 

You can detect the value of the exit code, and change it, by handling the Exit event. The Exit event handler is passed an ExitEventArgs which provides ccess to the exit code with the ApplicationExitCode property.

Application Lifetime Events
The following figure illustrates the key events in the lifetime of an application, and the sequence in which they are raised.

 

 

 

Application and Windows
Application and Window have a close relationship. As you've seen, the lifetime of an application can depend on the lifetime of its windows, as specified by the ShutdownMode property. Application records which window is designated the main application window, and maintains a list of currently instantiated windows.

Application and Navigation
For standalone applications with navigation, using NavigationWindow and Frame or Application detects any navigation within an application and raises the following events as appropriate: