MY mENU


Monday 2 April 2012

Activities in android apps

Activities are described by subclasses of the android.app.Activity class, which is an indirect subclass of the abstract android.content.Context class.
NOTE: Context is an abstract class whose methods let apps access global information about their environments (such as their resources and filesystems), and allow apps to perform contextual operations, such as launching activities and services, broadcasting intents, and opening private files.

Activity subclasses override various Activity lifecycle callback methods that Android calls during the life of an activity. For example, the SimpleActivity class extends Activity and also overrides the void onCreate(Bundle bundle) and void onDestroy() lifecycle callback methods.

import android.app.Activity;
import android.os.Bundle;
public class SimpleActivity extends Activity
{
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState); // Always call superclass method first.
System.out.println("onCreate(Bundle) called");
}
@Override
public void onDestroy()
{
super.onDestroy(); // Always call superclass method first.
System.out.println("onDestroy() called");
}
}

The overriding onCreate(Bundle) and onDestroy() methods invoke their superclass counterparts, a pattern that must be followed when overriding the void onStart(), void onRestart(), void onResume(), void onPause(), and void onStop() lifecycle callback methods.

1. onCreate(Bundle) is called when the activity is first created. This method is used to create the activity’s user interface, create background threads as needed, and perform other global initialization. onCreate() is passed an android.os.Bundle object containing the activity’s previous state, if that state was captured; otherwise, the null reference is passed. Android always calls the onStart() method after calling onCreate(Bundle).

2. onStart() is called just before the activity becomes visible to the user. Android calls the onResume() method after calling onStart() when the activity comes to the foreground, and calls the onStop() method after onStart() when the activity becomes hidden.

3. onRestart() is called after the activity has been stopped, just prior to it being started again. Android always calls onStart() after calling onRestart().

4. onResume() is called just before the activity starts interacting with the user. At this point, the activity has the focus and user input is directed to the activity. Android always calls the onPause() method after calling onResume(), but only when the activity must be paused.

5. onPause() is called when Android is about to resume another activity. This method is typically used to persist unsaved changes, stop animations that might be consuming processor cycles, and so on. It should perform its job quickly, because the next activity won’t be resumed until it returns. Android calls onResume() after calling onPause() when the activity starts interacting with the user, and calls onStop() when the activity becomes invisible to the user.

6. onStop() is called when the activity is no longer visible to the user. This may happen because the activity is being destroyed, or because another activity (either an existing one or a new one) has been resumed and is covering the activity. Android calls onRestart() after calling onStop(), when the activity is coming back to interact with the user, and calls the onDestroy() method when the activity is going away.

7. onDestroy() is called before the activity is destroyed, unless memory is tight and Android is forced to kill the activity’s process. In this scenario, onDestroy() is never called. If onDestroy() is called, it will be the final call that the activity ever receives.

NOTE: Android can kill the process hosting the activity at any time after onPause(), onStop(), or onDestroy() returns. An activity is in a killable state from the time onPause() returns until the time onResume() is called. The activity won’t again be killable until onPause() returns.

These seven methods define an activity’s entire lifecycle and describe the following three nested loops:

- The entire lifetime of an activity is defined as everything from the first call to onCreate(Bundle) through to a single final call to onDestroy(). An activity performs all of its initial setup of “global” state in
onCreate(Bundle), and releases all remaining resources in onDestroy(). For example, if the activity has a thread running in the background to download data from the network, it might create that thread in onCreate(Bundle) and stop the thread in onDestroy().

- The visible lifetime of an activity is defined as everything from a call to onStart() through to a corresponding call to onStop(). During this time, the user can see the activity onscreen, although it might not be in the foreground interacting with the user. Between these two methods, the activity can maintain resources that are needed to show itself to the user. For example, it can register a broadcast receiver in onStart() to monitor for changes that impact its user interface, and unregister this object in onStop() when the user can no longer see what the activity is displaying. The onStart() and onStop() methods can be called multiple times, as the activity alternates between being visible to and being hidden from the user.

- The foreground lifetime of an activity is defined as everything from a call to onResume() through to a corresponding call to onPause(). During this time, the activity is in front of all other activities onscreen and is interacting with the user. An activity can frequently transition between the resumed and paused states; for example, onPause() is called when the device goes to sleep or when a new activity is started, and onResume() is called when an activity result or a new intent is delivered. The code in these two methods should be fairly lightweight.

NOTE: Each lifecycle callback method is a hook that an activity can override to perform appropriate work. All activities must implement onCreate(Bundle) to carry out the initial setup when the activity object is first instantiated. Many activities also implement onPause() to commit data changes and otherwise prepare to stop interacting with the user.

 The lifecycle of an activity reveals that there’s no guarantee of onDestroy() being called. Because onDestroy() might not be called, you should not count on using this method as a place for saving data. For example, if an activity is editing a content provider’s data, those edits should typically be committed in onPause(). In contrast, onDestroy() is usually implemented to free resources (such as threads) that are associated with an activity so that a destroyed activity doesn’t leave such things around while the rest of its app is still running. More specifically, the activity is started by creating an Intent object describing an explicit or implicit intent, and by passing this object to Context’s void startActivity(Intent intent) method (launch a new activity; no result is returned when it finishes). Alternatively, the activity could be started by calling Activity’s void startActivityForResult(Intent intent, int requestCode) method. The specified int result is returned to Activity’s void onActivityResult(int requestCode, int resultCode, Intent data) callback method as an argument.

NOTE: The responding activity can look at the initial intent that caused it to be launched by calling Activity’s Intent getIntent() method. Android calls the activity’s void onNewIntent(Intent intent) method (also located in the Activity class) to pass any subsequent intents to the activity. Suppose that you’ve created an app named SimpleActivity, and that this app consists of SimpleActivity. Now suppose that you want to launch SimpleActivity2 from SimpleActivity’s onCreate(Bundle) method. The following code fragment shows you how to start SimpleActivity2:

Intent intent = new Intent(SimpleActivity.this, SimpleActivity2.class);
SimpleActivity.this.startActivity(intent);

The first line creates an Intent object that describes an explicit intent. It initializes this object by passing the current SimpleActivity instance’s reference and SimpleActivity2’s Class instance to the Intent(Context packageContext, Class cls) constructor. The second line passes this Intent object to startActivity(Intent), which is responsible for launching the activity described by SimpleActivity2.class. If startActivity(Intent) was unable to find the specified activity (which shouldn’t happen), it would throw an android.content.ActivityNotFoundException instance. Activities must be declared in the app’s AndroidManifest.xml file or they cannot be started (because they are invisible to Android).

APK file in Android


App Package: Android apps are written in Java. The compiled Java code for an app’s components is further transformed into Dalvik’s DEX format. The resulting code files along with any other required data and resources are subsequently bundled into an App PacKage
(APK), a file identified by the .apk suffix.

An APK is not an app, but is used to distribute an app and install it on a mobile device. It’s not an app because its components may reuse another APK’s components, and (in this situation) not all of the app would reside in a single APK. However, it’s common to refer to an APK as representing a single app.

An APK must be signed with a certificate (which identifies the app’s author) whose private key is held by its developer. The certificate doesn’t need to be signed by a certificate authority. Instead, Android allows APKs to be signed with self-signed certificates, which is typical. 

APK FILES, USER IDS, AND SECURITY: Each APK installed on an Android device is given its own unique Linux user ID, and this user ID remains unchanged for as long as the APK resides on that device. Security enforcement occurs at the process level, so the code contained in any two APKs cannot normally run in the same process, because each APK’s code needs to run as a different Linux user.

However, you can have the code in both APKs run in the same process by assigning the same name of a user ID to the tag’s sharedUserId attribute in each APK’s AndroidManifest.xml file. When you make these assignments, you tell Android that the two packages are to be treated as being the same app, with the same user ID and file permissions. In order to retain security, only two APKs signed with the same signature (and requesting the same sharedUserId value in their manifests) will be given the same user ID.

URL


A URL is a specialization of URI that defines the network location of a specific resource. Unlike a URN, the URL defines how the resource can be obtained. We use URLs every day in the form ofhttp://damnhandy.com, etc. But a URL doesn’t have to be an HTTP URL, it can be ftp://damnhandy.com, smb://damnhandy.com, etc.

URN


A URI identifies a resource by name in a given namespace but not define how the resource maybe obtained. This type of URI is called a URN. You may see URNs used in XML Schema documents to define a namespace, usually using a syntax such as:
xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:example"
Here the targetNamespace use a URN. It defines an identifier to the namespace, but it does not define a location.

URI


A URI identifies a resource either by location, or a name, or both. More often than not, most of us use URIs that defines a location to a resource. The fact that a URI can identify a resources by both name and location has lead to a lot of the confusion in my opinion. A URI has two specializations known as URL and URN

MIME

Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of email to support:
  1. Text in character sets other than ASCII
  2. Non-text attachments
  3. Message bodies with multiple parts
  4. Header information in non-ASCII character sets

Broadcast Receivers in Android

A broadcast receiver is a component that does nothing but receives and reacts to broadcast announcements. Many broadcasts originate in system code; for example, an announcement is made to indicate that the timezone has been changed or the battery power is low, that a picture has been taken, or that the user changed a language preference.
             Apps can also initiate broadcasts. For example, an app may want to let other apps know that some data has finished downloading from the network to the device and is now available for them to use.