Android: Process and Threads + Some important topics
Processes
and Threads
•
When an application
component starts and the application does not have any other components
running, the Android system starts a new Linux process for the application with
a single thread of execution. By default, all components of the same
application run in the same process and thread (called the "main"
thread). If an application component starts and there already exists a process
for that application (because another component from the application exists),
then the component is started within that process and uses the same thread of execution.
However, you can arrange for different components in your application to run in
separate processes, and you can create additional threads for any process.
Process Lifecycle:
•
Foreground processA
process that is required for what the user is currently doing. A process is
considered to be in the foreground if any of the following conditions are true:
–
It hosts an Activity
that the user is interacting with (the Activity's
onResume()
method has been called).
–
It hosts a Service
that's executing one of its lifecycle callbacks (onCreate(),
onStart(),
or onDestroy()).
•
Visible processA
process that doesn't have any foreground components, but still can affect what
the user sees on screen. A process is considered to be visible if either of the
following conditions are true:
–
It hosts an Activity
that is not in the foreground, but is still visible to the user (its onPause()
method has been called). This might occur, for example, if the foreground
activity started a dialog, which allows the previous activity to be seen behind
it.
•
A visible process is
considered extremely important and will not be killed unless doing so is
required to keep all foreground processes running.
•
Service process
A process that is running a service that has been started with the startService()
method and does not fall into either of the two higher categories. Although
service processes are not directly tied to anything the user sees, they are
generally doing things that the user cares about (such as playing music in the
background or downloading data on the network), so the system keeps them
running unless there's not enough memory to retain them along with all
foreground and visible processes.
•
Background process
A process holding an activity that's not currently visible to the user (the
activity's onStop()
method has been called). These processes have no direct impact on the user
experience, and the system can kill them at any time to reclaim memory for a
foreground, visible, or service process. Usually there are many background
processes running, so they are kept in an LRU (least recently used) list to
ensure that the process with the activity that was most recently seen by the
user is the last to be killed. If an activity implements its lifecycle methods
correctly, and saves its current state, killing its process will not have a
visible effect on the user experience, because when the user navigates back to
the activity, the activity restores all of its visible state. See the Activities
document for information about saving and restoring state.
•
Empty processA
process that doesn't hold any active application components. The only reason to
keep this kind of process alive is for caching purposes, to improve startup
time the next time a component needs to run in it. The system often kills these
processes in order to balance overall system resources between process caches
and the underlying kernel caches
Threads
in android
•
When an application is
launched, the system creates a thread of execution for the application, called
"main." This thread is very important because it is in charge of
dispatching events to the appropriate user interface widgets, including drawing
events. It is also the thread in which your application interacts with
components from the Android UI toolkit (components from the android.widget
and android.view
packages). As such, the main thread is also sometimes called the UI thread.
There are simply two rules to Android's
single thread model:
•
Do not block the UI
thread
•
Do not access the
Android UI toolkit from outside the UI thread
Permissions
•
A basic Android
application has no permissions associated with it, meaning it can not do anything
that would adversely impact the user experience or any data on the device. To
make use of protected features of the device, you must include in your
AndroidManifest.xml one or more <uses-permission>
tags declaring the permissions that your application needs.
<manifest
xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.app.myapp" ><uses-permission
android:name="android.permission.RECEIVE_SMS" /> ...
</manifest>
User
Interface
•
To enforce our own
permissions, we must first declare them in our AndroidManifest.xml using one or
more <permission>
tags.
•
All user interface
elements in an Android app are built using View
and ViewGroup
objects. A View
is an object that draws something on the screen that the user can interact
with. A ViewGroup
is an object that holds other View
(and ViewGroup)
objects in order to define the layout of the interface.
Linear
Layout
•
LinearLayout
is a view group that aligns all children in a single direction, vertically or
horizontally. We can specify the layout direction with the android:orientation
attribute.
•
All children of a LinearLayout
are stacked one after the other, so a vertical list will only have one child
per row, no matter how wide they are, and a horizontal list will only be one
row high (the height of the tallest child, plus padding). A LinearLayout
respects margins between children and the gravity (right, center,
or left alignment) of each child.
Relative
Layout
•
RelativeLayout
is a view group that displays child views in relative positions. The position
of each view can be specified as relative to sibling elements (such as to the
left-of or below another view) or in positions relative to the parent RelativeLayout
area (such as aligned to the bottom, left of center).
•
A RelativeLayout
is a very powerful utility for designing a user interface because it can
eliminate nested view groups and keep your layout hierarchy flat, which
improves performance. If we find ourself using several nested LinearLayout
groups, we may be able to replace them with a single RelativeLayout.
List
View
•
ListView
is a view group that displays a list of scrollable items. The list items are
automatically inserted to the list using an Adapter
that pulls content from a source such as an array or database query and
converts each item result into a view that's placed into the list.
•
Using a Loader
•
Using a CursorLoader
is the standard way to query a Cursor
as an asynchronous task in order to avoid blocking your app's main thread with
the query. When the CursorLoader
receives the Cursor
result, the LoaderCallbacks
receives a callback to onLoadFinished(),
which is where you update your Adapter
with the new Cursor
and the list view then displays the results.
•
Although the CursorLoader
APIs were first introduced in Android 3.0 (API level 11), they are also
available in the Support
Library so that your app may use them
while supporting devices running Android 1.6 or higher.
Grid
View &EventListners
•
GridView
is a ViewGroup
that displays items in a two-dimensional, scrollable grid. The grid items are
automatically inserted to the layout using a ListAdapter.
•
An event listener is an
interface in the View
class that contains a single callback method. These methods will be called by
the Android framework when the View to which the listener has been registered
is triggered by user interaction with the item in the UI.
•
onClick() From View.OnClickListener.
This is called when the user either touches the item (when in touch mode), or
focuses upon the item with the navigation-keys or trackball and presses the
suitable "enter" key or presses down on the trackball.
•
onLongClick() From View.OnLongClickListener.
This is called when the user either touches and holds the item (when in touch
mode), or focuses upon the item with the navigation-keys or trackball and
presses and holds the suitable "enter" key or presses and holds down
on the trackball (for one second).
•
onFocusChange() From View.OnFocusChangeListener.
This is called when the user navigates onto or away from the item, using the
navigation-keys or trackball.
•
onKey() From View.OnKeyListener.
This is called when the user is focused on the item and presses or releases a
hardware key on the device.
•
onTouch() From View.OnTouchListener.
This is called when the user performs an action qualified as a touch event,
including a press, a release, or any movement gesture on the screen (within the
bounds of the item).
•
onCreateContextMenu()
From View.OnCreateContextMenuListener.
This is called when a Context Menu is being built
Menus
•
Beginning with Android
3.0 (API level 11), Android-powered devices are no longer required to provide a
dedicated Menu button. With this change, Android apps should migrate
away from a dependence on the traditional 6-item menu panel and instead provide
an action bar to present common user actions.
Options
menu and action bar
•
The options menu is the
primary collection of menu items for an activity. It's where you should place
actions that have a global impact on the app, such as "Search,"
"Compose email," and "Settings." If you're developing for
Android 2.3 or lower, users can reveal the options menu panel by pressing the Menu
button.
•
On Android 3.0 and
higher, items from the options menu are presented by the action
bar as a combination of on-screen action
items and overflow options. Beginning with Android 3.0, the Menu button
is deprecated (some devices don't have one), so you should migrate toward using
the action bar to provide access to actions and other options.
•
Popup menu :A
popup menu displays a list of items in a vertical list that's anchored to the
view that invoked the menu. It's good for providing an overflow of actions that
relate to specific content or to provide options for a second part of a
command.
•
Context
menu and contextual action mode : A context menu
is a floating menu that appears when the user performs a long-click on an
element. It provides actions that affect the selected content or context frame.
Defining menu in xml:
<?xml version="1.0"
encoding="utf-8"?><menu
xmlns:android="http://schemas.android.com/apk/res/android"><item
android:id="@+id/new_game" android:icon="@drawable/ic_new_game"
android:title="@string/new_game"
android:showAsAction="ifRoom"/><item
android:id="@+id/help" android:icon="@drawable/ic_help"
android:title="@string/help" /></menu>
Creating a Options Menu
•
If you've developed
your application for Android 2.3.x (API level 10) or lower, the contents
of your options menu appear at the bottom of the screen when the user presses
the Menu button, as shown in figure 1. When opened, the first visible
portion is the icon menu, which holds up to six menu items. If your menu
includes more than six items, Android places the sixth item and the rest into
the overflow menu, which the user can open by selecting More.
•
If you've developed
your application for Android 3.0 (API level 11) and higher, items from
the options menu are available in the action
bar. By default, the system places all
items in the action overflow, which the user can reveal with the action
overflow icon on the right side of the action bar (or by pressing the device Menu
button, if available). To enable quick access to important actions, you can
promote a few items to appear in the action bar by adding
android:showAsAction="ifRoom" to the corresponding <item>
elements .
Example:
@Override
publicbooleanonCreateOptionsMenu(Menu
menu) {
return true;
}
Handling ClickEvents :
@Override
publicbooleanonOptionsItemSelected(MenuItem
item) {
// Handle item selection
// Handle item selection
switch (item.getItemId()) {
caseR.id.new_game: newGame();
return true;
caseR.id.help:
showHelp();
return true;
default:
returnsuper.onOptionsItemSelected(item);
}
}
Changing
Menu at RunTime
•
If we want to modify
the options menu based on events that occur during the activity lifecycle, we
can do so in the onPrepareOptionsMenu()
method. This method passes us the Menu
object as it currently exists so we can modify it, such as add, remove, or
disable items. (Fragments also provide an onPrepareOptionsMenu()
callback.)
Creating Contextual
Menus
•
A contextual menu
offers actions that affect a specific item or context frame in the UI.
•
There are two ways to
provide contextual actions:
•
In a floating context
menu. A menu appears as a floating list of menu items (similar to a dialog)
when the user performs a long-click (press and hold) on a view that declares
support for a context menu. Users can perform a contextual action on one item at
a time.
•
In the contextual
action mode. This mode is a system implementation of ActionMode
that displays a contextual action bar at the top of the screen with
action items that affect the selected item(s). When this mode is active, users
can perform an action on multiple items at once (if your app allows it).
Dialogs
•
A dialog is usually a
small window that appears in front of the current Activity. The underlying
Activity loses focus and the dialog accepts all user interaction. Dialogs are
normally used for notifications that should interrupt the user and to perform
short tasks that directly relate to the application in progress .
•
AlertDialog : A dialog
that can manage zero, one, two, or three buttons, and/or a list of selectable
items that can include checkboxes or radio buttons. The AlertDialog is capable
of constructing most dialog user interfaces and is the suggested dialog type.
•
ProgressDialog :A
dialog that displays a progress wheel or progress bar.
•
DatePickerDialog : A
dialog that allows the user to select a date.
•
TimePickerDialog : A
dialog that allows the user to select a time.
Creating an Alert Dialog:
•
An AlertDialog
is an extension of the Dialog
class. It is capable of constructing most dialog user interfaces and is the
suggested dialog type. we should use it for dialogs that use any of the
following features:
•
A title
•
A text message
•
One, two, or three
buttons
•
A list of selectable
items (with optional checkboxes or radio buttons).
Example:
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage("Are you sure you want to exit?")
.setCancelable(false)
.setPositiveButton("Yes", new
DialogInterface.OnClickListener() {
public void onClick(DialogInterface
dialog, int id) {
MyActivity.this.finish();
}
})
.setNegativeButton("No", new DialogInterface.OnClickListener()
{
public void onClick(DialogInterface
dialog, int id) {
dialog.cancel();
}
});
AlertDialog alert = builder.create();
Creating
a progress Dialog
•
A ProgressDialog
is an extension of the AlertDialog
class that can display a progress animation in the form of a spinning wheel,
for a task with progress that's undefined, or a progress bar, for a task that
has a defined progression. The dialog can also provide buttons, such as one to
cancel a download.
•
ProgressDialog dialog =
ProgressDialog.show(MyActivity.this, "", "Loading. Please
wait...", true);
Showing a ProgressBar
•
To show the progression
with an animated progress bar:
•
Set the progress style
to "STYLE_HORIZONTAL" with setProgressStyle(int)
and set any other properties, such as the message.
•
When you're ready to
show the dialog, call show()
or return the ProgressDialog from the onCreateDialog(int)
callback.
•
You can increment the
amount of progress displayed in the bar by calling either setProgress(int)
with a value for the total percentage completed so far or incrementProgressBy(int)
with an incremental value to add to the total percentage completed so far.
Creating a Custom Dialog
•
ProgressDialogprogressDialog;
progressDialog = new ProgressDialog(mContext);
progressDialog.setProgressStyle(ProgressDialog.STYLE_HORIZONTAL);
progressDialog.setMessage("Loading...");
progressDialog.setCancelable(false);
•
Context mContext =
getApplicationContext();
•
Dialog dialog = new
Dialog(mContext); dialog.setContentView(R.layout.custom_dialog);
•
dialog.setTitle("Custom
Dialog");
Action Bar
•
The primary goals of
the action bar are to
•
Provide a dedicated
space for identifying the application brand and user location.
•
Provide consistent
navigation and view refinement across different applications.
•
Make key actions for
the activity (such as "search", "create",
"share", etc.) prominent and accessible to the user in a predictable
way.
nice blogs ..i am just looking into ur docs , its seems to be very good.
ReplyDeletebut why ur copying all the exact content from developer.android.com site :)
Rockey ........actually this blog is created for my reference.......so i didn't thought that these many people will read the blog....
Delete