#18 CALL SCREEN, LEAVE SCREEN ​

Module pools had a call stack of screens. CALL SCREEN 200 pushed one, LEAVE TO SCREEN 0 popped it, and the screen underneath came back with its fields intact. It was one of those mechanisms nobody praised because nobody noticed it working.

abap2UI5 has the same stack. The elements on it are app instances.

Within one class there is no stack to speak of. A flag or a step number decides which view view_display( ) builds, and the event handlers move it along. Two views over the same internal table are two branches of one class, and that is the right shape whenever the screens share their data — no navigation, no handover, nothing to serialize twice.

Between classes the framework keeps the stack:

    " push: the called app takes the screen, this instance waits underneath
    client->nav_app_call( NEW zcl_app_detail( order_id = order_id ) ).

    " pop: back to the caller, which is called again with check_on_navigated( )
    client->nav_app_leave( ).

The caller gets main( ) called again, check_on_navigated( ) is true, and its own attributes are still there — the instance was serialized while it waited. What it has to do is show its view again, because the browser is still displaying the sub-app's. And it can read what the sub-app left behind:

    WHEN client->check_on_navigated( ).
      DATA(detail) = CAST zcl_app_detail( client->get_app_prev( ) ).
      IF detail IS BOUND.
        message = detail->result.
      ENDIF.
      view_display( ).

Note what that CAST implies: the result is not a string in a parameter table, it is the sub-app instance itself, with all its typed attributes. Returning a whole object from a screen is a luxury CALL SCREEN never had.

nav_app_leave( ) called with an app instance is LEAVE TO TRANSACTION: it starts the given app without pushing the current one, so there is nothing to return to.

A popup is the same thing in a smaller slot. popup_display( ) takes a fragment instead of a view, popup_destroy( ) closes it, and everything in between is ordinary binding — the popup's inputs are attributes of the same class. For a popup that is used from several apps, make it a class of its own: an ordinary z2ui5_if_app that displays into the popup slot, and ends with nav_app_leave( ). The caller reads the result through get_app_prev( ), as above.

What is not on the stack: the Fiori Launchpad. Navigating between Fiori apps goes through the launchpad's cross-app navigation, so that the shell's history and back button keep working — that is a cs_event constant rather than a nav_app_call( ), and its own page.

The stack came along. Its elements are instances now, not screen numbers.