# Configuring Applications

Applications are configured on the [Screens & and actions step](screensAndActions.md).

The top-level nodes represent the different applications that can be configured for the project. There are three types of applications:

- **Installer** — The installer is the application that is executed when the media file is invoked by the user, for example, when the user double-clicks on the installer executable in the Windows explorer. The installer cannot be deleted from the tree of installer elements.
- **Uninstaller** — The uninstaller is a special application for uninstalling an installation. It is used in various contexts and can be   directly invoked by the user invoked from the Windows software registry invoked by the "Uninstall previous installation" action   The uninstaller cannot be deleted from the tree of installer elements. If you do not wish to generate an uninstaller, you can [disable it](screensAndActions.md#disable).
- **Custom installer application** — You can add any number of custom installer applications that can be invoked after the installation. install4j comes with several templates for [auto-updater downloaders](../concepts/autoUpdate.md). Custom applications can also be used for writing maintenance applications for your installation.  You can add a new custom installer application by clicking on the ![](../images/add.svg) `Add` button on the right side of the list and choosing Add Application from the popup. The application templates dialog will be displayed and lets you choose a starting point for your custom installer application. Application templates are entirely made up of existing screens, actions and form components. You can modify the selected application template after adding it.   Unlike the installer and uninstaller above, custom applications are also created for [archive media files](../concepts/mediaFiles.md#archives). See the [help topic on media files](../concepts/mediaFiles.md) for more information on how to create first-run installers for archives.   Custom installer applications with a non-empty "Executable directory" property are automatically added to the "Default file set". If you leave the executable directory empty, the custom installer application is added to the `.install4j` directory and will always be included, regardless of the installation component configuration.

Each installer application has a **startup sequence** of [actions](actions.md). Those actions are executed before the installer application presents a user interface. If any of these actions fails and has a "Quit on failure" failure strategy, the installer application will not be shown.

### Properties of installer applications

Common properties of installer applications are:

_See `reference/beans/` for the bean catalog._

Custom applications as well as the uninstaller are added to the distribution tree and have additional related properties:

_See `reference/beans/` for the bean catalog._

The remaining properties that are specific to the installer are:

_See `reference/beans/` for the bean catalog._

Finally, custom installer applications have the following additional properties:

_See `reference/beans/` for the bean catalog._

### Configuring installer variables

The second tab in the configuration area for installer applications is the **Installer variables** tab. Here, you can check the bindings for all detected installer variables and pre-define installer variables. For more information, see the [help topic on variables](../concepts/variables.md).

![](../images/ui/beans_installer_variables.png)

An additional feature with respect to the variable selection dialog is that you can navigate to a binding by selecting an element in the binding tree at the bottom and click on the `Go To Selection` button.

### Launcher integrations

Custom installer applications have a **Launcher integrations** tab in the configuration area that helps you to start them when launchers are executed.

![](../images/ui/beans_launcher_integration.png)

One way to start an installer application is programmatically, by using the [install4j API](../api/installer.md). To get the code snippet for starting the selected installer application, click on the `Start integration wizard` button. The integration wizard will present a number of options that control the condition and possible callbacks from the installer application.

Another way to start an installer application is automatically, by defining a **launch schedule** and a **launch mode**. The launch schedule is one of

- **Always** — Every time you start the launcher, the installer application will be started as well.
- **According to update schedule** — install4j provides a built-in update schedule registry that can be configured by the user on a form screen with an "Update schedule selector" form component. Also, you can programatically modify the update schedule through the class `com.install4j.api.update.UpdateScheduleRegistry` in the API. The selected installer application will be started only if the update schedule requires an update check.
- **First run of any launcher in archive media file by the current user** — For archive media files (such as a Windows ZIP file), no installer is available. To execute a sequence of screens and actions when a launcher is started for the first time after the archive has been extracted, use this launch schedule. It may be convenient to link to screen groups in the installer to avoid duplicating configuration in your custom installer application.   In your launcher, you can check for this condition with   com.install4j.api.launcher.ApplicationLauncher.isNewArchiveInstallation()   in case you want to perform some actions outside a custom installer application.

The launch mode is one of

- **Blocking at start up** — When the launcher is started, the selected installer application will be started first. When the installer application terminates, the launcher will then start up, unless a "Shut down calling launcher" action has been executed.
- **Non-blocking at start up** — When the launcher is started, the selected installer application will be started immediately. The launcher continues to start up in parallel.
- **When first window is shown** — The selected installer application will be started when the first window is shown. This works for AWT, Swing and SWT applications. If you have an SWT application, the "Uses SWT" check box in the "Executable info" step of the [launcher wizard](../concepts/launchers.md) must be selected.

Just like with the API, the installer application can be started in the launcher process itself or in a new process. By default, the installer application is started in the same process. If the "Blocking at start up" or "Non-blocking at start up" launch modes are selected, the look and feel is set to the system look and feel. For the "When first window is shown" launch mode, the look and feel is not changed, so your own look and feel will be used. When the installer application is executed in the same process, the "Shutdown calling launcher" action has a different effect: The whole process will be terminated when the installer application exits.

By default, the selected installer application is started for all launchers in your project. If this is not desired, you can restrict the integration to selected launchers. Note that if "All launchers" is selected and the project is merged into another project, the integration will be performed for all launchers in the main project as well.
