1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
<meta name="doc-family" content="apps">
<h1>Understand the Architecture</h1>
<p>
Packaged apps integrate closely with a user’s operating system.
They are designed to be run outside of a browser tab,
to run robustly in offline and poor connectivity scenarios and
to have far more powerful capabilities than are available
in a typical web browsing environment.
The app container, programming, and security models
support these packaged app requirements.
</p>
<h2 id="container">App container model</h2>
<p>
The app container describes the visual appearance
and loading behavior of packaged apps.
Packaged apps look different than traditional web apps
because the app container does not show any traditional web page UI controls;
it simply contains a blank rectangular area.
This allows an app to blend with “native” apps on the system,
and it prevents the user from “messing” with the app logic
by manually changing the URL.
</p>
<p>
Packaged apps are loaded differently than web apps.
Both load the same type of content:
HTML documents with CSS and JavaScript;
however, a packaged app is loaded in the app container,
not in the browser tab.
Also, the app container must load the main document
of the packaged app from a local source.
This forces all packaged apps to be at least minimally functional
when offline and it provides a place
to enforce stricter security measures.
</p>
<img src="{{static}}/images/container.png"
width="671"
height="172"
alt="how app container model works">
<h2 id="programming">Programming model</h2>
<p>
The programming model describes the lifecycle
and window behavior of packaged apps.
Similar to native apps,
the goal of this programming model is to give users
and their systems full control over the app lifecycle.
The packaged app lifecycle should be independent
of browser window behavior or a network connection.
</p>
<p>
The “event page” manages the packaged app lifecycle
by responding to user gestures and system events.
This page is invisible, only exists in the background,
and can be closed automatically by the system runtime.
It controls how windows open and close and
when the app is started or terminated.
There can only be one “event page” for a packaged app.
<p>
<p>
<iframe title="YouTube video player" width="610" height="380" src="http://www.youtube.com/embed/yr1jgREbH8U" frameborder="0" allowfullscreen></iframe>
</p>
<h3>App lifecycle at a glance</h3>
<p>
For detailed instructions on how to use the programming model,
see <a href="app_lifecycle.html">Manage App Lifecycle</a>.
Here's a brief summary of the packaged app lifecyle
to get you started:
</p>
<br>
<table border="0">
<tr>
<th scope="col"> Stage </th>
<th scope="col"> Summary </th>
</tr>
<tr>
<td>Installation</td>
<td>User chooses to install the app and explicitly accepts the
<a href="manifest.html#permissions">permissions</a>.
</td>
</tr>
<tr>
<td>Startup</td>
<td>The event page is loaded,
the 'launch' event fires,
and app pages open in windows.
You
<a href="app_lifecycle.html#eventpage">create the windows</a>
that your app requires,
how they look, and how they communicate
with the event page and with other windows.
</td>
</tr>
<tr>
<td>Termination</td>
<td>User can terminate apps at any time
and app can be quickly restored to previous state.
<a href="app_lifecycle.html#H3-7">Stashing data</a>
protects against data loss.</td>
</tr>
<tr>
<td>Update</td>
<td>Apps can be updated at any time;
however, the code that a packaged app is running
cannot change during a startup/termination cycle.</td>
</tr>
<tr>
<td>Uninstallation</td>
<td>User can actively uninstall apps.
When uninstalled, no executing code or
private data is left behind.</td>
</tr>
</table>
<h2 id="security">Security model</h2>
<p>
The packaged apps security model protects users
by ensuring their information is managed
in a safe and secure manner.
<a href="app_csp.html">Comply with CSP</a>
includes detailed information on how to comply with content security policy.
This policy blocks dangerous scripting
reducing cross-site scripting bugs
and protecting users against man-in-the-middle attacks.
</p>
<p>
Loading the packaged app main page locally provides a place
to enforce stricter security than the web.
Like Chrome extensions,
users must explicitly agree to trust the packaged app on install;
they grant the app permission to access and use their data.
Each API that your app uses will have its own permission.
The packaged apps security model also provides the ability
to set up privilege separation on a per window basis.
This allows you to minimize the code in your app
that has access to dangerous APIs,
while still getting to use them.
</p>
<p>
Packaged apps reuse Chrome extension process isolation,
and take this a step further by isolating storage and external content.
Each app has its own private storage area
and can’t access the storage of another app
or personal data (such as cookies) for websites that you use in your browser.
All external processes are isolated from the app.
Since iframes run in the same process as the surrounding page,
they can only be used to load other app pages.
You can use the <code>object</code> tag to
<a href="app_external.html">embed external content</a>;
this content runs in a separate process from the app.
</p>
<p>
<iframe title="YouTube video player" width="610" height="380" src="http://www.youtube.com/embed/EDtiWN42lHs" frameborder="0" allowfullscreen></iframe>
</p>
<p class="backtotop"><a href="#top">Back to top</a></p>
|
