Sometimes in our applications, we need to change the flow of execution. Suppose we have a "wizard" inside our application, the user should not be able to go back to the different steps of the "wizard" as (s)he moves forward. In order to accomplish this, GeneXus provides a variety of events to manage the application flow, among which is the Back event.
Back event is a system event which defines an action to be performed when the back button is pressed. It is commonly used to change back button behavior or prompt a confirm dialog before calling the previous panel.
- In iOS, the body of the Back event is restricted to:
1) Leaving it empty for disabling the back button.
2) Filling it with the Return command only (available as of GeneXus 15 Upgrade 5).
The reason for this limitation is that Apple does not allow the developer to change the default behavior of a back action (e.g. display a message after back).
- In iOS, when a UI object is called with CallOption.Target = 'Blank', ensure that the object does not contain an action on the top-left side of the Application Bar (i.e. Position property = Custom (iOS) and top-left alignment) because in that place will be positioned the back button(1). If the developer situates a custom button in that place, the back button (and its swipe right gesture) will be disabled and it is the responsibility of the developer to implement the "back action" when it is desired.
(1) By default as of GeneXus 15 Upgrade 5, previous versions do not display such button.
Warning: All examples work as described in Android, but only examples 1) and 2) work in iOS (due to the limitations stated above).
1) Disable the back button.
2) Change the default behavior of the back action by using the return command.
3) Display a confirm dialog before canceling the action.
Confirm("Are you sure you want to return?")
4) Call a Panel for Smart Devices on Back.
- If you are trying to skip panels that had been already done on a wizard, it is recommended to use CallOptions.Type = Replace on the caller, instead of calling a panel on the back event. With that you optimize the usage of the application stack, replacing old panels with new ones when navigating through the application.
- When the Back event is not implemented, on each platform it behaves by default as an execution of the SDActions.Cancel() method. In such case, the subsequent code of the caller object won't be executed.
- In contrast to the above point, if the Back event is implemented by using the Return command, the subsequent code of the caller object will be executed. For example, suppose we have two panels, A and B, and the panel A calls to the panel B as follows.
Event 'Call_B' //
// ... do something before calling B
msg("After calling B")
// ... do something else after calling B
If there is no Back event implemented on B or it is implemented by using the SDActions.Cancel() method, the message after the calling will not be executed. But if the Back event is implemented by using the Return command, the message will be displayed on the A panel.