Enabling the Automatic SAP Fiori 2.0 Header Adaptation in the App Descriptor

Fiori 2.0 Adaptation

With Fiori 2.0, SAP has brings the Fiori Launchpad many features. One feature help saving space (on small devices like phones). This help document instructs developer how to make the Fiori application’s header to be merged & adapted with the Fiori launchpad header.

The pain points I’ve got when following that Help document is that… it’s not always working. Unfortunately, the document hasn’t explained details about the problem & solution you may encounter. That’s why I create this post to keep track of the solution.

The prerequisite checklist:

If the adaptation does not work for you, make sure you have gone through below checklist:

• Your Fiori launchpad is upgraded to 2.0
• You had already followed all steps in the help document to allow Fiori 2.0 Adaptation.
• You use them template from Web IDE library (not created by your own).

What if this adaptation does not work?

Since SAPUI5 version 1.56, the template has been redesigned (they call it “innovation” template) with new look and feel, which eliminate the header bar of the master & detail view, so the Fiori 2.0 Header adaptation is not really necessary anymore.

With SAPUI5 version lower than 1.44, the Fiori 2.0 Header adaptation work well, if you create the project using the template.

Version 1.52 still use the old design with the header bar floorplan. But it does not work with the Fiori 2.0 Adaptation. It’s fine when you run the app on the desktop. But in mobile, you got 2 headers: one from the app and one from the Fiori launchpad. Which make user confused and waste the space of small screen phone.

After checking carefully, I’ve found one line in the manifest.json that make the 2.0 adaption not working:

"rootView": {
   "viewName": "com.bosch.ps.ps_my_spec_mach.view.App",
   "type": "XML",
   "async": true,  // this line make Fiori 2.0 adaptation not work
   "id": "app"
  },

All you need to do is to remove that line and it would work fine.

My explanation:

I’ve checked the help document about the manifest.json and got to understand the async property “async”. In the scenario where we define the root view with async=true, we indicate to the bootstrap to load asynchronously the root view (the App.view.xml in our case) before the initiation of the Component of the app. Hence, my assumption is: that async load of the root view make the Component not recognize the structure the app because the App.view.xml has already loaded, which make the Component not able to merge the 2 headers into one. Which cause our issue with Fiori 2.0 header adaptation.

I would love to see your comments if you have additional explain/information.

Cheer,

Victor.