30DaysOfUI5

(1)

30 Days of UI5

Celebrating SAPUI5 and OpenUI5's milestone 1.30 release in Autumn 2015

by

DJ Adams, John Murray, Sean Campbell, James Hale, John Appleby, Chris Choy,

Nathan Adams & John Gregory (Bluefin Solutions)

and

Thilo Seidel & Sam Yen (SAP SE)

with a foreword by

(2)

Preface

This series has been a great journey for me and the rest of the folks who have contributed, and the result of a series of lucky circumstances:

● That SAP had the foresight to employ such superheroes for their UI5 team which is still going from strength to strength.

● That I was lucky enough to be able to work alongside them in Walldorf for a good period of time.

● That Bluefin has such a great team of UI5 developers, many of whom were also more than willing to collaborate with me on this series either directly or indirectly.

● That close contact and friendship with SAP colleagues resulted in an even wider collaboration (witness the contributions from Andreas Kunz, Thilo Seidel and Sam Yen here).

● That my friend Frank Köhntopp came up with the neat idea of turning the series of posts into an electronic book format.

The richness of the UI5 toolkit is matched by the warmth of its corresponding ecosphere, and the true openness and friendship of all of the folks both within and outside of SAP. To me, UI5

represents the new SAP in many ways: Web-first, developed with open source tools, and itself open sourced, an equal balance between technical accomplishment, utility and beautiful design, and created & curated by folks with a genuine passion.

UI5 is now at release 1.30 and the trajectory shows no sign of slackening off any time soon. I'm looking forward to 1.32 and beyond, and continuing my journey learning from those who are, perhaps unaware, teaching me great things.

Thanks again to Frank for suggesting this format, and I hope you enjoy this series! -- DJ Adams, October 2015

(5)

Foreword by Andreas Kunz

How It Started

It all started back in November 2008, with five to six people from different teams - all with different backgrounds - sitting in a room that was meant to accommodate four at the most. We were asked to create a new UI. One that was flexible, extensible, modern, and independent from the backend technology. None of us had any idea at the time where this would eventually lead. So why this challenge? Fact was, any visual or functional improvement of SAP’s main UI

framework back then had to be developed within an expert team, which had become a

bottleneck. Even worse, any improvements that were developed often didn’t reach customers for years as user interface upgrades could only be performed together with backend upgrades – often meaning considerable effort and costs. Decoupling was urgently needed.

SAP had recently acquired the business intelligence company Business Objects and was in the process of making even more acquisitions. The prospect of maintaining a zoo of UI technologies, each with its own look & feel on technology stacks outside the ABAP / Java story used within SAP, wasn’t a particularly pleasant one.

Going About It

The task was huge, but the chance to start from scratch with a greenfield site, laced with freedom, trust and enthusiastic, super-talented colleagues like the ones I had, is a pleasure for every

developer.

It goes without saying that journeys such as this are rarely straightforward. Stakeholders came and went. Visual themes were created and discarded. A lot of options were explored and abandoned, like optional server-side rendering or writing control renderers as HTML templates. Some of these ideas may be (or were already) resurrected under new preconditions. One of the big early changes was switching to jQuery as our foundation, replacing our own DOM manipulation layer, after thoroughly investigating different options. This constant evolution remains vitally important to UI5, as seen by the transition to the cross-device “sap.m” library or the recent move to AMD syntax and asynchronous module loading.

Adoption and Success

So how did UI5's success come about? All of a sudden, SAP developers were given an easy-to-use, totally tweakable UI technology. And what’s more, it looked good:one line of code was enough to bring up the entire “Gold Reflection” Shell, which had external developers tweeting right away about how this was “easily ... the best UI SAP has ever done”. So whether it was for demos or new products, out of nowhere it was so easy to impress with a beautiful user interface. In no time at

(6)

all, UI5-based apps started dominating SAP demo jams around the world, and UI5 was being used more and more in people’s free-time projects.

Wow, developers actually voluntarily chose an SAP UI technology?! Because it was easy and looked good?!

For sure, the UI5 team’s willingness to communicate with users of the framework helped a lot. At times, three of the global top ten posters in the internal community forum at SAP were from the UI5 team, answering questions and assisting users.

Going Public

As soon as the first trial version of SAPUI5 was made available to the public in February 2012, this willingness to communicate was met by an open and welcoming community of external

developers. I remember how I bumped into DJ Adams at the SAP DKOM event in April 2012. He had already looked into the library and written positive blog posts, which the UI5 team had devoured eagerly.

But apart from one or two TechEd presentations in 2011 (before externals actually had access to UI5), this was UI5’s first personal contact with the outside world. And it grew into a friendship, which has to be the best possible relation between a framework’s providers and its users, right? Seeing how much DJ has done to advocate UI5 ever since, I view this moment as a key factor in sparking UI5’s success in the external developer community, and for him it was apparently one of the moments that made him blog about the new SAP developer connection.

OpenUI5

The decision to open source UI5 came suddenly. Or maybe not. We had planned it all along, it was on our mind from day one, but somehow it needed the right moment and quite a push from the outside world to actually make it happen. The opportunity to announce it at TechEd Bangalore 2013 was a factor, I think. To not spoil the surprise, only three or four team members knew about it a few days in advance. While this allowed us to insert the chosen name where needed and create a web site and a build with the Apache license, it took a few more months until we had a Grunt-based replacement for our internal Maven build infrastructure and could subsequently move UI5 development to GitHub - and let the whole world contribute.

Now, less than one year later, we've already registered over 10,000 publicly visible code commits, dozens of external contributions, and hundreds of closed issue reports that help us deliver a quality framework. And it was a huge relief to us that, despite our prior doubts, public response turned out to be just right: there was neither disinterest, nor an unmanageable flood of issue reports.

(7)

The Future

So what does the future hold? I’ll not lay out a roadmap here, but I do see lots of new stuff emerging at the periphery and the evolution continues throughout UI5. Be it in the programming model, the functional scope, documentation or design.

And the community is also evolving: this blog post series and ebook, created as a joint effort by developers and managers inside and outside of SAP, looks - at least to me - like a novel step into untapped territory.

And that’s a great direction in which to go. -- Andreas Kunz, September 2015

(8)

Day 1 - Welcome to 30 Days of UI5!

by DJ Adams

UI5, the collective short name for both SAPUI5 and OpenUI5, is soon to reach a milestone, with the release of 1.30. There’s already a preview release available.

The UI Development Toolkit for HTML5, to give it its proper long-form Culture-style name, has come a long way in the last few years. It’s a multi-faceted tookit that shows pedigree, passion and influence from many directions. From the web dynpro inspired design roots, through the hard work and commitment from all the great designers and developers, to the exemplary responsive controls we have come to know and love in the sap.m library and beyond.

And of course there’s the open sourcing of the toolkit, a great move on SAP’s part, influenced not in a small way by many developers both external and internal to SAP. Many of the UI5 core team have open source in their blood, part of a new generation that is making SAP what it is today.

Where would SAP Fiori be without UI5? Nowhere. The engine behind the UX revolution that is powering today’s and tomorrow’s SAP applications (with S/4HANA) is UI5.

As Norman Cook might say, “You’ve come a long way, baby“. So as a bit of fun, and to celebrate this version 1.30 milestone, here’s a series of 30 posts, one a day, on UI5 related topics. Small posts from me and some guest authors, designed to be read during a quick coffee break. Nothing earth shattering, but hopefully things that will whet your appetite for further reading, and perhaps bring to your attention features that you might not yet have had a chance to consider.

This series is available online at http://bit.ly/30ui5.

(9)

Day 2 - Expression Binding

by DJ Adams

The expression binding feature was introduced with version 1.28, and allows logic to be included directly in an embedded binding. It’s a very useful feature, but a double edged sword that should be wielded with care.

Before expression bindings, any embedded binding that required a condition to be checked, or a calculation to be made, or a reformatting to happen, needed a reference to a formatter

function that would either be in a dedicated formatter module (common), or in the controller (less common). When using XML views, for example, the Model-View-Controller philosophy remained strong, in that any imperative computation remained separate from the pure declarative UI definitions.

But in practice you find yourself creating a lot of formatter functions. Yes, some of them could be probably be refactored, and if you had time, you could probably find that library of common formatter functions that you’d been half building in your copious free time. Regardless, you end up with a lot of helper functions, small and large, that sometimes become a maintenance burden. Enter expression bindings. If you’re prepared to add sugar and milk to your coffee, if you’re prepared to sacrifice the absolute purity of MVC for the sake of brevity, then expression bindings can be your friend.

Here’s an example that you can find on JSBin at http://jsbin.com/wivuku/18/edit:

(10)

HTML <!DOCTYPE html> <html> <head> <script src="https://openui5.hana.ondemand.com/resources/sap-ui-core.js" id="sap-ui-bootstrap" data-sap-ui-theme="sap_bluecrystal" data-sap-ui-libs="sap.m" data-sap-ui-xx-bindingSyntax="complex"> </script> <meta charset="utf-8"> <title>Expression Bindings</title> </head> 30 Days of UI5 Page 10 of 88

(11)

value="{= 'Good ' + (${/now}.getHours() > 11 ? 'afternoon' : 'morning')}" />

</mvc:View> </script>

<body class="sapUiBody" id="content"> </body> </html> JavaScript jQuery.sap.declare("localfrmt"); localfrmt = { greeting : function(dNow) {

return dNow.getHours() < 12 ? "morning" : "afternoon"; }

};

sap.ui.controller("localctrl", { greeting : function(dNow) {

return dNow.getHours() < 12 ? "morning" : "afternoon";

(12)

} }); sap.ui.xmlview({ viewContent : jQuery("#view1").html() }) .setModel(new sap.ui.model.json.JSONModel({ now : new Date()

}))

.placeAt("content");

Result

The greeting is created in three different ways. First, we use a function inside a formatter. Then, we use the same function but in the controller that is linked to the view (note the dot prefix in the value of the formatter property, specifying that the function is to be found in the controller). Finally, we have the same example in an expression binding, directly in the view.

Those who have had their coffee already today (milk and sugar optional) may have noticed

something unusual in the expression binding example. Instead of having the literal “Good” outside of the embedded binding curly brackets, like this:

<Input

enabled="false"

description="Expression"

value="Good {= ${/now}.getHours() > 11 ? 'afternoon' : 'morning'}" />

… it’s like this, instead:

<Input

enabled="false"

description="Expression"

value="{= 'Good ' + (${/now}.getHours() > 11 ? 'afternoon' : 'morning')}" />

(13)

This is because, currently, any literal string outside of the curly braces is rejected by the runtime. Anyway, expression bindings are here, and they may be the sort of thing that you’re looking for. Possibly exactly what you’re looking for, if you’re considering XML Templating. But that’s a post for another time.

(14)

Day 3 - Semantic Pages

by DJ Adams

My degree in Latin and Greek is not entirely without foundation or reason, and it provides me with at least a small sense of origin when it comes to words. The 3rd declension noun σ_ῆμα conveys the idea of a mark, a sign, a token. It refers to “meaning”, essentially, and the use in modern languages of the word semantic often implies an abstraction, a layer that confers or allows meaning to be defined or carried.

What has that got to do with UI5 reaching release 1.30? Well, take a look at the fledgling Semantic Page. It’s the root of a series of new controls that are perhaps set to encourage standardisation of Fiori UIs. The SAP Fiori Design Guidelines describe a rich set of controls, but more importantly they describe how those controls should be typically employed.

Floorplans such as the Split Screen Layout and the Full Screen are all fairly familiar to us. But consistency comes from attention to a more granular level of detail, and the UI designers are encouraged to place certain controls in standard places. A couple of examples: Action buttons belong in the bottom right (in the footer) of a page, while the new Message Popover from 1.28 belongs in the bottom left.

When SAP created Fiori application developer teams across the world to build out the Fiori apps that we see available today, it was almost inevitable that the different styles and approaches across teams and members would have resulted in a variety of structures, making it difficult to get the UX right, the UI consistent, and causing maintenance headaches. So SAP created scaffolding (sap.ca.scfld), a set of mechanisms that abstracted away a lot of the common boilerplate stuff allowing the developers to focus on the application logic (and preventing them from reinventing the boilerplate, slightly differently, every time). But this scaffolding was a little bit too monolithic, and I think the plan has been to phase it out.

I’m also thinking that the alternative could involve this set of semantic controls. Take a look at the way the Semantic Page Master-Detail sample puts things in the appropriate place – at a

semantically meaningful level of abstraction above the individual mechanics of a Page control’s aggregations, for example.

It’s similar in the Semantic Page Full Screen sample too. To get a feel for this level of abstraction,

take a look at how the aggregations are filled – nowhere in this XML view definition does it say where the semantic controls should go:

(15)

And there are plenty of semantic controls too. It doesn’t replace the breadth of functionality that the scaffolding offered, but it’s a start, and it feels more modular. A namespace to watch!

(16)

Day 4 - Creating Native Applications with UI5

by John Murray

Whilst web apps are great, and suit the vast majority of situations perfectly, sometimes they just don’t quite cut the mustard. It is in these situations that we are presented with a difficult choice, do we take option A – Sacrifice the features which are specific to native applications for the sake of sticking with UI5 and the benefits that web apps bring? Or do we go with option B – Sacrifice UI5 and the web app benefits, instead going with native code, but then have access to all the features? Well, even in the not-so-distant past we would have to weigh up the pros and cons of each option and make our decision accordingly.

More recently, we were provided with an option C – Use PhoneGap to make our application like a web app, using UI5 and an assortment of plugins to achieve our ends. However, this option was not without its own challenges and problems; you had to install libraries for all platforms you wished to build for, then structure everything in a rather precise manner, and to top it all off you then had to battle with the rather clunky command line interface. This did of course improve over time and after you had your setup and work flow down to a tee, but it was never smooth sailing. Thankfully though, we now have an option D!

Option D is PhoneGap Build, a service which takes everything that is great about standard PhoneGap and then removes everything that is bad about it, providing a fast and streamlined experience. This service is freely available, and will allow you to have a native version of your UI5 app up and running within minutes.

As an overview, you create your UI5 application as you would normally, except this time you also include a config.xml file in the root folder. It is this file which the Build service uses to create your application, you simply specify the location of your index.html file and reference any plugins you wish to use. You then zip up all of your code and upload it to their website, and it will

automatically build a native app for Android, iOS and Windows Phone in a matter of minutes. For more a more thorough getting started guide on all of this, I am currently writing an in depth blog series on my own website, the first part of which can be found here – UI5 and PhoneGap Build: First Steps.

(17)

Day 5 - OpenUI5 Walkthrough

by DJ Adams

OpenUI5, like it’s twin sibling SAPUI5, has a great SDK.

The SDK contains plenty of example code snippets, especially in the Explored app. Up until version 1.20 the Explored app was “just another” app in the Demo Apps section, but after that it was (rightly) promoted to prominence at the top level of the SDK menu structure.

The latest addition to Explored is a set of code examples that accompany a great multi-step walkthrough of many of the features and practices of UI5 development. A number of things are changing in release 1.30, including the introduction of the

application descriptor, and a new way of defining modules. This walkthrough covers these topics and many others too. It’s well worth a look.

One thing that immediately caught my eye was when I selected the appropriate Explored sample that corresponded to Step 30 of the walkthrough, describing the Debugging Tools : the excellent UI5 Diagnostics Tool popped up out of nowhere!

(I’m a big fan of this tool; there’s so much information it offers, as a UI5 developer you can’t afford to ignore its help.)

I was curious as to how this automatic opening of the tool had been achieved, and a quick look at the appropriate webapp/Component.js asset in the sample’s code section gave me the answer:

jQuery.sap.require("sap.ui.core.support.Support");

var oSupport = sap.ui.core.support.Support.getStub("APPLICATION"); oSupport.openSupportTool();

Nice!

(18)

Day 6 - The App Descriptor

by Thilo Seidel

Writing your component based applications in UI5 you might be familiar with a long list of settings in your metadata section making you scroll down for hours before reaching the point where the first violin plays. This is not only annoying but in fact bad design as it means to mix static

configuration in large amounts with actual code.

One way to solve this is the usage of a manifest file – one central asset that holds your entire application configuration. The UI5 creators have drawn inspiration from the W3C manifest for a web application concept that is currently under investigation and create an UI5 flavored version of it. The app descriptor in UI5 is basically a JSON file named manifest.json that is expected in the same folder your component lives in. All you need to do to get started is to add an attribute manifest with the value “json” to your component metadata.

Introduced in 1.28 in a basic version, with upcoming 1.30 it is even smarter. Beyond static

configuration for packaging and deployment it even helps to save you some code, especially when it comes to model instantiation. The manifest itself is structured in namespaces of which we want to briefly look into sap.app and sap.ui5 for this case. More details and examples can be found in the 1.30 documentation preview.

sap.app:

Mostly app specific attributes can be found here. You can also get set for your data model and resource bundle here. One property called ‘dataSources’ expects an object that holds the URL to your service, the service type and some additional settings if needed. A full blown service

configuration would look like this:

(19)

If you have more than one service you can simply add another object to this attribute. These can later be referenced by the given name. In addition we added the relative path to the i18n file here and will make use of this later as well.

sap.ui5:

This namespace is used for any configuration that can be used by the UI5 runtime directly. This counts for the routing configuration, but also for UI5 library dependencies and of course our case with the model instantiation.

For i18n it is pretty straightforward and a named i18n resource model (named “i18n”) will be created by the UI5 runtime. For the actual data model(s) you can also specify a name or keep it blank for an unnamed data model like this. Just set the datasource specified earlier and UI5 will handle the rest. The created models will be at your command as early as in the init function of your component.

To conclude this is only a snapshot of one little feature that is built into the new UI5 manifest, but showcases pretty well how this new file will ease your development routines, help to clean up your components and limit repetitive lines of code.

(20)

Day 7 - JavaScript Do's and Don'ts for UI5

by DJ Adams

In recent versions of the SDK you’ll find a new section called “Coding Issues to Avoid“. It’s great to see this take shape and start to become formalised. Some of them are obvious, at least to some folk, but it’s always helpful to have a reference.

Let’s have a look at a couple of the Do’s and Don’ts here.

The top item on my list is “Don’t use private and protected methods or properties of UI5″. Far too often, I see code that refers to internal properties of UI5 controls, especially to the arrays and maps that are managed internally (for the aggregations,

for example). I think it’s fair to say that 98% of the time, the use here is totally wrong, and there’s a public API to give you what you want. There have been a couple of instances in the past where I’ve seen something for which there appeared no equivalent ‘legal’ alternative, but that could be down to API maturity, or lack of documentation.

Related to this item is almost the antithesis, which is to use (create) properties that inadvertently clobber properties of the same name in an existing context. A great example of this is within a controller definition. There’s a nice pattern, which can be seen in many places including the reference apps in the SAP Web IDE, where in any given controller you would create controller properties to refer to the related view, and often the domain or view properties model, in the init event, like this:

sap.ui.controller("local.controller", { _oView : null, onInit : function() { this._oView = this.getView(); }, onSomeEvent : function(oEvent) { ... this._oView.someFunction(...); 30 Days of UI5 Page 20 of 88

(21)

... } });

But sometimes the developer, averse to underscores, will write it like this:

sap.ui.controller("local.controller", { oView : null, onInit : function() { this.oView = this.getView(); }, onSomeEvent : function(oEvent) { ... this.oView.someFunction(...); ... } });

What actually happens is that the call to

this.oView = this.getView();

is clobbering the internal property oView of ‘this’ (the controller), which is pointing at the view it’s related to. Luckily what it’s being clobbered with in this small (underscore-less) antipattern is another reference to the view itself, so not much immediate harm done, but it’s not entirely safe or future proof.

Another interesting best practice described in this section of the SDK relates to

internationalisation (i18n). What one should do is to use placeholders (such as {0}) in more complete sentences in translateable resources. What one often finds is that application texts are fragmented into short phrases and built up with concatenation, along with variables.

The problem is that sentence structure varies across languages – as described in the “Don’t” example in this section, a typical example is where the verb goes. It’s better to avoid

programmatic text construction, and leave it to the translation experts. Go long, and go home. Anyway, have a look at the rest of this JavaScript Code Issues section in the SDK, plus there’s a CSS Styling Issues section too!

(22)

Day 8 - User Notifications with the Message Popover

by Sean Campbell

Giving an end user good feedback regarding their interaction with the application or the application’s interactions with the back end has always been a bit of a challenge in UI5. Until recently pretty much every developer had a different style of capturing and exposing messages, with many of us building our own message log solutions. This lost a level of the “Enterprise” uniformity that is often required for our applications.

In recent releases however SAP and OpenUI5 have provided a very robust and uniformed way of exposing these messages.

Now users can expect message to be shown in a

clear and concise way, that is the same across all UI5 applications; no more are we hacking around arrays to provide our own message logs. From the bright colours to the simple click through to view a more detailed message, everything about this control has been aimed at the user who expects clear interactions, even Web Dynpro Java (WDJ) handled messages better than early UI5. In the example below I have mocked up a couple of Buttons that trigger the Popover in its two “States”. I tend to lean towards the full Popover as its easy to see a full list of the most recent messages. However I can see good use cases, in mobile apps for example, where the condensed popover would be best. As shown in Day 3 of this series, on Semantic Pages, the footer bar makes a nice place for the Button that controls the Popover.

Here's an example, available at http://jsbin.com/somuxu/3/edit:

(23)

This control still isn’t perfect and there are a number of improvements I could see being added over the next few iterations but it is certainly a dramatic leap in the right direction for UI5 and user interaction. The ability to easily delete messages would be nice along with a way to prevent duplication on error.

A nice touch that can be done relatively simply is to alter the look and feel of the Button

dependent upon the level of messages that have been posted. Those that have been following this series will have read DJ’s post on Expression Binding from Day 2 of this series. This would be a great way to derive the icon in the Button, to be based upon the “Highest” status message. Doing this gives the user feedback without them even opening the Message Popover and to me giving a user feedback at the earliest possible time is always going to give them the best experience.

(24)

Day 9 - Bootstrapping UI5 Locally and in the Cloud

by DJ Adams

Like many developers who find themselves building a lot with UI5, I find my working environment is mostly a local one, supplemented by

activities in the cloud.

Local Environment

More precisely, while I often use the excellent SAP Web IDE – for

training, generating starter projects and custom Fiori work, my main development workflow is based upon tools that are local to my workstation. In my particular case, that’s most often my MacBook Pro running OSX, but sometimes a Debian-based environment running in a chroot on my Chromebook, courtesy of the awesome crouton project. I use tools that work for me, that don’t get in the way of my flow, and at the bare essentials level, that means a decent editor (Vim or Atom), a local webserver (based on NodeJS), and a runtime platform that doubles as debugging, tracing and development (Chrome).

Cloud Environment

When I’m working in the cloud, specifically with the SAP Web IDE, the toolset is totally different. Not only that, but the bootstrapping of UI5 works slightly differently. In this short post, I wanted to explain what I do to flatten any speedbumps when transitioning between the two

environments. The worst thing for me would be to have to alter my codebase slightly to take account of different runtime environments.

Different UI5 Versions

Locally, I maintain a variety of different UI5 versions, that I’ve picked up over the months and years. You never know when you’ll need to go back to a previous version, or even look through the complete history, to see how something has changed. This is what the contents my local ~/ui5/ folder look like:

(25)

I use the NodeJS-based static_server.js script to serve files from this folder, as well as another folder which contains my UI5 projects. From here, I can access different UI5 versions by changing the location that the UI5 bootstrap looks. (Note that while I can and do often access older

versions, I pretty much always develop against the latest version, unless there’s a good reason not to … access to older versions is almost always for reference purposes.)

Usually I specify “latest” in the URL, which refers to the symbolic link in the folder above, which (via the use of the small “setlatest” script) in turn points to whatever folder represents the latest unpacked zip:

(26)

If I want to refer to an older version, I do so like this:

The same approach with the URL path applies to the contents of the “src” attribute in the UI5 bootstrap:

Harmonising Local and Cloud Bootrapping

However, this doesn’t play well with the SAP Web IDE, at least not directly. So I’ve come up with an approach that minimises the fuss and disruption when taking a UI5 app repo that I’ve

developed locally, and cloning it for use in the SAP Web IDE on the HANA Cloud Platform (HCP) environment, or vice versa.

Let’s look at an almost empty UI5 project folder that I’ve created locally:

In it, we have the index.html which contains a UI5 bootstrap that looks like this:

(27)

The “src” attribute refers to a resources folder in the same location as the containing index.html. The value of this attribute (“resources/sap-ui-core.js”) is pretty much the de facto standard for “the location of the UI5 runtime”, so it’s sensible to change this only if you have a very good reason, if not only because you’re starting a battle that you might not want to see through.

If you look at the folder listing above, you’ll see that this resources folder is actually a symbolic link to the resources folder in the “latest” UI5 version, as described earlier (yes, so we have a symbolic link following a symbolic link). So we’re bootstrapping whatever the latest version of UI5 is.

We’re not interested in having this in our UI5 application repo (it would be of no use in most other contexts) so in our .gitignore file, we exclude it:

When we want to run the application in the HCP context, via SAP Web IDE, we use a mapping file that translates our bootstrap “src” attribute URL into a resource that is available globally on HCP. This mapping file is neo-app.json, and here, it contains this:

(28)

The path “resources” is mapped to the target “sapui5″ service at “/resources”. This means that the script element in our index.html can successfully resolve and bootstrap UI5 from the right place, with zero changes between my local environment and HCP.

With my “resources” symbolic link in place, along with the neo-app.json mapping, I can enjoy a smooth transition between local and cloud based development when I’m working on UI5 development with the latest version. It’s a simple technique; get it in place, and you could be looking at some happy productivity gains, without loss of any reference to older UI5 versions locally.

(29)

Day 10 - Handling Dates with the Date Picker

by James Hale

When creating applications, the experiences of the user should be one of the key considerations that drives build and development. One aspect of this is the way that data is entered, saved and displayed to the user, which can drastically affect the usability of an application.

For this short post, we’re going to take a look at the

Date Picker, which is an input control in the OpenUI5 library used for simple capture of dates from the user. As we all know, dates can be somewhat of a nuisance to work with, especially when entering on small screens with particular formats. This control aims to ease this with a calendar style view of dates to select from.

It’s a simple, yet effective, little control that allows users to quickly select dates with a familiar and quick to use calendar style view. The control is also configurable to display different date formats based upon the displayFormat property, which can be useful when screen real estate is at a premium.

By using controls like the Date Picker with dedicated input mechanisms, we can all aim to make our applications easier to use within the day to day lives of users.

For additional controls focussed around date and time input, take a look at the Date Range Selection control when working with time periods, as well as the Date Time Input when making forms that handle dates and times together.

(30)

Day 11 - Lightweight notifications with the Message Strip

by DJ Adams

The Message Strip is a nice new control with 1.30. It’s in the main (sap.m) library of controls, and for me, appeals because it bridges the gap between no message at all, and a modal dialog box which is sometimes too heavyweight.

(If you’re wondering about the Message Toast control, don’t forget that this lighter weight

mechanism should only be used for “less important” messages such as informational messages on the successful completion of a step).

The nice thing about the way that this has been designed is actually its simple, perhaps restrictive nature. A nature that will give apps a better chance of having consistent messaging. The possible

message types are defined in the core, and are displayed visually differently, via colour and icons. There’s an optional close button, and an optional link that is always displayed at the end of the message text. Pretty simple and neat.

And that’s about it, which in most cases, is all that will be needed, to display a useful short message in line within the application UI, especially in the context of desktop based UI designs. If you want to manage messages in a more complete way, you might want to take a look at the

Message Popover. But don’t dismiss the new Message Strip, it may just be what you’re looking for.

(31)

Day 12 - Base Classes in UI5

by Thilo Seidel

Learning your way around UI5 can be hard sometimes. With the new tutorials and improved structure in the developer guide, help on the journey to UI5 mastery has got better over the last few months.

But if you really want understand the UI5 magic in all its depth you might want to dig a little deeper. For my part I can truly recommend going back to the roots to have a look into the UI5 base classes. They are properly lined up like a string of pearls building upon each other and forming the high level architectural blueprint of the toolkit as a whole.

All UI5 base classes come with a set of metadata, basically simple json that may hold additional information describing the instance. In addition this metadata has an underlying metadata implementation that provides helper functions, validation logic and some more convenience.

(32)

sap.ui.base.Object

This “instance plus metadata” concept is introduced already with sap.ui.base.Object, the first in line and mostly everything you want to instantiate in UI5 will be inheriting from it. Its children are mostly workers like classes taking care of parsing, or basic data carrying objects like the event implementation.

sap.ui.base.EventProvider

While Object is only setting the stage, sap.ui.base.EventProvider is the first to actually have capabilities to share. And you might have guessed it from the name already: the Event Provider introduces eventing in UI5. With functions to attach, detach and fire events, its toolkit is only small compared to what is still to come. Nevertheless, it is the starting point for most of the key features in UI5. Model, Binding, Router, at the heart they are all “just” Event Providers.

sap.ui.base.ManagedObject

Next in line is a heavyweight champion when you compare it with its predecessor: the sap.ui.base.ManagedObject. It is the herald for all instances that later will be rendered as it introduces properties, aggregations and associations in the metadata. It will never be rendered, but it sets the stage and extends the metadata implementation adding getters and setters for the fields that are introduced. Moreover it allows for data binding and might even have its own model. The most prominent example is the Component.

sap.ui.core.Element

The first base class that might have a place in the DOM is the sap.ui.core.Element. It has to be said that the Element itself has normally no renderer on its own and therefore is not to be placed standalone into the DOM. But it is the class you want to use in aggregations of your own controls with the list item as one of its best known subclasses. It is the one that completes the metadata implementation for base classes.

sap.ui.core.Control

Last up for this journey through UI5 architecture is the sap.ui.core.Control with children that are full blown UI elements. The last few thing that are still missing are introduced now. Besides direct DOM placement and the renderer it is basically picking up the last pieces with the busy-state and ability to handle browser events. And of course, every real UI-control has learned from Control.

sap.ui.core.Core

This post gives just the briefest of UI5 architecture overviews, covering only the bare essentials. There is much more to discover in that respect and I highly recommend you check out the entire package from GitHub and go exploring. There are definitely some gems hidden deep in the UI5

(33)

repository. Just one more for now, the sap.ui.core.Core, her majesty itself. And you might have guessed it, humble as she is, she downgraded herself recently and finally is nothing more than a (Base) Object.

(34)

Day 13 - Multi language support out of the box – UI5’s

pedigree

by DJ Adams

I was browsing through the controls that were new with 1.28, using the OpenUI5 SDK’s Explored app’s filter-by-release feature, and came across the Message Page control.

What caught my eye was the text on the control. When you think about it, there aren’t that many controls that have default text on them.

Looking into how this would work in other locales (this control as you see it would only make

immediate sense in English-speaking countries), and how the text was specified, led me down a path that ended up at a place that reminded me of OpenUI5’s pedigree. Born inside of SAP, the enterprise scale thinking permeates throughout the toolkit, and is very visible in this context. In the init function of MessagePage.js you can see that the control’s text property is being set to the value of the MESSAGE_PAGE_TEXT property in the message resource bundle:

This MESSAGE_PAGE_TEXT property in the base resource file messagebundle.properties has the value “No matching items found.”:

Even if you know only a little about how resource models work, you may realise that there’s more to it than this. There are actually 39 different translated versions of this base resource

(35)

representing many languages (more specifically locales) into which this control (and other controls) have been translated:

Let’s have a look at a few (with the second grep I’m omitting those that have Unicode encodings, because they’re hard to read):

And of course, not only does UI5’s pedigree extend to just translations, right-to-left (RTL) is also supported, out of the box.

Let’s bring this post to a close with a couple of examples. Don’t forget you can explicitly specify the language or locale with a special query parameter “sap-language” in the URL.

Here’s Hebrew (“iw”), with RTL kicking in automatically:

(36)

And to finish, how about another language:

(See what I did there? :-)

(37)

Day 14 - Speeding up your UI5 app with a Component

preload file

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.

(38)

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: { "name": "barcode-test", "version": "0.0.1", "description": "", "main": "index.html", "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: { component: { options: { resources: { cwd: '', prefix: '', src: [ 'webapp/**/*.js', 'webapp/**/*.fragment.html', 'webapp/**/*.fragment.json', 'webapp/**/*.fragment.xml', 'webapp/**/*.view.html', 'webapp/**/*.view.json', 'webapp/**/*.view.xml', 30 Days of UI5 Page 38 of 88

(39)

'webapp/**/*.properties' ] }, dest: '', compress: true }, components: true } } }); grunt.loadNpmTasks('grunt-openui5'); }

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’.

(40)

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!

(41)

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:

(42)

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).

(43)

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!

(44)

Day 16 - UI5 and Coding Standards

by DJ Adams

At one end of the spectrum, coding standards can be regarded as essential. At the other, they’re the subject of many a passionate debate, second perhaps only to the Vim vs Emacs editor wars.

I’ll provide some caution by starting with one of my

favourite quotes, from Andrew Tanenbaum: “The nice thing about standards is that there are so many of them to choose from”.

Use of standards

As software projects scale up, coding standards make more and more sense. On a recent run, I listened to the JavaScript Jabber podcast “JSJ ESLint with Jamund Ferguson“. There was a great discussion about ESLint, and it was interesting to see the different perspectives on imposed coding standards, from “it restricts my freedom of expression” to “it makes teams more efficient as they work more as one”.

I think those two perspectives slot roughly onto the scale spectrum. If it’s just you developing, then by all means use whatever style you feel like using. But if you’re part of a larger team whose members have to work with each other’s code, imposed coding standards do make a lot of sense. The OpenUI5 project has some coding contribution guidelines as well as ESLint rules, well worth checking out, and pretty important if you want to contribute to UI5. It’s also worth considering them for your own UI5 applications. One advantage of adopting the OpenUI5 project’s guidelines and rules is that when you cross the path from your codebase into the underlying UI5 toolkit, the transition won’t be as jarring.

Example XML View

The ESLint rules, and ESLint in general would cause this post to be a lot longer than I want, so instead I’ll look at some non-JavaScript conventions that I like to try and impose, at least upon myself. In particular I’ll look at the style for XML View definitions. Here’s part a sample XML View, which I’ll use to illustrate the style for which I strive. Note that the “»” character represents a tab (I have the list mode turned on in my editor to show invisibles).

(45)

In the following, each prefix represents the line number(s) to which I’m referring.

1: The correct namespace for a View is “sap.ui.core.mvc”, not “sap.ui.core” as you might have seen in older documentation and code examples.

2: The controllerName attribute should be the first attribute for the View element. If there is no controller then obviously this attribute won’t be present. It just makes it slightly quicker to look for the controller reference if it’s going to be consistently in the same place.

3-5: All the namespace declarations should be in a contiguous chunk. There are other attributes that might appear for a View element, that’s fine, as long as they’re not interspersed amongst the namespace declarations. Ensure any other attributes appear before the namespace declarations.

(46)

Also, don’t specify a namespace declaration unless you’re going to use it. (In this example, I’m using all of them; you just can’t see the use of the “core” here as it’s on line 60, not in the screenshot).

5: The default XML namespace for any given XML View should be the one that is dominant in the file, or “sap.m”. If you’re building responsive UI5 apps, you’re going to need a good reason for “sap.m” not to be the dominant library. Also, it should be the last attribute in the View element, with a closing angle bracket directly following. (Unlike the use of other angle-bracket powered markup (such as HTML) in UI5, this is a rule that can be applied consistently. With the UI5 bootstrap in HTML, I like to have the closing angle bracket on a separate line, in the

‘prefix-comma’ style from ABAP and other code, so I can add further data attributes without causing diff confusion.)

1-5, 6-7, 11-13 etc: All attributes should appear on lines of their own, indented appropriately.

13: When closing an element directly (like this: <element /> rather than this: <element>…</element>), a space should be used before the closing “/>”.

8, 17, 22, 29, etc: All aggregation elements should be used explicitly. Don’t omit implicit default aggregations for controls; instead, specify them. In this example, I’m using a sap.m.Page control, with the “subHeader” and “content” aggregations. While the “subHeader” aggregation must be specified explicitly anyway, the “content” aggregation is default and doesn’t need to be, but I do anyway. The same goes for the sap.m.List control’s “items” aggregation.

18: Contrary to the rule about attributes being on their own separate lines, there’s an exception to this which is for the id attribute. If it exists, put it on the same line as the opening part of the control’s element.

25: Unless there’s a good reason not to, create the names for your event handler functions using an “on” prefix (like here: “onSelect”). This way they’re consistent with the builtin view lifecycle event functions such as “onInit”.

31-34: When writing complex embedded binding syntax, put each property of the map on a separate line, in the same way you’d write a map in JavaScript. Use spaces before and after the colons.

1-34: Use double quotes throughout; the only place you’ll then use single quotes is within embedded binding syntax. Also … I know this is the subject of much debate, but the OpenUI5’s project standard specifies tabs for indentation. It came as a shock to me at first, but I have now embraced it :-)

(47)

Conclusion

I have no doubt caused some outrage to some of you, but hopefully just as much agreement with others. For me, this sample XML View is easy to read, a lot easier than some of the Fiori views that are generated from templates, for example. What are your standards?

(48)

Day 17 - UI5 and Fiori – The Story of Open and Free

by John Appleby

DJ kindly asked me to write a blog for his 30 days of UI5 series to celebrate version 1.30 of UI5. My immediate reaction was what, me, what do I have to add to this subject?

I then realized that I had a little part in the UI5 story thus far and folks might enjoy the story, and the update, of how Fiori became Freeori.

It all started with a late night phone call with Den Howlett, where we discussed, as we sometimes do, the state of the SAP Union.

We became engrossed in a conversation about the new Workday version that had just been released, with its responsive and modern user experience, and wondered how SAP could compete in UX quality. To that end, SAP had recently released Fiori but adoption was poor with just a handful of users navigating the complex licensing policy around it.

At that time, it was necessary to pay for core SAP licenses, Gateway integration licenses and separate Fiori licenses. There were some pros to this – the paid nature of Fiori meant that Fiori was getting development dollars, but it wasn’t getting adoption. Without adoption of a modern user experience, SAP would be in trouble in the mid-term.

From that conversation came a blog post Should SAP Fiori be Freeori? which framed the conversation in a way we believed SAP would understand. That was key to our argument – we believed that Fiori was the solution to renovating the SAP user experience and that charging for it would risk SAP’s long-term future.

What happened next?

Geoff Scott, CEO of ASUG chimed in with "Time for a UX Revolution, Not Evolution" and then Chris Kanaracus, that time at IDG, now working at ASUG, continued the discussion with "SAP users rattle sabers over charges for user-friendly Fiori apps" and did a fantastic job of rallying the user groups and getting great quotes from the ecosystem:

“DSAG’s position is clear. We say [Fiori] must be part of standard maintenance” – Andreas Oczko, DSAG Vice Chairman

“In a cloud world, you’d expect Fiori to be part of the upgrade cycle” – Ray Wang, Constellation Research

Dennis then put the hammer in with "The SAP Fiori or Freeori discussion heats up", comparing a potential $5-700m one time sale with Fiori to the risk of losing lucrative support revenues.

(49)

I received a few back-channel messages about this, suggesting that things would move, and sure enough, SAP opened up the Fiori product to all customers at no charge. What incredible news.

What does this look like one year on?

The concern my colleagues at SAP had was that charging for Fiori ensured that there was attention to the development. However the reverse hasn’t caused an issue. On the contrary, Fiori has more investment and Sam Yen’s User eXperience group have gone from strength to strength.

SAP S/4HANA has been released and Fiori is at the center of the user experience. The core UI5 and Fiori technologies have significant investments and with UI5 1.30 we see new functionality – just check out the release notes to see the extent! They include a focus on performance improvements and new page styles.

Personally, I’m incredibly proud of the individuals in the SAP ecosystem who have worked on this. The impact of renovating the SAP User eXperience shouldn’t be underestimated.

(50)

Day 18 - MVC – Model View Controller, Minimum Viable

Code

by DJ Adams

The solid Model View Controller implementation in UI5 forces the separation of concerns. The logical place for models, views and controllers are files, in (usually) separate folders. Views, with specific file extensions, in a folder that’s usually called “views”, and controllers, with specific file extensions, in a folder called “controllers”. And models elsewhere too.

This means that if you’re wanting to try something out quickly, and it’s a little bit more than a Hello

World construction, then you’re off creating files and folders from the start before you can properly start thinking about the actual app idea you want to explore.

That is, unless you use a “Minimum Viable Code” technique. I like to think that it’s due to a combination of the three great virtues of a programmer (laziness, impatience and hubris) that led to this approach :-).

Creating a folder structure and getting the right files in place does not go well with the “quickly” part of “try something out quickly”. Trying something out, for me, means ideally using just a single file. It’s fast, you can see everything in one place, and you’re not creating unnecessary clutter. But when I want to try something out also, I also want to ensure that the code I write is clean and separated. Which for me implies declarative views and fragments in XML.

Luckily, for nearly all of the cases where I’ve wanted to try something out, I’ve found that this single file technique works well. I can have one or more views, and fragments, all declared in XML, and one or more controllers too. And within that space I can declare models too.

Here’s how it works:

● I start out with a skeletal index.html with a UI5 bootstrap already there, and the HTML body element defined properly

● I add a simple triple (or tripel) of : view, corresponding controller, and what I call ‘startup code’

● I can then add controls to the view, functions to the controller, and off I go

(51)

● I use jQuery to identify the XML views and fragments, and construct the view instances in UI5 that way

And here’s an example:

(52)

Here’s a brief rundown of what you see:

30DaysOfUI5

30 Days of UI5

Celebrating SAPUI5 and OpenUI5's milestone 1.30 release in Autumn 2015

by

DJ Adams, John Murray, Sean Campbell, James Hale, John Appleby, Chris Choy,

Nathan Adams & John Gregory (Bluefin Solutions)

and

Thilo Seidel & Sam Yen (SAP SE)

with a foreword by

Table of Contents

Preface

Foreword by Andreas Kunz

Day 1 - Welcome to 30 Days of UI5!

Day 2 - Expression Binding

Day 3 - Semantic Pages

Day 4 - Creating Native Applications with UI5

Day 5 - OpenUI5 Walkthrough

Day 6 - The App Descriptor

Day 7 - JavaScript Do's and Don'ts for UI5

Day 8 - User Notifications with the Message Popover

Day 9 - Bootstrapping UI5 Locally and in the Cloud

Day 10 - Handling Dates with the Date Picker

Day 11 - Lightweight notifications with the Message Strip

Day 12 - Base Classes in UI5

Day 13 - Multi language support out of the box – UI5’s

pedigree

Day 14 - Speeding up your UI5 app with a Component

preload file

Day 15 - The UI5 Support Tool – Help Yourself!

Day 16 - UI5 and Coding Standards

Day 17 - UI5 and Fiori – The Story of Open and Free

Day 18 - MVC – Model View Controller, Minimum Viable

Code