The normal way in which ULC uses resources is to cache and reuse them on the ULC and UI side. This means for example that if you close a shell it is only hidden and kept in a cache (together with its children). If the programmer reuses the same shell a lot of times then only the data needs to be transferred to the UI Engine because the shell proxy (together with its children) is still there. The resources of the shell and its children are destroyed only when the application gets terminated or the associated connection goes down. This scenario is optimized for network traffic.
In applications where resources are not reused (or cannot be reused) the memory consumption on both UI and ULC side can be very large. ULC offers two solutions to this problem which are described here.
The programmer can set the destroyOnClose flag on each ULC shell which defines if a shell together with all its children is destroyed or cached (default). Setting this flag to
true will free the resources on the UI and the ULC side when the shell is closed.
You can set destroyOnClose flag in the properties view of a shell or directly in the code.
Note: When setting this flag to true the developer has to make sure that the receiver and all of its children are no longer used anywhere. For example if you set the flag to
true then you can no longer use show after you have hidden/closed the shell, since the resources have already been freed.
In applications where shells stay alive for a long time and inside the shells resources are dynamically changed (e.g. with a pagebook or notebook, or by dynamically adding / removing widgets), the destroyOnClose flag will not help very much. In order to give finer grained control to the programmer we have added a release API in ULC R3.0a which allows the developer to explicitly free any ULC object on demand by sending
release to this object. Sending
release frees the resources of the receiver on the ULC side and sends a request to the UI side to free the resources of the corresponding UI object.
Note: When releasing a ULC object the developer has to make sure that this object and all of its children are no longer used anywhere. For example if you release a ULC model that is still used by other ULC objects then your application will be in an inconsistent state and if a widget tries to use the model on the UI side it will not work correctly and may throw exceptions or even crash. In general the use of the release API should be restricted to only cases where it is absolutely necessary since releasing widgets/models requires the developer to be aware of all places within the application where the widget/model is being used and this can in some cases be error prone.