First impressions are important, and a key criterion for any user is the time it takes to load an application. Startup time is regarded as overhead. It also sets an expectation of future performance. When a business uses thin-client technologies, the required additional overhead of loading client code may have a negative impact on users. Therefore, it is important to minimize load time wherever possible.

After requesting an Oracle Forms application, several steps must be completed before the application is ready for use:

1. Invoke Java Virtual Machine (JVM).
2. Load all initial Java client classes, and authenticate security of classes.
3. Display splash screen.
4. Initialize form:
   1. Load additional Java classes, as required.
   2. Authenticate security of classes.
   3. Render boilerplate objects and images.
   4. Render all elements on the initial screen.
5. Remove splash screen.
6. Form is ready for use.

An application developer has little influence on the time it takes to launch the JVM. However, the Java deployment model and the structure of the Oracle Forms Developer Java client allow the developer to decide which Java classes to load and how. This, in turn, minimizes the load time required for Java classes.

The Java client requires a core set of classes for basic functionality (such as opening a window) and additional classes for specific display objects (such as LOV items). These classes must initially reside on the server. See Using Java Files for more information about how to improve the time it takes to load these classes into the client's JVM.

The developer can design the application to maximize the data stream compression, called message-diffing, that Forms automatically performs. This means that Forms sends along data stream compression by using message diff-ing, which sends along only the information that differs from one message to another. The following steps can be taken to reduce the differences between messages:

• Promote similarities between objects. Using similar objects improves message diff-ing effectiveness (in addition to being more visually appealing to the user). The following steps encourage consistency between objects:
  • Accept default values for properties, and change only those attributes needed for the object.
  • Use Smart Classes to describe groups of objects.
  • Lock the look-and-feel into a small number of visual attributes.
• Reduce the use of boilerplate text. As a developer, you should use the PROMPT item property rather than boilerplate text wherever applicable. Forms Developer 6.0 and higher includes the Associate Prompt feature, which allows boilerplate text to be re-designated as the prompt for a given item.
• Reduce the use of boilerplate items (such as arcs, circles, and polygons). All boilerplate items for a given form are loaded at form initialization. Boilerplate items take time to load and use resources on the client whether they are displayed or not. Common boilerplate items, namely rectangles and lines, are optimized. Therefore, restricting the application to these basic boilerplate items reduces network bandwidth and client resources while improving startup times.
• Keep navigation to a minimum. An Event Bundle is sent each time a navigation event finishes, whether the navigation extends over two objects or many more. Design forms that do not require the user to navigate through fields when default values are being accepted. A form should encourage the user to quickly exit once the form is complete, which causes all additional navigation events to fire as one Event Bundle.
• Reduce the time to draw the initial screen. Once the Java client has loaded the required classes, it must load and initialize all of the objects to be displayed before it can display the initial screen. By keeping the number of items to a minimum, the initial screen is populated and displayed to the user more promptly. Techniques that reduce the time to draw the initial screen include:
  • Providing a login screen for the application with a restricted set of objects (such as a title, small logo, username, and password).
  • On the form's initial display, hiding elements not immediately required. Use the canvas properties:

    RAISE ON ENTRY = YES (Canvas only)

    VISIBLE = NO

    Pay attention to TAB canvases that consist of several sheets where only one will ever be displayed. For responsive switching between tabs, all items for all sheets on the canvas are loaded, including those that are hidden behind the initial tab. Consequently, the time taken to load and initialize a TAB canvas is related to all objects on the canvas and not just to those initially visible.

    Tip:

    When using Tab canvases, use stacked canvases and display the right canvas in the when-tab-page-changed trigger. Remember to set the properties RAISE ON ENTRY = YES and VISIBLE = NO for all the canvases not displayed in the first screen.
• Disable MENU_BUFFERING. By default, MENU_BUFFERING is set to True. This means that changes to a menu are buffered for a future "synchronize" event when the altered menu is re-transmitted in full. (Most applications make either many simultaneous changes to a menu or none at all. Therefore, sending the entire menu at once is the most efficient method of updating the menu on the client.) However, a given application may make only minimal changes to a menu. In this case, it may be more efficient to send each change as it happens. You can achieve this using the statement:

  Set_Application_Property (MENU_BUFFERING, 'false');

• Menu buffering applies only to the menu properties of LABEL, ICON, VISIBLE, and CHECKED. An ENABLE/DISABLE event is always sent and does not entail the retransmission of an entire menu.