by John Murray
In this post we’ll be looking at how you can speed up the load times of your UI5 applications by using a Component preload file. Those of you who are familiar with SAP Fiori applications will probably already know what a Component preload file is, however those of you who aren’t will almost definitely have all seen a reference to this file before. This file is referenced in an error message that appears in the console whenever you load a UI5 app, which is lacking a Component preload file.
So just what is this preload file and why should I care?
The preload file is essentially all of the files which make up your application, so that’s the
Component itself, Controllers, Views, Fragments and so on, all compressed and inserted into one file, the preload file. If this file exists then UI5 will only load that file, and it won’t load of all of the other various files which it ordinarily would have done. The error we saw earlier is caused because UI5 looks for a preload file early in the execution flow, but of course did not find one, and so carried on loading all of the files individually.
Now that we’ve cleared up what the file actually is, and why that error appears, just why should exactly should we worry about it? After all we’ve ignored that error up until now and all our apps have worked just fine. Well, the reason we should care is that it dramatically decreases page load time. This is due to the app only having to make one call to get the preload file, rather than all of the individual calls for each file, but also because in the preload file the code is “minified”, which means the file size is also very small relative to the full size individual files. This is especially important when developing UI5 applications which are to be used over a mobile data connection, where size has a very large impact on initial load performance. As an anecdotal example, on the simple UI5 app which I have just created a preload file for my initial load time went from 8-9 seconds down to 3-4 seconds, which is tremendous improvement!
Sounds great! So how can I make a preload file for my UI5 app?
For this next section you will need to have installed on your machine NodeJS, npm and Grunt. If you don’t know how to install and use these things then do reach out to me on Twitter.
30 Days of UI5 Page 37 of 88
After you have all of the above installed, you’ll need to create a package.json file in your UI5 app’s root directory. Open the file up and paste in the contents below and don’t forget to edit them accordingly: "author": "John Murray",
"license": "Apache License, Version 2.0", "devDependencies": {
"grunt": "^0.4.5"
} }
After creating and saving this file, install the Grunt OpenUI5 tools which are made by the UI5 team at SAP. To install these tools open a terminal session in your UI5 root directory and run this
command ‘npm install grunt-openui5 –save-dev’. This will download and install the tools, and also add them to the “devDependencies” section of your ‘package.json’ file.
Next, again in the UI5 app root directory, create a file called ‘Gruntfile.js’. Into this file copy and paste the contents below, and we’ll go through what it all means in a moment.
module.exports = function(grunt) {
// Project configuration.
grunt.initConfig({
pkg: grunt.file.readJSON('package.json'), openui5_preload: {
'webapp/**/*.properties'
This is quite a simple example but it will suffice in most use cases. What we are doing here first of all is reading in the ‘package.json’ file created earlier which provides the dependency list. Then we are setting the configuration options for ‘openui5_preload’ which is the specific tool we are going to be using from the OpenUI5 toolset.
● The ‘cwd’ parameter allows you to provide a base directory for finding the files and the
‘prefix’ parameter lets you prefix all files with a path of your choosing; in this instance we are not using either of these parameters so we are leaving them blank.
● The ‘src’ parameter lets you provide an array of paths, which it will use to try and match files in your directory and then for those matches it will minify and add them to the
preload. I have all of my UI5 application files within a subdirectory called ‘webapp’ which is why my paths all begin with ‘webapp’. I have all my UI5 files located in this directory because I can then keep all of my other files and folders such as ‘node_modules’,
PhoneGap config files, IDE folders, etc back in the root directory. I do this because it allows me to use this simple “get everything” approach you see above in the ‘src’ without
worrying about accidentally including non-UI5 app files.
● The ‘dest’ parameter specifies the path to the destination you wish to save the preload file.
In this case we just want to save it in the same place as the `Component.js` file and therefore can leave it blank.
● The ‘compress’ parameter sets whether or not you wish to minify the files as well as add them to the preload file. I would personally recommend always setting this to ‘true’ unless you have a good reason not to.
● The ‘components’ parameter here with a value of ‘true’ sets the tool to automatically find all components and create a preload for each.
Finally, we load the ‘grunt-openui5′ toolkit from the plugin as previously installed and specified in ‘package.json’.
30 Days of UI5 Page 39 of 88
For the full documentation and parameter list I’d recommend looking at the Grunt OpenUI5 tools GitHub page.
That’s all the configuration set up, now it’s time to generate our preload file! Fire up a terminal session in the same directory as your ‘Gruntfile.js’ and run the following command ‘grunt openui5_preload’ and you should see the following output along with a ‘Component-preload.js’
file alongside your ‘Component.js’ file.
Final thoughts
Congratulations, you’ve just made your first preload file and are now well on the way to creating even better apps with UI5!
30 Days of UI5 Page 40 of 88
Day 15 - The UI5 Support Tool – Help Yourself!
by DJ Adams
Building anything but the most trivial native apps (that’s web native, of course) is not an easy ride. There are so many factors to get right. Debugging one of these apps can be just as tough.
The UI5 toolkit supports many features that make building and debugging easier. One of these is the support for the separation of concerns in the form of Model-View-Controller (MVC) mechanisms. Another is the ability to use a
declarative approach to define your views (no moving parts),
in XML, HTML or JSON; furthermore, you can use the subview and fragment concepts to divide and conquer complexity and embrace reuse.
The Support Tool
The particular feature I wanted to talk briefly about in this post though is the Support Tool,
alternatively known as “UI5 Diagnostics“, or even “the claw hand thing”. This last nickname comes from the fact that you invoke the support tool from a challenging key combination: Ctrl-Alt-Shift-S.
There’s also the Support Tool’s little brother, invoked with Ctrl-Alt-Shift-P, which is a model popup giving you a summary of the runtime context, and giving you the chance to turn on some debugging information.
You can see a shot of this on the left. (You can also turn on debugging via a URL query parameter sap-ui-debug=true.)
Sometimes this is all you need, especially if you want to see the UI5 version in operation, or turn on debug sources.
But the Support Tool is a super, multi-faceted mechanism which has proved invaluable over the years. It sports a large number of features, too many to cover here, so we’ll just have a brief look at one of them (arguably the most important) – the Control Tree:
30 Days of UI5 Page 41 of 88
On the left hand side there’s a super useful display of the app’s control hierarchy. This alone is worth the cost (ahem) of the Support Tool.
Imagine being able to peer into the internal structure of a building, or having X-Ray Specs and being able to see your skeleton, or sitting in front of a monitor in The Matrix and seeing the world behind the curtain. This is what you get with the Control Tree.
UI5 apps can have complex UI structures. Fiori apps especially so. Controls within controls, wheels within wheels in a spiral array, a pattern so grand and complex. With the Control Tree you can see and grok this structure very quickly. Note you can view at a glance what the control actually is, what it contains & what contains it, and what its ID is.
But that’s not all. On the right hand side, for a selected control (for example the Page control in the screenshot above), you can see all the properties of that control and from where in the control inheritance they come. You can modify the values for those properties and see the effect
immediately, and even set breakpoints for each time the value for a particular property is read (G – get) or written (S – set).
30 Days of UI5 Page 42 of 88
Select the Binding Infos tab and see what bindings exist. You can see information on what model a binding is from, what type of binding it is, and of course the binding path. Here we can see some of the binding info for the List control in an app:
For you eagle-eyed readers, the model name here — “entity” — is the name of the domain model in this app example. Often the domain model is the unnamed model, but here it has a name. Can anyone guess what this (publically available) app is?
There’s so much to discover with the Control Tree and the rest of the Support Tool, I recommend you hit Ctrl-Alt-Shift-S the next time you’re running a UI5 apps, and start exploring.
Finishing off
Let’s finish this post off with a quick piece of trivia and a tip. If you’ve had the Chrome Developer Tools open and then open the Support Tool, you’ll notice a ton of new messages in the console, and it’s a lot more verbose. This is because when the Support Tool starts up, it sends a message to the logger to crank the logging output up to 11.
By default, the log level is set to 1 (“ERROR”). If you’re running the app with debugging on, that level is 4 (“DEBUG”). But opening the Support Tool causes this to be set to 6 (“ALL”). You can turn that down again with the jQuery.sap.log.setLevel function. Otherwise, LOG ALL THE THINGS!!1!
30 Days of UI5 Page 43 of 88