Have you ever used an application on your smartphone that was extremely simple to use? Have you used an application that was simple and visually appealing? The user experience (UX) of an application is more than how it looks, but it’s how it works.
I consider the most delightful and alluring apps incorporate well-thought, frontend and backend logic. Moreover, these apps keep these two ends separate. SAP has realized the user interface (UI) is more susceptible to change today than ever before. User’s evolving needs and demands can easily reshape an application’s composition and design. With this in mind, the backend should be developed and maintained separately from the frontend, and there should be a clear divide of concerns. Apart from this divide, the individual UI elements of an app can and should be developed separately too.
What is SAPUI5?
The purpose of this blog post is to point out the different development concepts and how a basic SAPUI5 application works and is structured. I’ll regurgitate information from many guides and tutorials that I’ve found helpful along the way. This is a great (and short) “getting started” guide for beginners to SAPUI5. I hope to create many preceding guides on SAPUI5.
How does SAPUI5 work?
To begin, you must understand SAPUI5’s primary, underlying develop concept. SAPUI5 supports the Model View Controller (MVC) concept, “a software architectural pattern for implementing user interfaces”. As a developer, you are encouraged to use the MVC to keep the data model handling, the UI design and the application logic separate. This helps in facilitating UI development in addition to modifying the different parts.
Model: This is the part that is accountable for the management, retrieval, and updating of the data that is being viewed in your application.
View: This part is accountable for interpreting and rendering the initial UI. The view in the context of SAPUI5, generates the presentation to the user based on changes in the model.
What does a view look like? Well, in its directory, views are in stored in the “view” folder and names of XML views always end with *.view.xml (as you’ll see below).
Controller: This is one of the most important parts. This is the part that is accountable for separating the view logic from the data logic. The Controller responds to user interaction and “view events” by adjusting the view and the model. The controller is essentially sending commands to the model to update it’s state, like editing a document in a word processing application. Similar to views, Controllers carry the same name as the related view (if there is a 1:1 relationship). Controller names always end with *controller.js (as you’ll see below).
Fun Fact: MVC was originally developed for desktop-computing, but has since been widely adopted for the World Wide Web.
Okay, that makes sense. But how does it really work?
Okay, before you close this page, I promise the above diagram is quite simple. Now that you know a little about the MVC concept, let’s take a look at how an SAPUI5 app is assembled. Doing so, we’ll take a quick look at each file in turn.
For this exercise we’ll pretend we have just built a basic master-detail SAPUI5 application. First, what’s a master-detail application? Well, if you’ve ever used an iPad or tablet, then you’ve most likely used email on it. Have you ever noticed how the email app on an iPad or tablet displays a list of your emails on the left? It may show the subject, the sender, and a little preview of the email. Then on the right, it displays the email that you selected. That’s an example of a master-detail application. Formally speaking, in a master-detail application, the user can select objects from a list of objects and review the selected objects. Many transactional SAP Fiori apps utilize this type of application layout (as seen below).
Use Diagram 1A to follow along with the steps below.
- We’ve all visited a website. Obviously you’re on a website right now. The first step in loading a SAPUI5 app is when the browser loads the web application’s index.html (which includes no more than minimal code). If you’re not familiar with web development, every website is deployed inside directories within a web server. In addition to that, each web page is an individual file on that web server. When you visit a webpage, the server looks for the default file (index.html) and displays that automatically.
- Subsequent to, it then loads the SAPUI5 toolkit core using the standard variant bootstrap. Bootstrap contains HTML and CSS-based blueprints/patterns for SAPUI5’s typography, forms, buttons, navigation, and other interface components.
Then there is a single function call to exemplify an sap.ui.core.ComponentContainer and places it in the body of the HTML document.
What does the sap.ui.core.ComponentContainer do?
The sap.ui.core.ComponentContainer loads an sap.ui.core.UIComponent which is the self-contained encapsulation of the whole application.
- The Component (which is named sap.ui.core.UIComponent) is defined in the Component.js file in the same folder as index.html; it is found through the specification of resource locations in the bootstrap tag. The Component has metadata defined, which includes application-level configuration and routing information. Routing is the key best practice navigation mechanism and for non-trivial apps supersedes sap.ui.core.EventBus-based navigation, and even shared-controller-based access to the top-level navigation control (such as an sap.m.NavContainer).
So, what do I mean by application-level configuration? Our Component consists of two parts:metadata, and a function that calls our data source when the component is initialized after the index. In previous versions of SAPUI5, additional configuration settings for the app, like the service configuration, the root view, and the routing config, were added to our Component. As of SAPUI5 version 1.30, SAP recommends you to define these settings in a file known as the Manifest (which we will talk about in Part 2).
- Following the initialization of our Component, there are a few models that are created and regulated on our Component. The first is the main model; this connect to our Data Source using oData. Along with the main model, the internalization (i18) is initialized. The internalization file is where texts are loaded from a local resource (file), and device detection based on UI controls.
- Additionally, the initialization of the Router (sap.ui.core.routing.Router) is carried out in the main section of our Component the root view (‘App’) is instantiated. Like all the other views in our imaginary app, the root view is an XML view.
- The basis, foundation view (defined in App.view.xml) is very simple and contains a single sap.m.SplitApp control. Okay slow down – what is sap.m.SplitApp? SplitApp is an additional core component of a SAPUI5 mobile application, besides App control. SplitApp sustains two NavContainers (navigation between Pages or other fullscreen controls) if SAPUI5 runs on a tablet and one NavContainer on a smartphone. The display of master NavContainer depends on the portrait/landscape of the device and the mode of SplitApp.
- Okay – now the fluffy stuff! Now we’ll learn about the part of the app that our users will see in their browser. The visible part of our imaginary app is provided by three main XML views and a fragment. When our app is presented on a device (other than a smartphone), there are two views shown – the master and the detail. At first, this is the Master.view.xml and the Detail.view.xml . Each of these views contain an sap.m.Page. There’s also NotFound.view.xml, to be used when no view can be matched to the resource requested. Similar to that classic “404-Not Found” page you may have come across on other websites. What is an sap.m.page? Well, an sap.m.Page is a basic container for a mobile application screen.
- In the Detail view there is a few SAPUI5 form controls to display the details within our app. For this specific example, this can include the sender and receiver emails. These controls are defined separately in XML fragments.
- Lastly, There is a Formatter.js file. The Formatter contains formatting values that are used in various controls within the Master and Detail views. The css folder contains style.css which has a very small amount of custom CSS, specifically to position the “not found” message further down that it would normally sit. Again, if you’re not familiar with web development, CSS stands for Cascading Style Sheets. CSS can comprise of one or many static files used as a style sheet language for describing the presentation of a page (or document).
Great! What can I take away from all of this?
Using web technology such as HTML5 as our foundation, SAP’s apps can genuinely reshape into many different designs. With that in mind, there are a number of design patterns that SAPUI5 supports; each of them is supported by the sap.m controls. As you have already seen, this is the foundation of SAP Fiori UX. By following a design pattern approach described here, the app that you build will have a consistent feel with existing Fiori apps and new SAPUI5 down the road. As mentioned at the beginning of this post – The user experience of an application is more than how it looks, but it’s how it works.
Now that we have an idea of how our basic SAPUI5 app is structured and works, go dig around at these great resources below. Stay tuned for a the Part 2! Show your love by sharing this post with your peers!
See you soon!
User Experience & HANA Cloud Platform