Split-Screen Made Easy -2

Introduction

Further to our earlier post on Split-Screen in Fiori made easy here, let us proceed to add some functionalities to the same. Often while giving training, you could start small and enhance with additional functionalities.

Cloning the Repository

Let us quickly take a copy of the working application from the GitHub repository and create a UI5 project in Web IDE.

Fig 1): Cloning from the Repository.

 Fig 2): Web IDE project.

Fig 3): Project structure created

Quickly running the application gives us the same earlier list of coffee and tea items.

Fig 4): List of Items in Master Detail views.

Back Button

We see that the application does not have a Back button included which is very popular in the Split-Screen applications. Let us quickly add one. When we look at the Detail view, it appears the property responsible for the same is already present but mapped to the device model.

Fig 5): Back Button tag.

     As per the API Reference, it expects a boolean value with default being ‘false’.

Fig 6): Page property default value.

Let us explore the device model and see what is the value that it is returning at runtime. We locate the device model definition in the ‘model.js’ file under the ‘model’ folder.

Fig 7): Device model definition

Now the same is set globally with the name ‘device’ at the Componet.js. API reference here.

Fig 8): Device model setting.

To test the value that it returns, we set a break point while starting the ‘Detail.view’.

Fig 9): Evaluating runtime value

Let us analyze the values our ‘device’ model returns.

Fig 10): Device model value

For the system,’phone’ it returns ‘false’ and hence our Detail.view does not show the Back navigation button, which is fair as we could see both Master and Detail at the same time in Desktop/Laptop but only one in a phone due to screen size limitation on a phone. For time being, let us quickly override this in console:-

this.getOwnerComponent().getModel("device").getData().system.phone = true;

And the Detail.view now shows the Back Button.

Fig 11): Back Button on Detail.view

On the implementation side, we add a new dependency for History as mentioned here.

Fig 12): Back Navigation implementation.

For time being, we set the system as ‘desktop’ for the ‘Back’ button to keep showing.

<Page title="{drinkName}" navButtonPress="onNavBack" showNavButton="{device>/system/desktop}">

In order to simulate the scenario, we select the ‘Tea’ item from the master list, view the tea item details in the details screen and click the ‘Back’ button. It shows the Master list items with Coffee details being shown.

Fig 13): Back button in action.

One small problem though, when we navigate back to master list, didn’t remove the earlier selection on Master.view. Here it retains the ‘Tea’ item still selected. To avoid that whenever we click the ‘Back’ button we remove the Master list item selection.

this.getView().byId("orders").removeSelections(true);

And the result now looks right.

Fig 14: Navigating back.

You might have noticed that even though the Coffee products are shown on right, the ‘Coffe’ item is not selected on the left. Let us handle that also by setting the selection to first item as below:-

var firstOrder = this.getView().byId("orders").getItems()[0]; 
this.getView().byId("orders").setSelectedItem(firstOrder,true); 

Now the ‘Coffee’ items is selected on left while navigating back. Also when loading the app initially.

Fig 15: Fist Item selected.

Updating the Feature

Now with the updates done, let us push this back to the repository. However we don’t want to overwrite the existing source base and wants to keep the feature separately. We stage all the changes from the ‘Git’ pane.

Fig 16: Staging Changes.

Let us create a new remote branch(in the repository) so that we could keep existing as master and this new changes separately. If need be we could merge this feature later on.

Fig 17: Feature Branch creation.

Now we could push the changes to the new feature branch.

Fig 18:Pushing changes to feature branch.

Ok, now our changes are reflected on the feature branch(master remains intact as well?)

Fig 19:Feature branch with changes.

Full code available on GitRepo at FioriMasterDetail

Thanks,

Jakes