Best Build Fiori Apps Rule 7: Always use intent-based navigation to navigate within an app and between apps
At lot of people start developing own SAP Fiori Apps, but missing the programming guidelines to build a future proof applications for the Fiori Launchpad. At the SAP Teched 2015 in Las Vegas and Barcelona I presented my 10 golden rules to build future proof freestyle Fiori Applications based on UI5 SDK 1.28 and higher. In this series I will explain the background of the rules starting with the first golden rule:
Golden Rule 7: Always use intent-based navigation to navigate within an app and between apps
Fiori Launchpad allows users to launch applications in a different views or modes depending on its parameters. Fiori launchpad makes use of semantic objects and actions, so called intents, which are customized as targets and mapped at runtime to the actual urls of the target application. This mechanism is called intent-based navigation and allows you to decouple the navigation triggers from the actual navigation targets.
This allow you to start with the same Tile in the Fiori Launchpad different applications based device the user is uses or based on the role of the user has. If there isn’t a valid target available, the Launchpad will not show the Tile.
Intent-based Navigation to different apps based on device or role (source: help.sap.com)
Intent-base navigation also will help to develop applications separately with their own lifecycle. By calling the intent, it is possible to navigate between apps, without they know each other. By using the same concept for inner-app navigation, meaning changing pages using the SAPUI5 routing control. It is even possible to store the state of the app (as a new tile) or share this it with others users using email or social media by sharing a url.
Actually this means that the UI5 app behind the Fiori Launchpad will recognize the target app by using and analyzing the query string of the url. For this hash-based routing concept is introduced in SAPUI5. The shell part of the query string behind the hash tag (#) will be translated into intent (Semantic Object-Action) and its parameters. Fiori Launchpad app will analyze the intent and uses the target mapping to find the correct Fiori Application and will load the component with the cross-app navigation parameters.
Hash-based routing in Fiori Launchpad (source: help.sap.com)
Based on app-specific part of the query string, the UI5 routing object will recognition a parameter pattern for the inner-app navigation and starts the app with the right screen and data. If someone doesn’t have authorization and the right target mappings for application in its Fiori Launchpad, the url is useless on its own.
The behavior for the Fiori Launchpad is developed by SAP, so we only have to look what’s needed for our Fiori App and the answer is simple:
— You should implement the cross-app navigation and inner-app routing concept of UI5 —
The first step is to choose the right template for your application. This can be a Fiori Freestyle template like Full Page or Master-Detail or a Fiori Smart Template like overview pages (OVP). Based on the template you have to setup your routing into the metadata configuration. You specify the routing configuration like router class, view type and entry path, control id and aggregations and the transition animation type during the navigation. Next you have to specify the views and its level in the application as targets. These targets will be used for inner-app navigation using the navTo method of the router component. By setting up the routes in the metadata configuration, you also create different entry point of your application. The pattern in the hash-based routing will be recognized as route in the application and the component controller will load the correct pages. By adding a dynamic part to the route, you can even persist data in the query string, which can be analyzed by the target view.
When using the wizards of WebIDE to generate your freestyle Fiori applications, you will get a default setup for your routing. It will generate the right setup for the routing in metadata of app descriptor (manifest.json in UI5 SDK 1.30 and higher) or the component controller (component.js in UI) itself. The wizard will also generate the views including views for error handling. It also will add the getRouter() method for referencing the sap.ui.core.routing.Router object and onNavBack() method as event handler for the browser back button to the base controller (base.controller.js). The wizard will add the event handler for the router matching in the init() method of every view controllers.
Routing in App Descriptor using the Descriptor Editor (source: sap WebIDE 1.19.6)
This router matching event handler is very important for the hash-based routing concept and crucial for cross-app navigation. Based on the patterns of the routes, this event handler must analyze the route url and use its parameters to reset the state of the application.
For cross-app navigation, you can also use the Cross Application Navigation service of the Fiori Launchpad. This is an instance of the sap.ushell.services.CrossApplicationNavigation object. By calling this service, the app can dynamically pass parameters to another application and back. The called application can receive the parameters as startup parameters of component controller. In the app descriptor of an application you can customize the proposed intent and its parameters.
Customizing of the proposed intent in App Descriptor using the Descriptor Editor (source: sap WebIDE 1.19.6)
Keep in mind that the query string of the hash-based navigation will be exchanged with the server and cached in the browser cache. So you should prevent to use privacy data in your hash. So for security reason, its better that you only use a minimum set of keys (if possible without context like guids). As alternative for inner-app navigation, you can use the component controller to exchange data between views.
A Fiori Overview Page don’t have views and in this case in stead of the routes you need to customize the cards in the sap.ovp section of the app descriptor, if you want to show on the overview page.
If you want to learn more about routing in UI5, please look at the tutorial in the documentation of the UI5 SDK. The routing concept is very important to understand and key for the viewport concept of Fiori 2.0, the successor of the Fiori Launchpad.
In my next blog I will explain rule 8, Use only the newest UI5 OData Model (v2) to access one OData Service node of the back-end. An overview of all 10 golden rules can be found here.