UNIT TWO

Android - Application
Components
 Android - Application Components
 Application components are the essential building
blocks of an Android application.
They are loosely coupled by the application
manifest file.
 Android - Application Components

 There are four main components that can be used within an Android
application
1. Activities:- They dictate the UI and handle the user interaction to the smart phone
screen.

2. Services:- They handle background processing associated with an application

3. Broadcast receivers:- They handle communication between Android OS and
applications.

4. Content providers:- They handle data and database management issues.

 ACTIVITIES
 An activity is usually a single screen (visible part of your
application) that the user sees on the device at one time.
 An application typically has multiple activities, and the user
flips back and forth among them but only one activity is
visible when application is launched.

For example, an email application might have one activity that shows a
list of new emails, another activity to compose an email, and another
activity for reading emails.
NB: for this example at least we have three activities.
 Activity Life Cycle
 The activity life cycle is managed by the Activity Manager, a service that runs
inside the Android Framework layer of the stack.
 The Activity Manager is responsible for creating, destroying, and managing
activities.
For example, when the user starts an application for the first time, the
Activity Manager will create its activity and put it onto the screen
 Later, when the user switches screens, the Activity Manager will move that
previous activity to a holding place.

States that an activity can go through

Starting Paused
Running Destroyed
Stopped
Fig: Activity Life cycle
 Starting state
 When an activity doesn’t exist in memory, it is in a starting state.
 As it starts, the activity invokes a set of callback methods that you as a
developer have an opportunity to fill out. These callbacks include onCreate(),
onStart(), and onResume().
 Eventually, the activity will be in a running state, which means that it will be
fully displayed on the screen, in focus, waiting for user to interact with it.
 Keep in mind that this transition from starting state to running state is one of
the most expensive operations the application will perform in terms of
computing time, and this also directly affects the battery life of the device.
 Running state
 Only one activity on a device can be in a running state: it’s the one
that is currently on the screen and interacting with the user.
 We also say this activity is in focus, meaning that all user
interactions—such as typing, touching the screen, and clicking
buttons—are handled by this one activity.
 The running activity has priority in terms of getting the memory and
resources it needs to run as quickly as possible.
 This is because Android wants to make sure the running activity is
zippy and responsive to the user.
 Paused state
 When an activity is not in focus (i.e., not interacting with the user) but still visible
on the screen, we say it’s in a paused state.
 This is not a typical scenario, because the device’s screen is usually small, and an
activity is either taking up the whole screen or none at all.
 We often see this case with dialog boxes that come up in front of an activity,
causing it to become paused.
 All activities go through a paused state to being stopped.
 The Activity Manager calls onPause() when putting your application into the
paused state.
 Stopped state
 When an activity is not visible, but still in memory, we say it’s in a stopped state.
 A stopped activity could be brought back to the front to become a running activity
again. Or, it could be destroyed and removed from memory, which is an operating
system choice beyond your control.
 The system keeps activities around in a stopped state because it is likely that the
user will still want to get back to those activities some time soon,.
 Restarting a stopped activity is far cheaper than starting an activity from scratch.
That is because the Activity Manager already has all the objects loaded in
memory and simply has to bring them all up to the foreground.
 Stopped activities can be removed from memory at any point. The Activity
Manager calls onStop() when putting your application into this state.
 Next If activity is long stayed in Stopped state then it will forced to Destroyed state.
 Destroyed state
 A destroyed activity is no longer in memory.
 The Activity Manager decided that this activity is no longer needed
and has removed it.
 Before the activity is destroyed, it can perform certain actions, such
as save any unsaved information. However, there’s no guarantee
that your activity will be destroyed from the destroyed state.
 It is possible for a stopped activity to be destroyed as well. For that
reason, it is better to do important work, such as saving unsaved
data, in the onStop() rather than the onDestroy() callback.
 Callback methods that used in
activity lifecycle
 onCreate() :- this callback method is called when the activity is first created.
 Callback methods that used in
activity lifecycle
 onStart() :- this method is called when the activity is
visible to user.
 Callback methods that used in
activity lifecycle
 onResume() :- this callback method is called when the user start interact with app.
 Callback methods that used in
activity lifecycle
 onPause() :- this method is called when the current activity is visible to user but a
user unable to send input data.
 Callback methods that used in
activity lifecycle
 onStop() :- this callback method is called when the activity is no longer visible.
 Callback methods that used in
activity lifecycle
 onDestroy() :- this method is called before activity destroyed by system.
 Intents
 Intents are messages that are sent among the major building blocks.
 They trigger an activity to start up, tell a service to start, stop, or bind to, or are
simply broadcasts.
 Intents are asynchronous, meaning the code that sends them doesn’t have to wait
for them to be completed.
 Intents analogy with a website, intents would be the links connecting various
pages together.
Website(Links) Android(Intents)
Connecting various pages(Links) Connecting various activities
Links connect components in other apps Can carry small amount of primitive data
with them
 Intents
It can be used with 
 startActivity to launch an Activity, 
 broadcastIntent to send it to any interested BroadcastReceiver components, and 
 startService(Intent) or bindService(Intent, ServiceConnection, int) to
communicate with a background Service.
 Intents cont..
 An intent could be
* Explicit In an explicit intent, the sender clearly spells out which
specific component should be on the receiving end.
* Implicit In an implicit intent, the sender specifies just the type of receiver.

 For example, your activity could send an intent saying it simply wants someone to
open up a web page. In that case, any application that is capable of opening a web
page could “compete” to complete this action.
 When you have competing applications, the system will ask you which one you’d like
to use to complete a given action.
 Intents cont..
* Explicit intent, These intents designate the target component by
its name and they are typically used for application-internal messages
- such as an activity starting a subordinate service or launching a sister
activity. For example −
 Intents cont..
• Implicit intent, These intents do not name a target and the field for
the component name is left blank. Implicit intents are often used to activate
components in other applications.
For example −
Examples of Intent
 Services
 Services run in the background and don’t have any user interface components.
 They can perform the same actions as activities, but without any user interface.
 Services are useful for actions that you want to perform for a while, regardless of
what is on the screen.
 For example, you might want your music player to play music even as you are
flipping between other applications.
 Services have a much simpler life cycle than activities (see Figure below).
 You either start a service or stop it. Also, the service life cycle is more or less
controlled by the developer, and not so much by the system.
 Consequently, developers have to be mindful to run services so that they don’t
consume shared resources unnecessarily, such as the CPU and battery.
 Service lifecycle

• Just because a service runs in the background doesn’t necessarily mean it runs on a
separate thread.
• By default, services and activities run on the same main application thread, often called
the UI thread.
• If a service is doing some processing that takes a while to complete (such as performing
network calls), you would typically invoke a separate thread to run it. Otherwise, your
user interface will run noticeably slower.
Service cont.…
 Steps to creating a service are:
 1. Create the Java class representing your service.
 2. Register the service in the AndroidManifest.xml file. Provided by android
Framework
 3. Start the service.

public class RefreshService extends Service {…}

 onStartCommand()
 Called each time the service is started
 onDestroy()
 Called when the service is terminated
 To do that, you can use the Eclipse tool
 Source→Override/Implement Methods and select those three methods.
Service cont.…
 Content Providers
 Content providers are interfaces for sharing data between applications.
 By default, Android runs each application in its own sandbox so that all data that belongs
to an application is totally isolated from other applications on the system.
 Although small amounts of data can be passed between applications via intents, content
providers are much better suited for sharing persistent data between possibly large datasets.
 As such, the content provider API nicely adheres to the CRUD principle. how the content
provider’s CRUD interface pierces the application boundaries and allows other apps to
connect to it to share data.
 The methods that content providers use to implement the four critical operations are:
Operation Method
Create Insert()
Read Query()
Update Update ()
Delete Delete ()
Content Providers contd..
 The Android system uses this mechanism all the time. For example:
 The Contacts Provider exposes all user contact data to various applications.
 The Settings Provider exposes system settings to various applications, including the built-in Settings
application.
 The Media Store is responsible for storing and sharing various media, such as photos and music, across
various applications.
 Figure belowq illustrates how the Contacts app uses the Contacts Provider, a totally
separate application, to retrieve data about users’ contacts.
 The Contacts app itself doesn’t have any contacts data, and the Contacts Provider doesn’t
have any user interface.
Content Providers contd…

Figure. Content provider Figure. Contacts application using the Contacts Provider to get
the data
Content Providers contd...
 This separation of data storage and the actual user interface application offers:
 greater flexibility to mash up various parts of the system.
 For example, a user could install an alternative address book application that uses the same
data as the default Contacts app. Or he could install widgets on the home screen that allow
for easy changes in the System Settings, such as turning on or off the WiFi, Bluetooth, or
GPS features.
 Many phone manufacturers take advantage of content providers to add their own
applications on top of standard Android to improve the overall user experience, such as
HTC Sense.
 Content providers are relatively simple interfaces. The insert(), update(), delete(),and
query() methods look a lot like standard database methods, so it is relatively easy to
implement a content provider as a proxy to the database.
 Although content providers are relatively easy to use, they are somewhat tricky to
implement properly. We’ll explore how to create a new content provider in lab section.
 Broadcast Receivers
 Broadcast receivers are Android’s implementation of a system-wide
publish/subscribe mechanism, or more precisely, an Observer pattern.
 The receiver is simply dormant code that gets activated by the occurrence of an
event to which the receiver is subscribed.
 The “event” takes the form of an intent.
 The system itself broadcasts events all the time. For example, when an SMS
arrives, a call comes in, the battery runs low, or the system completes booting up,
all those events are broadcast, and any number of receivers could be triggered by
them.
 Broadcast receivers themselves do not have any visual representation, nor are
they actively
 running in memory. But when triggered, they get to execute some code, such as
starting an activity, a service, or something else.
 Broadcast Receivers
 That action is in the form of an intent broadcast.
 When the right intent is fired, the receiver wakes up and executes.
 The “wakeup” happens in the form of an onReceive() callback
method.
 Application Context
 So far you have seen activities, services, content providers, and broadcast
receivers. Together, they make up an application. They are the basic building
blocks, loosely coupled, of an Android app.
 Think of an application in Android as a container to hold together your blocks.
Your activities, services, providers, and receivers do the actual work.
 The container that they work in is the shared Linux process with common Dalvik
VM, private file system, shared resources, and similar things.
 To use our website analogy, an app would be the website domain.
 Users never really go to Amazon.com (the domain), but rather visit a web page
(which you could compare to an Android activity) within that domain, or consume
a web service (an Androidservice). So web pages and web services are building
blocks for a website, and the website itself is just a container to hold them all
together under one roof.
 This is very similar to what an Android application does for its components.
Application Context cont.…
 Application Context cont.…
 The application context is uniquely identified on a device based on the package name of that
application. For example, com.marakana.android.HelloWorld would be a package name of our app.
 There cannot be another app with the same package name (unless it comes from us, and we want to
use shared user IDs). An application context gets created whenever the first component of this
application
 The application context lives as long as your application is alive. As such, it is independent of the
activity’s life cycle. So as long as any of the activities, services, providers, or receivers are alive, your
application context is around to hold them. Once the Activity Manager terminates all other building
blocks of your app, it also gets rid of the application context because it’s no longer needed.
 You can easily obtain a reference to the context by calling Context.getApplicationContext() or
Activity.getApplication().
 Intent intent = new Intent(getApplicationContext(),MainActivity.class);
 Keep in mind that activities and services are already subclasses of the context, and therefore inherit
all its methods.
 Activities and services are also subclasses of the Context class, which is different from the
application context we’re talking about here.