Lesson 7: Loading and Unloading applications

UJML applications can be thought of as residing on a stack. The earliest launched application lives at the lowest stack position and the most recently launched application lives at the top of the stack. This lesson will discuss the methods for launching applications.

A UJML application is the code between the or tags in a file with a .ujml extension. The compiler looks for *.ujml to determine the application source files, so every application must conform to those requirements.

Practically, there is no difference between code contained in an tag and code contained in a tag. Conceptually, an is a standalone application that is _run() while a is a smaller part of a larger application that is _link()ed to the parent application. In practice, there is no difference except in name. As a rule of thumb, I use in my startup application file while I use in all other files.

There are three ways to launch an application from within another application. The first is the easiest, but affords the least control over the startup parameters. To launch another application, call _run(appURL). Use the URL to your application as the parameter to this API. When this is called, the launched application takes the top position in the stack and also takes the topmost position in the Z-order.

Applications that are launched with _run() control their own lifetime. They can exit and return control to the owning application by calling _unloadSelf().

The second type of application activation is the _link() API. This has two advantages over _run(). First, it provides a way to give a name to the application. This is useful because it means that the launching application can _unlink() the partition explicitly. In the _run() case, the launching application must wait for the _run() application to _unloadSelf() itself. The other benefit is that _link() allows the launching application to set the Z-order of the _link()ed partition. Depending on how the whole application is designed, it may be useful to load certain partitions higher or lower in the Z-order. A pop-up screen (like a notification) would need a very high Z-order while a resource loader could use a lower Z-order. Leaving off the Z-order value in the call will cause the application to be loaded above the launching application.

A _link()ed partition may call _unloadSelf() to remove itself from the application stack, but the more typical method is by using the _unlink() API. The string parameter passed to _unlink() is the name that was passed as the first parameter to _link().

Be careful with the naming, though. If the same partition name is used for than once, the first _link()ed partition will be automatically _unlink()ed to make room for the next partition.

The third type of application launch is _replace(). This is a relatively minor API compared to _link() or _run(). It has most of the same characteristics of _run(), but instead of loading the application at the next open stack position, it implicitly _unlink()s the current application and _link()s the new one at that position. I have not found this API to be of any use, personally.

Although the UJML documentation says that the launching application is de-activated, it is actually suppressed in the Z-order. If an event comes in and the topmost application does not handle it, the event will trickle down the application stack until a handler is found or it reaches the bottom of the stack. Be sure that no unwanted event handlers are active when launching an application.

By effectively using the application stack, it is possible to write multi-featured applications in a small space since you can _link() and _unlink() necessary components on the fly.