Intents& · IntentFilters • A&component's&intentﬁlters&in&the&...

Intents

COMP 355 (Muppala) Android Overview 1

Ac)va)ng Components


Ac)vity

Service

Broadcast Receiver

Intent

Content Provider

Content Resolver

Intents

•  Intents are asynchronous message objects to ac)vate components other than content providers –  Message consists of (for ac)vi)es and services)

•  Ac)on being requested (MAIN/VIEW/EDIT/PICK/DELETE/DIAL/etc) •  URI of the data to act upon

–  For broadcast receivers the message is the ac)on being announced –  Example

public void onClick(View v) { if(v==retryBtn){ // Change view Intent i = new Intent(Result.this,Touch.class); startActivity(i); } }


Intents (Contd.)

•  Two kinds of intents: –  Explicit intent: explicitly specify the component’s name that should

respond to the intent –  Implicit intent: Let Android locate the best component that can

respond to the intent •  Uses intent filters for this (more on this later) •  Example

startActivity(new Intent(Intent.ACTION_VIEW,Uri.parse("http://www.cse.ust.hk")));


ShuUng Down Components

•  Ac)vi)es and services need to be shut down explicitly •  No need to explicitly shut down content provider and

broadcast receiver –  A content provider ac)ve only while responding to a request from a

ContentResolver –  A broadcast receiver ac)ve only while responding to a broadcast

message

•  Components might also be shut down by the system –  When they are no longer being used –  When Android must reclaim memory for more ac)ve components


The Manifest File Revisited

•  Applica)ons declare their components in a manifest file –  Bundled into the.apk file –  Before Android can start an applica)on component, it must learn that

the component exists

•  Structured XML file –  Always named AndroidManifest.xml for all applica)ons –  Also names any libraries the applica)on needs to be linked against

(besides the default Android library) –  Iden)fies any permissions the applica)on expects to be granted


Intent Filters •  A component's intent filters in the

manifest file informs Android of the kinds of intents the component is able to handle. –  <ac)vity

android:name=".Touch" android:label="@string/)tle_ac)vity_touch" > <intent-‐filter> <ac)on android:name="android.intent.ac)on.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-‐filter> </ac)vity> <ac)vity android:name=".Result" android:label="@string/)tle_ac)vity_result" > <intent-‐filter> <ac)on android:name="android.intent.ac)on.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> </intent-‐filter> </ac)vity> . . .


Intent Filters (Contd.)

•  A component can have any number of intent filters, each one declaring a different set of capabili)es.

•  One filter may indicate that the ac)vity is the entry point for the applica)on.

•  Another filter may declare an ac)on that the ac)vity can perform on par)cular type of data

•  If it doesn't have any filters, it can be ac)vated only by intents that explicitly name the component as the target


Exercise: Intents and Ac)vi)es


Using Explicit Intents

•  Open the ac)vity_result.xml file and add a bucon widget: <Bucon android:id="@+id/retryBtn" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_alignParentBocom="true" android:layout_centerHorizontal="true" android:layout_marginBocom="110dp" android:text="Retry" />


Using Explicit Intents

•  Open Result.java to add an onClick() listener to the Retry bucon as follows:

retryBtn = (Button) findViewById(R.id.retryBtn); retryBtn.setOnClickListener(this);

public void onClick(View v) { if(v==retryBtn){ // Change view Intent i = new Intent(Result.this,Touch.class); startActivity(i); } }


Exercise: Data Transfers Among Ac)vi)es


putExtra() – Sending Informa)on

•  Using putExtra to add data into the Intent •  Extras are key/value pairs; the key is always a String. As value

you can use the primi)ve data types (int, float,..), String, Bundle, Parceable and Serializable.

•  For example, you can pass the total tap count from Touch to Result ac)vity Intent i = new Intent(Touch.this,Result.class);// Pass the total tap count to the Result viewi.putExtra("totalTapCount", totalTapCount);


getExtras() – Retrieving Informa)on

•  Using getExtras() to retrieve data in the Intent •  For example, you can retrieve the total tap count from Touch

ac)vity

// Retrieve data from previous intent (view) Intent touch = getIntent(); int totalTapCount = touch.getIntExtra("totalTapCount",

totalTapCount);


Ac)vi)es, Tasks and Applica)on Lifecycle


Applica)ons, Ac)vi)es and Tasks

•  Four fundamental concepts that we need to understand: –  Applica)on –  Ac)vity –  Ac)vity stack –  Task


Applica)ons and Components •  An Android applica=on typically

consists of one or more related, loosely bound ac)vi)es for the user to interact with, typically bundled up in a single file (with an .apk suffix)

•  An Android applica)on is composed of several components –  Every applica)on runs in its own

Linux process –  Process created whenever any one

of the components get ac)vated –  Every component has a managed

lifecycle

Applica)on

Ac)vity 1 Ac)vity 2

Service 1

Broadcast Receiver

Service 2

Content Provider

Ac)vity 3

Applica)ons, Ac)vi)es and Tasks


Touch

Result

Mail composer

Touch

Mail

Ac)vity stack Applica)on/Process

Task

Applica)ons, Ac)vi)es and Tasks (Contd.) •  Tasks

–  A task is a group of related Ac)vi)es arranged in a stack •  Ac)vi)es may belong to different applica)ons

–  What the user experiences as an “applica)on” –  The root ac)vity is the one that begins the stack, the

ac)vity that is selected by the user in the applica)on launcher

–  Current ac)vity is at the top of the stack –  User pressing the BACK key will cause the current

ac)vity to be popped off the stack and the previous ac)vity resumes

–  Stack may contain more than one instance of the same ac)vity

–  The en)re stack moves as a unit between foreground and background

Touch

Result

Web browser

root

Current Ac)vity

Interrup)ng a Task

•  User can interrupt what they're doing (their task) to perform a different task –  Can return to where they len off to complete the original task –  Mul)tasking and switching between the tasks

•  Task switching: –  User is interrupted by a no)fica)on – a no)fica)on appears and the

user wants to act on it –  User deciding to perform another task – user just presses Home and

starts an applica)on


Ac)vi)es and Tasks

•  Star)ng an Ac)vity from Home –  Home is the star)ng place for most applica)ons. (Some applica)ons can be launched only from other applica)ons.)

–  When the user touches an icon in the applica)on launcher (or a shortcut on the Home screen), the applica)on is launched into the foreground where it has user focus


Ac)vi)es and Tasks

•  Naviga)ng away from an Ac)vity with BACK key –  An ac)vity can keep or lose its state depending on how the user leaves the ac)vity — by the HOME or BACK key.

–  By default, pressing the BACK key finishes (destroys) the current ac)vity and displays the previous ac)vity to the user


Ac)vi)es and Tasks

•  Naviga)ng away from an Ac)vity with HOME key


Reusing Ac)vi)es


Replacing an Ac)vity


Mul)tasking


Switching Between Tasks


Design Tips

•  When wri)ng an ac)vity that won't be re-‐used, don't specify intent filters — use explicit intents

•  When reusing an ac)vity owned by others, handle the case where no ac)vity matches

•  Consider how you want your ac)vi)es to be launched or used by other applica)ons –  Launch your main ac)vity from an icon at Home –  Launch your ac)vity from within another applica)on –  Launch your ac)vity only from within another applica)on –  Launch two or more main ac)vi)es within a single applica)on from

separate icon at Home –  Making your applica)on available as a widget


Design Tips

•  Allow your ac)vi)es to be added to the current task •  No)fica)ons should let the user easily get back to the

previous ac)vity •  Use the no)fica)on system — don't use dialog boxes in place

of no)fica)ons •  Don't take over the BACK key unless you absolutely need to


Component Lifecycle

•  Component lifecycle –  From the beginning when Android instan)ates them to respond to

intents through to an end when the instances are destroyed –  In between, they may some)mes be ac)ve or inac)ve –  Ac)vi)es may be visible to the user or invisible


Component Lifecycles

•  Ac)vity Lifecycle –  Three states

•  Running, paused and stopped

–  If an ac)vity is paused or stopped, the system can drop it from memory either by:

–  asking it to finish (calling its finish() method)

–  simply killing its process.

• Ac)vity in the foreground of the screen (at the top of the ac)vity stack for the current task)

Running

• Ac)vity has lost focus but is s)ll visible to the user Paused

• Ac)vity is completely obscured by another ac)vity

• It s)ll retains all state and member informa)on

Stopped

Ac)vity Lifecycle

•  As an ac)vity transi)ons from state to state, it is no)fied of the change by calls to the following protected methods: void onCreate(Bundle savedInstanceState) void onStart() void onRestart() void onResume() void onPause() void onStop() void onDestroy()


Ac)vity Lifecycle •  Three nested loops for the en)re

lifecycle –  En"re life"me

•  From onCreate() to onDestroy() •  An ac)vity does all its ini)al setup of

"global" state in onCreate() •  releases all remaining resources in

onDestroy() •  For example, create that thread in

onCreate() and then stop the thread in onDestroy().

–  Visible Life)me •  User can see the ac)vity on-‐screen,

though it may not be in the foreground and interac)ng with the user.

•  onStart() and onStop() can be called mul)ple )mes, as the ac)vity alternates between being visible and hidden to the user.

–  Foreground Life)me •  Ac)vity is in front of all other ac)vi)es

on screen and is interac)ng with the user.

En)re Life)m

e

Visib

le Life

)me

Foregrou

nd

Life)m

e

Ac)vity Lifecycle

•  When are the methods called in an ac)vity's overall lifecycle? –  onCreate()

•  Called when the ac)vity is first created or when the ac)vity was killed –  onStart()

•  Called just before the ac)vity becomes visible to user

–  onRestart() •  Called aner the ac)vity has been stopped, just prior to it being started again

–  onResume() •  Called just before the ac)vity starts interac)ng with the user •  At this point, the ac)vity is at the top of the ac)vity stack, with user input going to it

Ac)vity Lifecycle

•  When are the methods called in an ac)vity's overall lifecycle? –  onPause()

•  Called when the system is about to start resuming another ac)vity •  This method is typically used to commit unsaved changes to persistent data, stop anima)ons and other things that may be consuming CPU, and so on

–  onStop() •  Called when the ac)vity is no longer visible to the user •  This may happen because it is being destroyed, or because another ac)vity has been resumed and is covering it

–  onDestroy() •  Called before the ac)vity is destroyed

Saving Ac)vity State

•  When system shuts down an ac)vity, user may expect to return to the ac)vity in its previous state

•  Make use of two methods implemented within the ac)vity to save and restore state: –  onSaveInstancestate(): Android calls this before making the ac)vity

vulnerable to being destroyed (i.e. before onPause()) •  Save state in a Bundle object

–  onRestoreInstanceState(): Bundle passed both to onCreate() and the onRestoreInstanceState() which is called just before onStart() to recreate the captured state

–  Both methods are not part of lifecycle, as they need not be called when the user inten)onally destroys the ac)vity


Coordina)ng Ac)vi)es

•  When one ac)vity starts another, they both experience lifecycle transi)ons –  One pauses and may stop, while the other starts up. –  On occasion, you may need to coordinate these ac)vi)es, one with

the other.

•  The order of lifecycle callbacks is well defined, par)cularly when the two ac)vi)es are in the same process: 1.  The current ac)vity's onPause() method is called. 2.  Next, the star)ng ac)vity's onCreate(), onStart(), and onResume()

methods are called in sequence. 3.  Then, if the star)ng ac)vity is no longer visible on screen, its

onStop() method is called.


Service Lifecycle

•  A service can be used in two ways: –  The service can be started and allowed to run un)l someone stops it

or stops itself. •  Started by calling Context.startService() •  Stopped by calling Context.stopService()

–  The service can be operated programma)cally using an interface that it defines and exports •  Clients establish a connec)on to the Service object and use that connec)on to call into the service.

•  Connec)on established by calling Context.bindService() •  Connec)on closed by calling Context.unbindService()

Service Lifecycle

•  Service lifecycle methods –  They are public, not protected: void onCreate() void onStart(Intent intent) void onDestroy()

Broadcast Receiver Lifecycle

•  Single callback method void onReceive(Context curContext, Intent broadcastMsg)

•  When a broadcast message arrives for the receiver, Android calls the method and passes it the Intent object containing the message

–  Ac)ve only when the onReceive() is being executed. Becomes inac)ve on exit of this method

–  A process with an ac)ve broadcast receiver is protected from being killed but a process with only inac)ve components can be killed by the system at any )me.

Intents& · IntentFilters • A&component's&intentﬁlters&in&the&...

Documents

Transcript of Intents& · IntentFilters • A&component's&intentﬁlters&in&the&...