Each of the activities listed in the previous section Application Designer Session - Application Designer Subsessions is represented by a subsession on the server side. Each subsession itself is holding the adapters for the activity.
In the diagram above, the activity "Address Management" is shown in detail. It consists of several pages between which the user navigates. Each page belongs to one adapter of a certain class. The adapter instances are managed inside the subsession.
The general rules for administering adapter instances are:
For each adapter class, there is one instance inside one subsession. This means: if you have several different pages between which you navigate inside one activity, and all pages are bound to the same Adapter class, then all pages are working with the same server side adapter instance.
Adapter instances start to live when they are first accessed (e.g. by a page requesting them). They are kept as instances for the whole life cycle of a subsession - if not explicitly destroyed by the application via an API call.
Basically, there are two types of sessions:
Each browser connected to Application Designer opens a new session inside the server. When closing the browser or navigating to another web page, this session is automatically destroyed at the server side.
Within a session there are subsessions. Each subsession represents the state of one interaction process inside the browser. In the Application Designer workplace environment, you can open multiple parallel interaction processes, and you can switch from one to another. You may have other environments in which you do not want to offer the multi-interaction process management - and only have one subsession for the whole life cycle of a session.
Inside a subsession, the adapter instances are created. All navigation is done between pages that belong to the same subsession. See also Working with Page Navigation.
