Lines Matching refs:user
74 <li>By default, each application is assigned a unique Linux user ID.
76 that user, only to the application itself — although there are ways
81 It's possible to arrange for two applications to share the same user ID,
113 <dd>An <i>activity</i> presents a visual user interface for one focused endeavor
114 the user can undertake. For example, an activity might present a list of
119 or change settings. Though they work together to form a cohesive user interface,
128 as the first one that should be presented to the user when the application is
137 for example, a pop-up dialog that calls for a user response in the midst of
148 user actions directed at that space. Thus, views are where the activity's
149 interaction with the user takes place. For example, a view might display
150 a small image and initiate an action when the user taps that image. Android
164 <dd>A <i>service</i> doesn't have a visual user interface, but rather runs in
166 play background music as the user attends to other matters, or it might fetch
172 application would probably have one or more activities that allow the user to
191 user interface, they often spawn another thread for time-consuming tasks
199 that the battery is low, that a picture has been taken, or that the user
211 Broadcast receivers do not display a user interface. However, they may start
213 the {@link android.app.NotificationManager} to alert the user. Notifications
214 can get the user's attention in various ways — flashing
258 an activity to present an image to the user or let the user edit some
285 that lets the user pick a photo, it might expect to be returned the chosen
307 the user with the means (a user interface) for controlling the playback.
347 Activities, on the other hand, provide the user interface. They're
348 in a long-running conversation with the user and may remain active,
519 {@code startActivity()}. The map viewer will display the map. When the user
524 To the user, it will seem as if the map viewer is part of the same application
526 that application's process. Android maintains this user experience by keeping
527 both activities in the same <i>task</i>. Simply put, a task is what the user
530 — typically, it's an activity the user selected in the application launcher.
532 the one that is the focus for user actions. When one activity starts another,
534 The previous activity remains in the stack. When the user presses the BACK key,
558 — three under the current activity. The user presses the HOME key, goes
561 Then, after a short period, the user goes back to the home screen and again selects
563 activities in the stack, comes forward. When the user presses the BACK
564 key, the screen does not display the activity the user just left (the root
647 from the user's point of view, you will probably want to assign different
766 intent, the user can always press the BACK key to return to the previous state
768 Activity handles a new intent, the user cannot press the BACK key to
782 If the user leaves a task for a long time, the system clears the task of all
783 activities except the root activity. When the user returns to the task again,
784 it's as the user left it, except that only the initial activity is present.
807 the stack is cleared down to the root activity whenever the user leaves the task
809 {@code alwaysRetainTaskState}. The user always returns to the task in its
818 activity remains part of the task only for the current session. If the user
866 and the user spends some time working in that task. The user then presses
869 the user has no way to return to it.
875 begin a new task and the user presses the HOME key to leave it, there
876 must be some way for the user to navigate back to it again. Some
881 by an external entity that might use this flag, take care that the user
886 For those cases where you don't want the user to be able to return
918 applications share the same Linux user ID and are signed by the same authorities.
929 user actions and the lifecycle notifications discussed later in the
941 the user. Application components running in the process are consequently
948 importance to the user. For example, it more readily shuts down a process
962 work. Since the user interface must always be quick to respond to user actions,
1122 or inactive,or, in the case of activities, visible to the user or
1138 activity that is the focus for the user's actions.</li>
1140 <li><p>It is <em>paused</em> if it has lost focus but is still visible to the user.
1149 visible to the user so its window is hidden and it will often be killed by the
1157 to the user, it must be completely restarted and restored to its previous state.
1179 to commit data changes and otherwise prepare to stop interacting with the user.
1217 During this time, the user can see the activity on-screen, though it may not
1218 be in the foreground and interacting with the user. Between these two methods,
1219 you can maintain resources that are needed to show the activity to the user.
1222 it in {@code onStop()} when the user can no longer see what you are displaying.
1224 as the activity alternates between being visible and hidden to the user.</p></li>
1230 is interacting with the user. An activity can frequently transition between the
1289 <td>Called just before the activity becomes visible to the user.
1300 interacting with the user. At this point the activity is at
1301 the top of the activity stack, with user input going to it.
1316 invisible to the user.</td>
1323 <td>Called when the activity is no longer visible to the user. This
1327 the activity is coming back to interact with the user, or by
1358 should use {@code onPause()} to write any persistent data (such as user
1381 When the system, rather than the user, shuts down an activity to conserve
1382 memory, the user may expect to return to the activity and find it in its
1406 calling it when the instance is actually being destroyed by a user action
1407 (such as pressing the BACK key). In that case, the user won't expect to
1479 user wants to exercise some control over the player or get information
1590 away from the main thread where other components of the user interface run.
1619 what the user is currently doing. A process is considered to be
1623 <li>It is running an activity that the user is interacting with
1628 to the activity that the user is interacting with.</p></li>
1645 required to keep the user interface responsive.
1649 components, but still can affect what the user sees on screen.
1655 to the user (its <code>{@link android.app.Activity#onPause onPause()}</code>
1672 user sees, they are generally doing things that the user cares about (such
1679 that's not currently visible to the user (the Activity object's
1681 These processes have no direct impact on the user experience, and can be killed
1685 was most recently seen by the user is the last to be killed.
1687 state, killing its process will not have a deleterious effect on the user experience.