What is Bootstrap?
The process of loading and initializing SAPUI5 is called bootstrapping. In this step, we load the SAPUI5 framework from our local webserver and initialize the core modules with the following configuration options:

  • The src attribute of the first <script> tag tells the browser where to find the SAPUI5 core library – it initializes the SAPUI5 runtime and loads additional resources, such as the libraries specified in the data-sap-ui-libs attribute.
  • The SAPUI5 controls support different themes, we choose sap_belize as our default theme.
  • We specify the required UI library sap.m containing the UI controls we need for this tutorial.
  • To make use of the most recent functionality of SAPUI5 we define the compatibility version as edge.
  • We configure the process of “bootstrapping” to run asynchronously.
  • When all resources and libraries are loaded, the SAPUI5 runtime fires the global init event to signal that the library is ready. It is a good practice to listen for this event to trigger your application logic only after the event has been fired.


What is app Descriptor or manifest.json used for?

All application-specific configuration settings are put in a separate descriptor file called manifest.json. 
This clearly separates the application coding from the configuration settings and makes our app even more flexible. For example, all SAP Fiori applications are realized as components and come with a descriptor file to be hosted in the SAP Fiori launchpad.

The content of the manifest.json file is a configuration object in JSON format that contains all global application settings and parameters. The manifest file is called the descriptor for applications, components, and libraries and is also referred to as “descriptor” or “app descriptor” when used for applications. It is stored in the webapp folder and read by SAPUI5 to instantiate the component. There are three important sections defined by namespaces in the manifest.json file:

·         Sap.app : The sap.app namespace contains the following application-specific attributes:
o    Id (mandatory): The namespace of our application component. The ID must not exceed 70 characters. It must be unique and must correspond to the component ID/namespace.
o    Type: Defines what we want to configure, here: an application
o    i18n: Defines the path to the resource bundle file
o    Title: Title of the application in handlebars syntax referenced from the app's resource bundle
o    Description: Short description text what the application does in handlebars syntax referenced from The app's resource bundle
o    Application version: The version of the application to be able to easily update the application later on
·         Sap.ui :-The sap.ui namespace contributes the following UI-specific attributes:
o    Technology: This value specifies the UI technology; in our case we use SAPUI5
o    Device types: Tells what devices are supported by the app: desktop, tablet, phone (all true by default)
o    Supported Themes: An array containing a list of SAP themes supported by the app, for example sap_belize
·         Sap.ui5:- The sap.ui5 namespace adds SAPUI5-specific configuration parameters that are automatically processed by SAPUI5. The most important parameters are:
o    Root View:  The component will automatically instantiate this view and use it as the root for this component
o    Dependencies: Here we declare the UI libraries used in the application
o    Models: In this section of the descriptor we can define models that will be automatically instantiated by SAPUI5 when the app starts. Here we can now define the local resource bundle. We define the name of the model "i18n" as key and specify the bundle file by namespace.

What are Fragments in sapui5 applications?
Fragments are light-weight UI parts (UI subtrees) which can be reused but do not have any controller. This means, whenever you want to define a certain part of your UI to be reusable across multiple views, or when you want to exchange some parts of a view against one another under certain circumstances (different user roles, edit mode vs read-only mode), a fragment is a good candidate, especially where no additional controller logic is required. A fragment can consist of 1 to n controls. At runtime, fragments placed in a view behave like "normal" view content, which means controls inside the fragment will just be included into the view’s DOM when rendered. Fragment does not have any footprint in the DOM tree of the app, and there is no control instance of the fragment itself (only the contained controls). It is simply a container for a set of reusable controls.  The fragment assets are placed in the core namespace, so we add an xml namespace for it inside the Fragment Definition tag. Because dialogs cannot be specified as views, we will create an XML fragment containing the dialog.
For e.g.:


What is Shell container in SapUi5?
We use a shell control as container for our app and use it as our new root element. The shell takes care of visual adaptation of the application to the device’s screen size by introducing a so-called letterbox on desktop screens. Declared in Init method of index.html file
Before using shell.
After using shell.

What is use of Content Density?

We adjust the content density based on the user’s device. SAPUI5 contains different content densities allowing you to display larger controls for touch-enabled devices and a smaller, more compact design for devices that are operated by mouse. In our app, we will detect the device and adjust the density accordingly. SAPUI5 controls can be displayed in multiple sizes, for example in a compact size that is optimized for desktop and non-touch devices, and in a cozy mode that is optimized for touch interaction. The controls look for a specific CSS class in the HTML structure of the application to adjust their size. To prepare the content density feature we will also add a helper method getContentDensityClass. This helper method queries the sap.ui.Device API directly for touch support of the client and returns the CSS ClasssapUiSizeCompact if touch interaction is not supported and sapUiSizeCozy for all other cases. We will use it throughout the application coding to set the proper content density CSS class.

 

 

How FIORI apps adapt to different screen sizes?

By making use of the sap.ui.Device API and defining a device model . The sap.ui.Device API detects the device type (Phone, Tablet, Desktop) based on the user agent and many other properties of the device. Therefore simply reducing the screen size will not change the device type. To test this feature, you will have to enable device emulation in your browser or open it on a real device. We add two new properties EXPANDABLE and EXPANDED in our app.

 

EXPANDABLE is bound to a model named device and the path /system/phone. So the panel can be expanded on phone devices only. The device model is filled with the sap.ui.Device API of SAPUI5.

 

EXPANDED property controls the state of the panel and we use expression binding syntax to close it on phone devices and have the panel expanded on all other devices. The device API of SAPUI5 offers more functionality to detect various device-specific settings,

 

What are custom controls?

Custom controls are small reuseable components that can be created within the app very easily. Due to their nature, they are sometimes also referred to as "notepad” or “on the fly” controls. A custom control is a JavaScript object that has two special sections (metadataand renderer) and a number of methods that implement the functionality of the control.
The metadata section defines the data structure and thus the API of the control. With this meta information on the properties, events, and aggregations of the control SAPUI5 automatically creates setter and getter methods and other convenience functions that can be called within the app.
The renderer defines the HTML structure that will be added to the DOM tree of your app whenever the control is instantiated in a view. It is usually called initially by the core of SAPUI5 and whenever a property of the control is changed. The parameter oRM of the render function is the SAPUI5 render manager that can be used to write strings and control properties to the HTML page

Explain the concept of Routing and Navigation?

We specify a routing configuration for our app and create a separate view for each page of the app, then we connect the views by triggering navigation events.

 

 

We add a new “routing" section to the sap.ui5 part of the descriptor. There are three subsections that define the routing and navigation structure of the app:
  • config
This section contains the global router configuration and default values that apply for all routes and targets. We define the router class that we want to use and where our views are in the app. To load and display views automatically, we also specify which control is used to display the pages and what aggregation should be filled when a new page is displayed.
  • routes
Each route defines a name, a pattern, and one or more targets to navigate to when the route has been hit. The pattern is basically the URL part that matches to the route, we define two routes for our app. The first one is a default route that will show the overview page with the content from the previous steps, and the second is the detail route with the URL pattern detail that will show a new page.
  • targets
A target defines a view that is displayed, it is associated with one or more routes and it can also be displayed manually from within the app. Whenever a target is displayed, the corresponding view is loaded and shown in the app. In our app we simply define two targets with a view name that corresponds to the target name.
What are the types of models used in SAPUI5 applications?
·         JavaScript Object Notation (JSON)
·         Extensible Markup Language (XML)
·         OData
·         Resource model
When JSON, XML and resource models are created, the data they contain is loaded in a single request (either from a file stored locally on the client or by requesting it from a Web server). In other words, after the model's data has been requested, the entire model is known to the application. These models are known as client-side models and tasks such as filtering and sorting are performed locally on the client.
An OData model however, is a server-side model. This means that whenever an application needs data from the model, it must be requested from the server. Such a request will almost never return all the data in the model, typically because this would be far more data than is required by the client application. Consequently, tasks such as sorting and filtering should always be delegated to the server.

What is expression binding?
Expression binding allows you to display a value on the screen that has been calculated from values found in some model object. This way simple formatting or calculations can be inserted directly into the data binding string.

What is Aggregation binding?
Aggregation binding allows a control to be bound to a list within the model data and allows relative binding to the list entries by its child controls.
It will automatically create as many child controls as are needed to display the data in the model using one of the following two approaches:
·         Use template control that is cloned as many times as needed to display the data.
·         Use a factory function to generate the correct control per bound list entry based on the data received at runtime.

What is Element Binding?
When we want to do something with that newly generated list. In most cases, you will use a list to allow the selection of an item and then show the details of that item elsewhere. To achieve this, we use a form with relatively bound controls and bind it to the selected entity via element binding.

What is the difference between standalone apps and apps for Fiori launch pad?
·         If the app runs in FLP it also contains additional features like Save as Tile or Share in SAP Jam that depend on FLP at runtime. This app cannot be run standalone, meaning no index.html file is created but only files for testing the app in the FLP sandbox.
·         Only standalone apps contain an index.html file that is used to start the app.

What is the use of semantic page in FIORI apps?
A Semantic Page is an enhanced sap.m.Page that contains controls with a semantic meaning and displays them according to the SAP Fiori Design Guidelines.
Content specified in the sap.m.semantic.SemanticPage#semanticControls aggregations will be automatically positioned in dedicated sections of the footer or the header of the page, depending on the control's semantics. For example, a semantic button of type sap.m.semantic.PositiveAction will be positioned in the right side of the footer, and in logically correct sequence order with respect to any other included semantic controls.
The full list of what we internally define for semantic content is:
·         Visual properties (e.g. AddAction will be styled as an icon button)
·         Position in the page (UX guidelines specify that some buttons should be in the header only, while others are in the footer or the "share" menu, so we do the correct positioning)
·         Sequence order (UX guidelines define a specific sequence order of semantic controls with respect to each other)
·         Default localized tooltip for icon-only buttons
·         Overflow behavior (UX quidelines define which buttons are allowed to go to the overflow of the toolbar when the screen gets narrower). For icon buttons, we ensure that the text label of the button appears when the button is in overflow, as specified by UX.
·         Screen reader support (invisible text for reading the semantic type)
In addition to the predefined semantic controls, the SemanticPage can host also custom application-provided controls. It preserves most of the API of sap.m.Page for specifying page content.

What is the use of data source section in  manifest.json file?
An external service is defined in the dataSources section of the sap.app namespace. In the example shown below, we configure an OData with protocol version 2.0 and the alias "mainService" in the manifest.json file:









 

 



Comments