Recently I have created two UI5 apps using shell -> views and appContainer -> views. Both results in same output. I\'m confused when to use Shell, App, Container, Page, View, an
You're right, there are a lot of container controls and this can be confusing. So let me give a brief overview:
The shell, no surprise here, is a parent container you can use for views. However, in contrast to other containers, it allows you to limit the app width for large devices. If you want to achieve this for your application, this is your control.
Both, the sap.m.App
and the sap.m.SplitApp
are probably the most used parent controls. In fact, one of them should always be part of your mobile application as they do some HTML modifications to improve the experience on mobile devices (see sap/ui/util/Mobile.init for details). Of course, they can be a child of any Shell. Furthermore, they are important since they extend a sap.m.NavContainer
and therefore offer navigation capabilities. For example, the sap.m.App
has a pages
aggregation. By calling to
, you can simply navigate from one page to another (once you are using routing, this is done by the router). The sap.m.SplitApp
contains two NavContainers. One for the Master Area and another for the Detail Area. In addition, it offers you to manage one background across your application.
Talking about containers one should mention the sap.m.SplitContainer
. Basically, it offers the same capabilities as the sap.m.SplitApp
but since you should have only one App (sap.m.App
or sap.m.SplitApp
) in your application, you can use this control if you want to start a Master/Detail view once you navigate deeper in your application.
The view (and all of its sub types like JSView
, XMLView
, HTMLView
) reflect one simple page or area of a page. In contrast to all other containers, a view may have a controller associated and enables you to implement the View/Controller part of MVC.
Fragments are light-weight variants of a view. They are used like views and they behave similar, but have no controller associated by default. However, you can use simple objects with functions as a controller replacement if necessary. Fragments can be used if you have a particular part of the User Interface you want to externalize to a different file (and maybe reuse it multiple times).
Regarding an architecture of your application, it depends on what you want to display (limited app width, Master/Detail, ...). Almost every combination is possible but I think it is still best practices to have only one App object per application. If you don´t need a feature of one of the Shells you can simply omit it and make your app object the top level container. Some examples for an architecture could look like this:
SplitApp or SplitContainer in a sap.m.Shell
sap.m.Shell
sap.m.SplitApp
sap.ui.core.view.XMLView (Master)
sap.m.Page
sap.ui.core.view.XMLView (Detail)
sap.m.Page
SplitApp or SplitContainer without Shell
sap.m.SplitApp
sap.ui.core.view.XMLView (Master)
sap.m.Page
sap.ui.core.view.XMLView (Detail)
sap.m.Page
sap.m.App in a sap.m.Shell
sap.m.Shell
sap.m.App
sap.ui.core.view.JSView
sap.m.Page
sap.m.App without any Shell
sap.m.App
sap.ui.core.view.XMLView
sap.m.Page