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 bound to the activity that the user is interacting with.
      It hosts a Service that's running "in the foreground"—the service has called startForeground().
      It hosts a Service that's executing one of its lifecycle callbacks (onCreate(), onStart(), or onDestroy()).
      It hosts a BroadcastReceiver that's executing its onReceive() method.
       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.
      It hosts a Service that's bound to a visible (or foreground) activity.
       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) {
MenuInflaterinflater = getMenuInflater(); inflater.inflate(R.menu.game_menu, menu);
return true;
}
Handling ClickEvents :
@Override
publicbooleanonOptionsItemSelected(MenuItem item) {
 // 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:
       Initialize the ProgressDialog with the class constructor, ProgressDialog(Context).
       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.


Comments

  1. nice blogs ..i am just looking into ur docs , its seems to be very good.
    but why ur copying all the exact content from developer.android.com site :)

    ReplyDelete
    Replies
    1. Rockey ........actually this blog is created for my reference.......so i didn't thought that these many people will read the blog....

      Delete

Post a Comment

Please post comments here:-)

Popular posts from this blog

Android Objective type Question and Answers

Android Questions and Answers for written exams

Android Interview questions