1. Recevory img is specific to phone model
fastboot flash recovery recovery-clockwork-6.0.3.5-maguro.img
fastboot flash recovery recovery-clockwork-6.0.2.5-crespo.img
2. galaxy nexus boot to bootloader: press power and volume up AND down
http://www.html5rocks.com/en/tutorials/file/dndfiles/#toc-reading-files
HTML5 finally provides a standard way to interact with local files, via the File APIspecification. As example of its capabilities, the File API could be used to create a thumbnail preview of images as they’re being sent to the server, or allow an app to save a file reference while the user is offline. Additionally, you could use client-side logic to verify an upload’s mimetype matches its file extension or restrict the size of an upload.
The spec provides several interfaces for accessing files from a ‘local’ filesystem:
File – an individual file; provides readonly information such as name, file size, mimetype, and a reference to the file handle.FileList – an array-like sequence of File objects. (Think <input type="file" multiple> or dragging a directory of files from the desktop).Blob – Allows for slicing a file into byte ranges.When used in conjunction with the above data structures, the FileReader interface can be used to asynchronously read a file through familiar JavaScript event handling. Thus, it is possible to monitor the progress of a read, catch errors, and determine when a load is complete. In many ways the APIs resemble XMLHttpRequest‘s event model.
The first thing to do is check that your browser fully supports the File API:
// Check for the various File API support.
if (window.File && window.FileReader && window.FileList && window.Blob) {
// Great success! All the File APIs are supported.
} else {
alert('The File APIs are not fully supported in this browser.');
}
Of course, if your app will only use a few of these APIs, modify this snippet accordingly.
The most straightforward way to load a file is to use a standard <input type="file">element. JavaScript returns the list of selected File objects as a FileList. Here’s an example that uses the ‘multiple’ attribute to allow selecting several files at once:
<input type="file" id="files" name="files[]" multiple />
<output id="list"></output>
<script>
function handleFileSelect(evt) {
var files = evt.target.files; // FileList object
// files is a FileList of File objects. List some properties.
var output = [];
for (var i = 0, f; f = files[i]; i++) {
output.push('<li><strong>', escape(f.name), '</strong> (', f.type || 'n/a', ') - ',
f.size, ' bytes, last modified: ',
f.lastModifiedDate ? f.lastModifiedDate.toLocaleDateString() : 'n/a',
'</li>');
}
document.getElementById('list').innerHTML = '<ul>' + output.join('') + '</ul>';
}
document.getElementById('files').addEventListener('change', handleFileSelect, false);
</script>
Example: Using form input for selecting. Try it!
Another technique for loading files is native drag and drop from the desktop to the browser. We can modify the previous example slightly to include drag and drop support.
<div id="drop_zone">Drop files here</div>
<output id="list"></output>
<script>
function handleFileSelect(evt) {
evt.stopPropagation();
evt.preventDefault();
var files = evt.dataTransfer.files; // FileList object.
// files is a FileList of File objects. List some properties.
var output = [];
for (var i = 0, f; f = files[i]; i++) {
output.push('<li><strong>', escape(f.name), '</strong> (', f.type || 'n/a', ') - ',
f.size, ' bytes, last modified: ',
f.lastModifiedDate ? f.lastModifiedDate.toLocaleDateString() : 'n/a',
'</li>');
}
document.getElementById('list').innerHTML = '<ul>' + output.join('') + '</ul>';
}
function handleDragOver(evt) {
evt.stopPropagation();
evt.preventDefault();
evt.dataTransfer.dropEffect = 'copy'; // Explicitly show this is a copy.
}
// Setup the dnd listeners.
var dropZone = document.getElementById('drop_zone');
dropZone.addEventListener('dragover', handleDragOver, false);
dropZone.addEventListener('drop', handleFileSelect, false);
</script>
Example: Using drag and drop for selecting. Try it!
Note: Some browsers treat <input type="file"> elements as native drop targets. Try dragging files onto the input field in the previous example.
Now comes the fun part!
After you’ve obtained a File reference, instantiate a FileReader object to read its contents into memory. When the load finishes, the reader’s onload event is fired and itsresult attribute can be used to access the file data.
FileReader includes four options for reading a file, asynchronously:
FileReader.readAsBinaryString(Blob|File) – The result property will contain the file/blob’s data as a binary string. Every byte is represented by an integer in the range [0..255].FileReader.readAsText(Blob|File, opt_encoding) – The result property will contain the file/blob’s data as a text string. By default the string is decoded as ‘UTF-8’. Use the optional encoding parameter can specify a different format.FileReader.readAsDataURL(Blob|File) – The result property will contain the file/blob’s data encoded as a data URL.FileReader.readAsArrayBuffer(Blob|File) – The result property will contain the file/blob’s data as an ArrayBuffer object.Once one of these read methods is called on your FileReader object, the onloadstart,onprogress, onload, onabort, onerror, and onloadend can be used to track its progress.
The example below filters out images from the user’s selection, callsreader.readAsDataURL() on the file, and renders a thumbnail by setting the ‘src’ attribute to a data URL.
<style>
.thumb {
height: 75px;
border: 1px solid #000;
margin: 10px 5px 0 0;
}
</style>
<input type="file" id="files" name="files[]" multiple />
<output id="list"></output>
<script>
function handleFileSelect(evt) {
var files = evt.target.files; // FileList object
// Loop through the FileList and render image files as thumbnails.
for (var i = 0, f; f = files[i]; i++) {
// Only process image files.
if (!f.type.match('image.*')) {
continue;
}
var reader = new FileReader();
// Closure to capture the file information.
reader.onload = (function(theFile) {
return function(e) {
// Render thumbnail.
var span = document.createElement('span');
span.innerHTML = ['<img src="', e.target.result,
'" title="', escape(theFile.name), '"/>'].join('');
document.getElementById('list').insertBefore(span, null);
};
})(f);
// Read in the image file as a data URL.
reader.readAsDataURL(f);
}
}
document.getElementById('files').addEventListener('change', handleFileSelect, false);
</script>
Example: Reading files. Try it!
Try this example with a directory of images!
In some cases reading the entire file into memory isn’t the best option. For example, say you wanted to write an async file uploader. One possible way to speed up the upload would be to read and send the file in separate byte range chunks. The server component would then be responsible for reconstructing the file content in the correct order.
Lucky for us, the File interface supports a slice method to support this use case. The method takes a starting byte as its first argument, ending byte as its second, and an option content type string as a third.
var blob = file.slice(startingByte, endindByte); reader.readAsBinaryString(blob);
The following example demonstrates reading chunks of a file. Something worth noting is that it uses the onloadend and checks the evt.target.readyState instead of using theonload event.
<style>
#byte_content {
margin: 5px 0;
max-height: 100px;
overflow-y: auto;
overflow-x: hidden;
}
#byte_range { margin-top: 5px; }
</style>
<input type="file" id="files" name="file" /> Read bytes:
<span class="readBytesButtons">
<button data-startbyte="0" data-endbyte="4">1-5</button>
<button data-startbyte="5" data-endbyte="14">6-15</button>
<button data-startbyte="6" data-endbyte="7">7-8</button>
<button>entire file</button>
</span>
<div id="byte_range"></div>
<div id="byte_content"></div>
<script>
function readBlob(opt_startByte, opt_stopByte) {
var files = document.getElementById('files').files;
if (!files.length) {
alert('Please select a file!');
return;
}
var file = files[0];
var start = parseInt(opt_startByte) || 0;
var stop = parseInt(opt_stopByte) || file.size - 1;
var reader = new FileReader();
// If we use onloadend, we need to check the readyState.
reader.onloadend = function(evt) {
if (evt.target.readyState == FileReader.DONE) { // DONE == 2
document.getElementById('byte_content').textContent = evt.target.result;
document.getElementById('byte_range').textContent =
['Read bytes: ', start + 1, ' - ', stop + 1,
' of ', file.size, ' byte file'].join('');
}
};
var blob = file.slice(start, stop + 1);
reader.readAsBinaryString(blob);
}
document.querySelector('.readBytesButtons').addEventListener('click', function(evt) {
if (evt.target.tagName.toLowerCase() == 'button') {
var startByte = evt.target.getAttribute('data-startbyte');
var endByte = evt.target.getAttribute('data-endbyte');
readBlob(startByte, endByte);
}
}, false);
</script>
Example: Slicing a file. Try it!
One of the nice things that we get for free when using async event handling is the ability to monitor the progress of the file read; useful for large files, catching errors, and figuring out when a read is complete.
The onloadstart and onprogress events can be used to monitor the progress of a read.
The example below demonstrates displaying a progress bar to monitor the status of a read. To see the progress indicator in action, try a large file or one from a remote drive.
<style>
#progress_bar {
margin: 10px 0;
padding: 3px;
border: 1px solid #000;
font-size: 14px;
clear: both;
opacity: 0;
-moz-transition: opacity 1s linear;
-o-transition: opacity 1s linear;
-webkit-transition: opacity 1s linear;
}
#progress_bar.loading {
opacity: 1.0;
}
#progress_bar .percent {
background-color: #99ccff;
height: auto;
width: 0;
}
</style>
<input type="file" id="files" name="file" />
<button onclick="abortRead();">Cancel read</button>
<div id="progress_bar"><div class="percent">0%</div></div>
<script>
var reader;
var progress = document.querySelector('.percent');
function abortRead() {
reader.abort();
}
function errorHandler(evt) {
switch(evt.target.error.code) {
case evt.target.error.NOT_FOUND_ERR:
alert('File Not Found!');
break;
case evt.target.error.NOT_READABLE_ERR:
alert('File is not readable');
break;
case evt.target.error.ABORT_ERR:
break; // noop
default:
alert('An error occurred reading this file.');
};
}
function updateProgress(evt) {
// evt is an ProgressEvent.
if (evt.lengthComputable) {
var percentLoaded = Math.round((evt.loaded / evt.total) * 100);
// Increase the progress bar length.
if (percentLoaded < 100) {
progress.style.width = percentLoaded + '%';
progress.textContent = percentLoaded + '%';
}
}
}
function handleFileSelect(evt) {
// Reset progress indicator on new file selection.
progress.style.width = '0%';
progress.textContent = '0%';
reader = new FileReader();
reader.onerror = errorHandler;
reader.onprogress = updateProgress;
reader.onabort = function(e) {
alert('File read cancelled');
};
reader.onloadstart = function(e) {
document.getElementById('progress_bar').className = 'loading';
};
reader.onload = function(e) {
// Ensure that the progress bar displays 100% at the end.
progress.style.width = '100%';
progress.textContent = '100%';
setTimeout("document.getElementById('progress_bar').className='';", 2000);
}
// Read in the image file as a binary string.
reader.readAsBinaryString(evt.target.files[0]);
}
document.getElementById('files').addEventListener('change', handleFileSelect, false);
</script>
Example: Monitoring the progress of a read. Try it!
Tip: To really see this progress indicator in action, try a large file or a resource on a remote drive.
http://developer.android.com/guide/components/tasks-and-back-stack.html
An application usually contains multiple activities. Each activity should be designed around a specific kind of action the user can perform and can start other activities. For example, an email application might have one activity to show a list of new email. When the user selects an email, a new activity opens to view that email.
An activity can even start activities that exist in other applications on the device. For example, if your application wants to send an email, you can define an intent to perform a “send” action and include some data, such as an email address and a message. An activity from another application that declares itself to handle this kind of intent then opens. In this case, the intent is to send an email, so an email application’s “compose” activity starts (if multiple activities support the same intent, then the system lets the user select which one to use). When the email is sent, your activity resumes and it seems as if the email activity was part of your application. Even though the activities may be from different applications, Android maintains this seamless user experience by keeping both activities in the same task.
A task is a collection of activities that users interact with when performing a certain job. The activities are arranged in a stack (the “back stack”), in the order in which each activity is opened.
The device Home screen is the starting place for most tasks. When the user touches an icon in the application launcher (or a shortcut on the Home screen), that application’s task comes to the foreground. If no task exists for the application (the application has not been used recently), then a new task is created and the “main” activity for that application opens as the root activity in the stack.
When the current activity starts another, the new activity is pushed on the top of the stack and takes focus. The previous activity remains in the stack, but is stopped. When an activity stops, the system retains the current state of its user interface. When the user presses the Backbutton, the current activity is popped from the top of the stack (the activity is destroyed) and the previous activity resumes (the previous state of its UI is restored). Activities in the stack are never rearranged, only pushed and popped from the stack—pushed onto the stack when started by the current activity and popped off when the user leaves it using the Back button. As such, the back stack operates as a “last in, first out” object structure. Figure 1 visualizes this behavior with a timeline showing the progress between activities along with the current back stack at each point in time.
Figure 1. A representation of how each new activity in a task adds an item to the back stack. When the user presses the Backbutton, the current activity is destroyed and the previous activity resumes.
If the user continues to press Back, then each activity in the stack is popped off to reveal the previous one, until the user returns to the Home screen (or to whichever activity was running when the task began). When all activities are removed from the stack, the task no longer exists.
Figure 2. Two tasks: Task B receives user interaction in the foreground, while Task A is in the background, waiting to be resumed.
Figure 3. A single activity is instantiated multiple times.
A task is a cohesive unit that can move to the “background” when users begin a new task or go to the Home screen, via theHome button. While in the background, all the activities in the task are stopped, but the back stack for the task remains intact—the task has simply lost focus while another task takes place, as shown in figure 2. A task can then return to the “foreground” so users can pick up where they left off. Suppose, for example, that the current task (Task A) has three activities in its stack—two under the current activity. The user presses the Home button, then starts a new application from the application launcher. When the Home screen appears, Task A goes into the background. When the new application starts, the system starts a task for that application (Task B) with its own stack of activities. After interacting with that application, the user returns Home again and selects the application that originally started Task A. Now, Task A comes to the foreground—all three activities in its stack are intact and the activity at the top of the stack resumes. At this point, the user can also switch back to Task B by going Home and selecting the application icon that started that task (or by selecting the app’s task from the recent apps screen). This is an example of multitasking on Android.
Note: Multiple tasks can be held in the background at once. However, if the user is running many background tasks at the same time, the system might begin destroying background activities in order to recover memory, causing the activity states to be lost. See the following section about Activity state.
Because the activities in the back stack are never rearranged, if your application allows users to start a particular activity from more than one activity, a new instance of that activity is created and pushed onto the stack (rather than bringing any previous instance of the activity to the top). As such, one activity in your application might be instantiated multiple times (even from different tasks), as shown in figure 3. As such, if the user navigates backward using the Back button, each instance of the activity is revealed in the order they were opened (each with their own UI state). However, you can modify this behavior if you do not want an activity to be instantiated more than once. How to do so is discussed in the later section about Managing Tasks.
To summarize the default behavior for activities and tasks:
Navigation Design
For more about how app navigation works on Android, read Android Design’s Navigation guide.
As discussed above, the system’s default behavior preserves the state of an activity when it is stopped. This way, when users navigate back to a previous activity, its user interface appears the way they left it. However, you can—and should—proactively retain the state of your activities using callback methods, in case the activity is destroyed and must be recreated.
When the system stops one of your activities (such as when a new activity starts or the task moves to the background), the system might destroy that activity completely if it needs to recover system memory. When this happens, information about the activity state is lost. If this happens, the system still knows that the activity has a place in the back stack, but when the activity is brought to the top of the stack the system must recreate it (rather than resume it). In order to avoid losing the user’s work, you should proactively retain it by implementing the onSaveInstanceState() callback methods in your activity.
For more information about how to save your activity state, see the Activities document.
The way Android manages tasks and the back stack, as described above—by placing all activities started in succession in the same task and in a “last in, first out” stack—works great for most applications and you shouldn’t have to worry about how your activities are associated with tasks or how they exist in the back stack. However, you might decide that you want to interrupt the normal behavior. Perhaps you want an activity in your application to begin a new task when it is started (instead of being placed within the current task); or, when you start an activity, you want to bring forward an existing instance of it (instead of creating a new instance on top of the back stack); or, you want your back stack to be cleared of all activities except for the root activity when the user leaves the task.
You can do these things and more, with attributes in the <activity> manifest element and with flags in the intent that you pass to startActivity().
In this regard, the principal <activity> attributes you can use are:
taskAffinitylaunchModeallowTaskReparentingclearTaskOnLaunchalwaysRetainTaskStatefinishOnTaskLaunchAnd the principal intent flags you can use are:
In the following sections, you’ll see how you can use these manifest attributes and intent flags to define how activities are associated with tasks and how the behave in the back stack.
Caution: Most applications should not interrupt the default behavior for activities and tasks. If you determine that it’s necessary for your activity to modify the default behaviors, use caution and be sure to test the usability of the activity during launch and when navigating back to it from other activities and tasks with theBack button. Be sure to test for navigation behaviors that might conflict with the user’s expected behavior.
Launch modes allow you to define how a new instance of an activity is associated with the current task. You can define different launch modes in two ways:
startActivity(), you can include a flag in the Intent that declares how (or whether) the new activity should associate with the current task.As such, if Activity A starts Activity B, Activity B can define in its manifest how it should associate with the current task (if at all) and Activity A can also request how Activity B should associate with current task. If both activities define how Activity B should associate with a task, then Activity A’s request (as defined in the intent) is honored over Activity B’s request (as defined in its manifest).
Note: Some launch modes available for the manifest file are not available as flags for an intent and, likewise, some launch modes available as flags for an intent cannot be defined in the manifest.
When declaring an activity in your manifest file, you can specify how the activity should associate with a task using the <activity> element’s launchMode attribute.
The launchMode attribute specifies an instruction on how the activity should be launched into a task. There are four different launch modes you can assign to the launchMode attribute:
"standard" (the default mode)"singleTop"onNewIntent() method, rather than creating a new instance of the activity. The activity can be instantiated multiple times, each instance can belong to different tasks, and one task can have multiple instances (but only if the activity at the top of the back stack is not an existing instance of the activity).For example, suppose a task’s back stack consists of root activity A with activities B, C, and D on top (the stack is A-B-C-D; D is on top). An intent arrives for an activity of type D. If D has the default "standard"launch mode, a new instance of the class is launched and the stack becomes A-B-C-D-D. However, if D’s launch mode is "singleTop", the existing instance of D receives the intent through onNewIntent(), because it’s at the top of the stack—the stack remains A-B-C-D. However, if an intent arrives for an activity of type B, then a new instance of B is added to the stack, even if its launch mode is "singleTop".
Note: When a new instance of an activity is created, the user can press the Back button to return to the previous activity. But when an existing instance of an activity handles a new intent, the user cannot press the Back button to return to the state of the activity before the new intent arrived inonNewIntent().
"singleTask"onNewIntent() method, rather than creating a new instance. Only one instance of the activity can exist at a time.Note: Although the activity starts in a new task, the Back button still returns the user to the previous activity.
"singleInstance"."singleTask", except that the system doesn’t launch any other activities into the task holding the instance. The activity is always the single and only member of its task; any activities started by this one open in a separate task.As another example, the Android Browser application declares that the web browser activity should always open in its own task—by specifying the singleTask launch mode in the <activity> element. This means that if your application issues an intent to open the Android Browser, its activity is not placed in the same task as your application. Instead, either a new task starts for the Browser or, if the Browser already has a task running in the background, that task is brought forward to handle the new intent.
Regardless of whether an activity starts in a new task or in the same task as the activity that started it, the Backbutton always takes the user to the previous activity. However, if you start an activity that specifies thesingleTask launch mode, then if an instance of that activity exists in a background task, that whole task is brought to the foreground. At this point, the back stack now includes all activities from the task brought forward, at the top of the stack. Figure 4 illustrates this type of scenario.
Figure 4. A representation of how an activity with launch mode “singleTask” is added to the back stack. If the activity is already a part of a background task with its own back stack, then the entire back stack also comes forward, on top of the current task.
For more information about using launch modes in the manifest file, see the <activity> element documentation, where the launchMode attribute and the accepted values are discussed more.
Note: The behaviors that you specify for your activity with the launchMode attribute can be overridden by flags included with the intent that start your activity, as discussed in the next section.
When starting an activity, you can modify the default association of an activity to its task by including flags in the intent that you deliver to startActivity(). The flags you can use to modify the default behavior are:
FLAG_ACTIVITY_NEW_TASKStart the activity in a new task. If a task is already running for the activity you are now starting, that task is brought to the foreground with its last state restored and the activity receives the new intent inonNewIntent().
This produces the same behavior as the "singleTask" launchMode value, discussed in the previous section.
FLAG_ACTIVITY_SINGLE_TOPIf the activity being started is the current activity (at the top of the back stack), then the existing instance receives a call to onNewIntent(), instead of creating a new instance of the activity.
This produces the same behavior as the "singleTop" launchMode value, discussed in the previous section.
FLAG_ACTIVITY_CLEAR_TOPIf the activity being started is already running in the current task, then instead of launching a new instance of that activity, all of the other activities on top of it are destroyed and this intent is delivered to the resumed instance of the activity (now on top), through onNewIntent()).
There is no value for the launchMode attribute that produces this behavior.
FLAG_ACTIVITY_CLEAR_TOP is most often used in conjunction with FLAG_ACTIVITY_NEW_TASK. When used together, these flags are a way of locating an existing activity in another task and putting it in a position where it can respond to the intent.
Note: If the launch mode of the designated activity is "standard", it too is removed from the stack and a new instance is launched in its place to handle the incoming intent. That’s because a new instance is always created for a new intent when the launch mode is "standard".
The affinity indicates which task an activity prefers to belong to. By default, all the activities from the same application have an affinity for each other. So, by default, all activities in the same application prefer to be in the same task. However, you can modify the default affinity for an activity. Activities defined in different applications can share an affinity, or activities defined in the same application can be assigned different task affinities.
You can modify the affinity for any given activity with the taskAffinity attribute of the <activity> element.
The taskAffinity attribute takes a string value, which must be unique from the default package name declared in the <manifest> element, because the system uses that name to identify the default task affinity for the application.
The affinity comes into play in two circumstances:
FLAG_ACTIVITY_NEW_TASK flag.A new activity is, by default, launched into the task of the activity that called startActivity(). It’s pushed onto the same back stack as the caller. However, if the intent passed to startActivity() contains theFLAG_ACTIVITY_NEW_TASK flag, the system looks for a different task to house the new activity. Often, it’s a new task. However, it doesn’t have to be. If there’s already an existing task with the same affinity as the new activity, the activity is launched into that task. If not, it begins a new task.
If this flag causes an activity to begin a new task and the user presses the Home button to leave it, there must be some way for the user to navigate back to the task. Some entities (such as the notification manager) always start activities in an external task, never as part of their own, so they always putFLAG_ACTIVITY_NEW_TASK in the intents they pass to startActivity(). If you have an activity that can be invoked by an external entity that might use this flag, take care that the user has a independent way to get back to the task that’s started, such as with a launcher icon (the root activity of the task has aCATEGORY_LAUNCHER intent filter; see the Starting a task section below).
allowTaskReparenting attribute set to "true".In this case, the activity can move from the task it starts to the task it has an affinity for, when that task comes to the foreground.
For example, suppose that an activity that reports weather conditions in selected cities is defined as part of a travel application. It has the same affinity as other activities in the same application (the default application affinity) and it allows re-parenting with this attribute. When one of your activities starts the weather reporter activity, it initially belongs to the same task as your activity. However, when the travel application’s task comes to the foreground, the weather reporter activity is reassigned to that task and displayed within it.
Tip: If an .apk file contains more than one “application” from the user’s point of view, you probably want to use the taskAffinity attribute to assign different affinities to the activities associated with each “application”.
If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, only the root activity is restored. The system behaves this way, because, after an extended amount of time, users likely have abandoned what they were doing before and are returning to the task to begin something new.
There are some activity attributes that you can use to modify this behavior:
alwaysRetainTaskState"true" in the root activity of a task, the default behavior just described does not happen. The task retains all activities in its stack even after a long period.clearTaskOnLaunch"true" in the root activity of a task, the stack is cleared down to the root activity whenever the user leaves the task and returns to it. In other words, it’s the opposite ofalwaysRetainTaskState. The user always returns to the task in its initial state, even after a leaving the task for only a moment.finishOnTaskLaunchclearTaskOnLaunch, but it operates on a single activity, not an entire task. It can also cause any activity to go away, including the root activity. When it’s set to "true", the activity remains part of the task only for the current session. If the user leaves and then returns to the task, it is no longer present.You can set up an activity as the entry point for a task by giving it an intent filter with"android.intent.action.MAIN" as the specified action and "android.intent.category.LAUNCHER" as the specified category. For example:
<activity ... > <intent-filter ... > <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> ... </activity>
An intent filter of this kind causes an icon and label for the activity to be displayed in the application launcher, giving users a way to launch the activity and to return to the task that it creates any time after it has been launched.
This second ability is important: Users must be able to leave a task and then come back to it later using this activity launcher. For this reason, the two launch modes that mark activities as always initiating a task,"singleTask" and “"singleInstance", should be used only when the activity has an ACTION_MAIN and aCATEGORY_LAUNCHER filter. Imagine, for example, what could happen if the filter is missing: An intent launches a"singleTask" activity, initiating a new task, and the user spends some time working in that task. The user then presses the Home button. The task is now sent to the background and is not visible. Now the user has no way to return to the task, because it is not represented in the application launcher.
For those cases where you don’t want the user to be able to return to an activity, set the <activity> element’sfinishOnTaskLaunch to "true" (see Clearing the stack).
http://www.intridea.com/blog/2011/6/16/android-understanding-activity-launchmode
http://developer.android.com/guide/topics/manifest/activity-element.html#lmode
| Use Cases | Launch Mode | Multiple Instances? | Comments |
|---|---|---|---|
| Normal launches for most activities | “standard“ |
Yes | Default. The system always creates a new instance of the activity in the target task and routes the intent to it. |
“singleTop“ |
Conditionally | If an instance of the activity already exists at the top of the target task, the system routes the intent to that instance through a call to itsonNewIntent() method, rather than creating a new instance of the activity. |
|
| Specialized launches (not recommended for general use) |
“singleTask“ |
No | The system creates the activity at the root of a new task and routes the intent to it. However, if an instance of the activity already exists, the system routes the intent to existing instance through a call to its onNewIntent()method, rather than creating a new one. |
“singleInstance“ |
No | Same as “singleTask", except that the system doesn’t launch any other activities into the task holding the instance. The activity is always the single and only member of its task. |
Before I dive into the launch mode of an activity, we need to first understand the term, ‘Task’. A task is the stack (“Last in, First out”) which contains a collection of activity instances. Normally, when a user starts an app a new task will be created, and the first activity instance is called as a root of the task. The Android system can hold multiple tasks at the same time and only one task is in the foreground. Similar to a double click of the home key on iOS, if you long press the HOME key on Android you’ll be presented with a list of your currently running applications. You can select any one of these applications (which are currently running in the background) in order to bring it to the foreground and interact with the app! Of course, because background tasks do tend to use up your processor cycles you should try to keep your backgrounded apps to a minimum to ensure your phone performs optimally.
Now let’s look at the launch mode of an activity. Launch mode allows you to define how a new instance or the existing instance of an activity is associated with the current task. The activity launch mode has four valid values:
| 1 |
<activity android:launchMode = [“standard” | “singleTop” | “singleTask” | “singleInstance”] ../>
|
The ‘standard’ is the default value. The four values fall into two groups:
Multiple instances of the activity class can be instantiated and multiple instances can be added to the same task or different tasks. This is the common mode for most of the activities.
The difference from ‘standard’ is, if an instance of activity already exists at the top of the current task and system routes intent to this activity, no new instance will be created because it will fire off an onNewIntent() method instead of creating a new object. Let’s take the Twitter-oauth integration as example. Suppose we have the following NewsDetailActivity declared:
| 12345678 |
<activity android:name=”.NewsDetailActivity” android:launchMode=”singleTop”>
<intent-filter>
<action android:name=”android.intent.action.VIEW”></action>
<category android:name=”android.intent.category.DEFAULT”></category>
<category android:name=”android.intent.category.BROWSABLE”></category>
<data android:scheme=”oauth” android:host=”twitt”></data>
</intent-filter>
</activity>
|
And in the activity we will have the following code to start the oAuth process which will bring up the browser to visit Twitter’s authorization page:
So if a user goes to this activity in the current task (let’s say Task #1), a new instance of NewsDetailActivity will be pushed to the top. Now start the oAuth process and the Android system routes the intent to the default Android Browser application, whose launch mode is ‘singleTask’; that means a new Task begins for the browser activity, let’s say Task #2. Hence the ‘NewDetailActivity’ is still on top of the Task #1.
After the user finishes the authorization on Twitter’s page, the customized callback url ‘oauth://twitter’ will be invoked. Because NewsDetailActivity declares support for that data type, the system routes the intent to the ‘NewsDetailActivity’. Since NewsDetailActivity’s launch mode is ‘singleTop’, and the top instance on Task #1 will be reused, its onNewIntent() method will be invoked to continue oAuth’s last step. Here is the code for that:
| 1234567891011121314151617181920212223 |
protected void onNewIntent(Intent intent) {
super.onNewIntent(intent);
Uri uri = intent.getData();
if (uri != null && uri.toString().startsWith(CALLBACK_URL)) {
String verifier = uri.getQueryParameter(“oauth_verifier”);
try {
//load other persisted data goes here
….
//get the request-token from prefs and request the access token
TwitterFactory twitter = new TwitterFactory().getInstance();
requestToken = prefsManager.getRequestToken();
prefsManager.clearTwitterRequestToken();
twitter4j.auth.AccessToken accessToken = twitter.getOAuthAccessToken(requestToken, verifier);
// save the access token
prefsManager.saveTwitterOauth(accessToken.getToken(), accessToken.getTokenSecret(), accessToken
.getScreenName());
//other logics to do the post to twitter
….
} catch (Exception e) {
Log.e(TAG, e.getMessage(), e);
}
}
}
|
A new task will always be created and a new instance will be pushed to the task as the root one. However, if any activity instance exists in any tasks, the system routes the intent to that activity instance through the onNewIntent() method call. In this mode, activity instances can be pushed to the same task. And if the user clicks the BACK key from the singleTask activity, the system will return the user to the previous activity.
This mode is useful for activities that act as the entry points. For example, in a tab-based Twitter client, we can declare the main TabActivity as singleTask. This is also useful if you only want a single instance of the activity to be created. One example of singleTask is the Browser application. Let’s take a Twitter-client-application as example, where the main activity is a TabActivity and has three tabs: tweets, replies and messages. And we want to suppose auto-refresh and notification function when app is running.
In AndroidManifest.xml, we have:
| 12 |
<activity android:name=”.MainTabActivity” android:launchMode=”singleTask” android:alwaysRetainTaskState=”true” android:windowSoftInputMode=”adjustPan”>
</activity>
|
Suppose we have the notification for new tweet/replies/messages, and we hope that clickong on the notification will take the user to the current TabActivity, and switch to corresponding tabs. (Here we suppose the app is not closed before user clicks the notification). Because the MainTabActivity’s launch mode is singleTask, system routes the intent to the MainTabActivity by calling its onNewIntent() method. And in this method, we can determine which tab to switch to according to the bundle data in the intent.
Same as ‘singleTask’, except that the no activities instance can be pushed into the same task of the singleInstance’s. That means, the activity with launch mode is always in a single activity instance task. This is a very specialized mode and should only be used in the applications that are implemented entirely as one activity.
Understanding the launch mode will help you design better navigation and implement some special cases. Here we only discuss the launch mode from the AndroidManifest file. Android launch mode can also be declared using the Intent flags, such as FLAG_ACTIVITY_NEW_TASK, FLAG_ACTIVITY_CLEAR_TOP and FLAG_ACTIVITY_SINGLE_TOP. And we will create more posts to talking about intent flags in the near future, so stay tuned!
Luyi Xing's Blog 