UI5ers Buzz #21: Take IDs into Your own Hands

Stable IDs have recently been added to the development best practice guide for UI5 release 1.52 and rightfully so! They are a proper power house when it comes to implementing flexibility and stability for apps and tests: whenever a programmer needs bullet proof reference to an artifact, stable IDs are the perfect match. Many use cases can benefit from this measure – and, by the way, all our demo apps have been updated with stable IDs. Two particularly representative use cases are the topic of this blog post, app flexibility by users and automated testing. Both use cases have in common how stable IDs are assigned:

• For the component, the stable ID is assigned in the index.html file or in the mockserver.html. If the Fiori Launchpad is used, the Fiori Launchpad assigns the ID and no manual setting is necessary

  new Shell({
      app : new ComponentContainer({
      height : "100%",
      name : "sap.ui.demo.bulletinboard",
      settings : {
         id : "bulletinboard"
      }
  })
  

• Views, fragments, controls, etc., get their stable IDs where they are created: within the manifest.json file as part of the routing configuration; but possibly also in the XML views or in the controller, for example, if they are created programmatically.

  "routing": {
      "config": {
      "routerClass": "sap.m.routing.Router",
         "viewType": "XML",
         "viewPath": "sap.ui.demo.bulletinboard.view",
         "controlId": "app",
         "controlAggregation": "pages",
           "async": true
  

1. App Flexibility by Users

Too many contradictory yet similar requirements by the customer? Making the user interface of SAP Fiori apps flexible by means of the UI Adaptation at Runtime feature of SAPUI5 flexibility services is a good chance to meet this challenge. Stable IDs are used to handle programming artifacts within an app. Even if its position in the app or the technical name of the artifact changes the app will maintain its lifecycle stability and freedom from modification. The video below shows how adaptation by users looks:

In the Me Area (the icon looking like a person in the top left corner) of the UI Adaptation at Runtime Demo App, the user can select Adapt UI. Then, fields that are hidden, but available in the app’s oData, can be added to the app, enriching the information on display for the user. Users can add their own labels, combine fields and even add or remove entire sections. Stable IDs for all fields facilitate that all parts of the app are distinct and can thus be referred directly.

It makes sense to use asynchronous loading in combination with stable IDs for performance reasons: as user changes are stored in the SAP UI5 flexibility services, artifacts with stable IDs are generated from there. Asynchronous loading facilitates that the then needless default object generation at the initialization of the app is skipped and artifact generation takes place only once including the user changes, not twice.

2. Automated Testing

In testing, stable IDs lead to more reliable test results. A guarantee that generated IDs cannot give as they can change depending on their environment. The effect can be imagined as trying to use a piece of soap in the shower. If you write your OPA tests and integration tests using stable IDs, you can be sure that there is no room for glitches as the fixed names always exist. They may even expand the testing possibilities. And facilitate more understandable code.

An additional advantage of unique stable IDs is that troubleshooting is easier. First, the developer assigns all artifacts their own stable IDs. This way, we can see in the Developer Tools that the names of all encapsulated artifacts are compounded and allow the developer to pinpoint their location in the code much more easily than automatically generated IDs. Repeating and nonrepresentative names using numbers to distinguish amongst themselves, such as *__button42-content*, make it hard for the developer to recognize where the code for the artifact resides. This is a totally different story with a name like this: If the following XML view is instantiated using the ID myView, the contained page and table would have the IDs myView–page and myView–table at run time.

<mvc:View xmlns="sap.m" xmlns:mvc="sap.ui.core.mvc">
    <Page id="page">
       <content>
         <Table id="table">
         </Table>
       </content>
    </Page>
</mvc:View>

Aren’t stable IDs an easy and yet significant way to expand the horizons for your app programming? We hope that you enjoyed this little lesson of the UI5ers Buzz series again and hope to get your feedback.

More information can be found in the documentation on stable IDs.

How are we doing? Let us know by leaving a comment here or contacting us in the slack channel.

Previous Post: UI5ers Buzz #20

Happy coding!

Annette

Annette is a UI5 developer at SAP who loves to be creative and produce sophisticated Web front ends. Always in pursuit of the optimal user experience, she’s supporting UI5 communities, happy to share success and grateful for learning something new every day.

Sebastian

Sebastian is architect for the UI adaptation tooling for SAPUI5/SAP Fiori UIs. Whenever he can, he advocates agile development methods. He’s curious about patterns for software extensibility since the beginning of his career and likes the dynamics of meta programming in ABAP, Java, and JavaScript.