Intents
COMP 355 (Muppala) Android Overview 1
Ac)va)ng Components
COMP 355 (Muppala) Android Overview 2
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); } }
COMP 355 (Muppala) Android Overview 3
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")));
COMP 355 (Muppala) Android Overview 4
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
COMP 355 (Muppala) Android Overview 5
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
COMP 355 (Muppala) Android Overview 6
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> . . .
COMP 355 (Muppala) Android Overview 7
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
COMP 355 (Muppala) Android Overview 8
Exercise: Intents and Ac)vi)es
COMP 355 (Muppala) Android Overview 9
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" />
COMP 355 (Muppala) Android Overview 10
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); } }
COMP 355 (Muppala) Android Overview 11
Exercise: Data Transfers Among Ac)vi)es
COMP 355 (Muppala) Android Overview 12
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);
COMP 355 (Muppala) Android Overview 13
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);
COMP 355 (Muppala) Android Overview 14
Ac)vi)es, Tasks and Applica)on Lifecycle
COMP 355 (Muppala) Android Overview 15
Applica)ons, Ac)vi)es and Tasks
• Four fundamental concepts that we need to understand: – Applica)on – Ac)vity – Ac)vity stack – Task
COMP 355 (Muppala) Android Overview 16
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
COMP 355 (Muppala) Android Overview 18
Touch
Result
Mail composer
Touch
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
COMP 355 (Muppala) Android Overview 20
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
COMP 355 (Muppala) Android Overview 21
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
COMP 355 (Muppala) Android Overview 22
Ac)vi)es and Tasks
• Naviga)ng away from an Ac)vity with HOME key
COMP 355 (Muppala) Android Overview 23
Reusing Ac)vi)es
COMP 355 (Muppala) Android Overview 24
Replacing an Ac)vity
COMP 355 (Muppala) Android Overview 25
Mul)tasking
COMP 355 (Muppala) Android Overview 26
Switching Between Tasks
COMP 355 (Muppala) Android Overview 27
Switching Between Tasks
COMP 355 (Muppala) Android Overview 28
Switching Between Tasks
COMP 355 (Muppala) Android Overview 29
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
COMP 355 (Muppala) Android Overview 30
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
COMP 355 (Muppala) Android Overview 31
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
COMP 355 (Muppala) Android Overview 32
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()
COMP 355 (Muppala) Android Overview 34
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
COMP 355 (Muppala) Android Overview 38
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.
COMP 355 (Muppala) Android Overview 39
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.
Top Related