Vous êtes sur la page 1sur 14

Recently i have created two SAPUI5 apps using shell->views and appContainer>views.Both results in same output.

I'm confused when to use Shell and App, Container,


Page, View and SplitApp in SAPUI5. I would like to know the differences between Shell,
App, Container, Page, View and SplitApp in SAPUI5. Also please describe the best
practices of using the above containers from ur experiences. Diagramatical explanation
would help a lot in understanding.

Youre right, there are a lot of container controls and this can be confusing. So let me give a
brief overview:

sap.m.Shell
The shell, no suprise 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. This is an example:

sap.ui.unified.Shell
The unified Shell acts as a rich parent control with an optional secondary content on the left
side, built in search capabilites on the top and many more things. The unified shell looks like
this:

sap.m.App | sap.m.SplitApp
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 jQuery.sap.initMobile 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 capabilites. 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.

sap.m.SplitContainer
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.

sap.ui.core.mvc.View
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.

sap.ui.core.Fragment
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).

Examples
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 dont 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

Vous aimerez peut-être aussi