When a UJML application is started, its compiled byte code file is loaded into device memory by the UJML player and its top-level script and display elements are executed. See Application Files, Byte Code Files, Running Files, Scripting. The UJML source may not be executed directly.

A compiled UJML byte code file is a single 'module' of executable byte code. These modules come in three types: application, partition, and component, based on the type of UJML file which they were compiled from. See Application Files, Partition Files, Component Files. 

When an application module is first started it must be the only module currently loaded by the UJML player. An application module may then run other applications, which entails unloading the current application and loading a new one. See Running Files. UJML provides facilities to run applications, stop applications, and for applications to automatically restart when an application they previously ran has stopped itself. 

Partition modules may not be run directly. Instead they are loaded into memory and unloaded from memory on request of the current application in a process called 'linking'. See Linking Files. Linked partition modules may share variables, functions, and other identifiers with the parent module which linked them. 

Application files and partition files may also include code from other files at the compilation stage, before the byte code modules are generated. See Including Files. This process can only occur at compile time and is not dynamic in the sense that linking files is.

The scripting code in a module's top-level script and display elements represents the 'startup' code for the module and is executed by UJML immediately after the module has been loaded into memory. 

This startup code may call functions, change variable values, and set state variables, causing state transitions to occur. See Data, State Transitions. Visual elements may also contain their own scripting code, which is executed when the visual element is displayed. See Visual Elements. Once all scripting code in the startup execution path has executed, the UJML program 'idles' and waits for events to occur. See Execution Order. 

Event handlers may be declared in different contexts to catch specific events. See Handling Events. As events occur, scripting code in the events is executed, possibly changing the application state and kicking off a new round of script execution. 

All this continues until the module unloads itself or, in the case of a partition module, is unloaded by its parent. If the module is a partition, it is unloaded from memory and the application continues to handle events. If the module is an application, UJML fires the UNLOAD event. See UNLOAD event. If the application module or any loaded partition contains an UNLOAD event handler, any script in the handler is executed once and the application (including all partitions) is then unloaded from memory. 

Note: The UNLOAD event may only be captured by one event handler. If multiple handlers are declared for the UNLOAD event, then only the handler with the top-most z-order will be fired.

Application Files, Byte Code Files, Running Files, Data, State Transitions, Scripting, Visual Elements, Handling Events, UNLOAD Event