Lecture-2

1. M D . M U J A H I D I S L A M
A P P S D E V E L O P E R
U N I T E D F I N A N C E
Android Application Development
1

2. Android Components
There are four different types of app components:
1. Activities.
2. Services.
3. Broadcast receivers.
4. Content providers.
2

3. Activity
An activity is the entry point for interacting with the
user. It represents a single screen with a user
interface.
Keeping track of what the user currently cares about
(what is on screen) to ensure that the system keeps
running the process that is hosting the activity.
Knowing that previously used processes contain
things the user may return to (stopped activities),
and thus more highly prioritize keeping those
processes around.
3

4. Activity
Helping the app handle having its process killed so
the user can return to activities with their previous
state restored.
Providing a way for apps to implement user flows
between each other, and for the system to coordinate
these flows.
4

5. Service
5
A service is a general-purpose entry point for
keeping an app running in the background for all
kinds of reasons.
 It is a component that runs in the background to
perform long-running operations or to perform work
for remote processes.
A service does not provide a user interface.

6. Broadcast Receiver
6
 A broadcast receiver is a component that enables
the system to deliver events to the app outside of a
regular user flow, allowing the app to respond to
system-wide broadcast announcements.
 Broadcast receivers are another well-defined entry
into the app, the system can deliver broadcasts even
to apps that aren't currently running.

7. Content providers
7
A content provider manages a shared set of app data
that you can store in the file system, in a SQLite
database, on the web, or on any other persistent
storage location that your app can access.
Through the content provider, other apps can query
or modify the data if the content provider allows it.

8. The manifest file
8
Identifies any user permissions the app requires,
such as Internet access or read-access to the user's
contacts.
Declares the minimum API Level required by the
app, based on which APIs the app uses.
Declares hardware and software features used or
required by the app, such as a camera, bluetooth
services, or a multitouch screen.
Declares API libraries the app needs to be linked
against (other than the Android framework APIs),
such as the Google Maps library.

9. The manifest file
9
You must declare all app components using the
following elements:
1. <activity> elements for activities.
2. <service> elements for services.
3. <receiver> elements for broadcast receivers.
4. <provider> elements for content providers.

10. Activity Life Cycle
10

11. Navigating between activities
11
Depending on whether your activity wants a result
back from the new activity it’s about to start, you
start the new activity using either the startActivity()
or the startActivityForResult() method.
The Intent object specifies either the exact activity
you want to start or describes the type of action you
want to perform (and the system selects the
appropriate activity for you, which can even be from
a different application).
An Intent object can also carry small amounts of
data to be used by the activity that is started.

12. Navigating between activities
12
Intent intent = new Intent(this, SignInActivity.class);
startActivity(intent);
Intent intent = new Intent(Intent.ACTION_SEND);
intent.putExtra(Intent.EXTRA_EMAIL, recipientArray);
startActivity(intent);
startActivityForResult(new Intent(Intent.ACTION_PICK,new Uri("content://contacts")),
PICK_CONTACT_REQUEST);

13. Saving activity state
13
static final String STATE_SCORE = "playerScore";
static final String STATE_LEVEL = "playerLevel";
...
@Override
public void onSaveInstanceState(Bundle savedInstanceState) {
// Save the user's current game state
savedInstanceState.putInt(STATE_SCORE, mCurrentScore);
savedInstanceState.putInt(STATE_LEVEL, mCurrentLevel);
// Always call the superclass so it can save the view hierarchy state
super.onSaveInstanceState(savedInstanceState);
}

14. Restoring activity state
14
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState); // Always call the superclass first
// Check whether we're recreating a previously destroyed instance
if (savedInstanceState != null) {
// Restore value of members from saved state
mCurrentScore = savedInstanceState.getInt(STATE_SCORE);
mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL);
} else {
// Probably initialize members with default values for a new instance
}
...
}

15. Restoring activity state
15
public void onRestoreInstanceState(Bundle savedInstanceState) {
// Always call the superclass so it can restore the view hierarchy
super.onRestoreInstanceState(savedInstanceState);
// Restore state members from saved instance
mCurrentScore = savedInstanceState.getInt(STATE_SCORE);
mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL);
}

16. Sending data between activities
16
Parcelable and Bundle objects are intended to be used
across process boundaries such as with IPC/Binder
transactions, between activities with intents, and to
store transient state across configuration changes.
Intent intent = new Intent(this, MyActivity.class);
intent.putExtra("media_id", "a1b2c3");
...
startActivity(intent);

17. Sending data between processes
17
Sending data between processes is similar to doing
so between activities. However, when sending
between processes, we recommend that you do not
use custom parcelables.
 If you send a custom Parcelable object from one app
to another, you need to be certain that the exact
same version of the custom class is present on both
the sending and receiving apps. Typically this could
be a common library used across both apps.

18. Processes and Application Lifecycle
18
In most cases, every Android application runs in its own
Linux process.
This process is created for the application when some of
its code needs to be run, and will remain running until it
is no longer needed and the system needs to reclaim its
memory for use by other applications.
An unusual and fundamental feature of Android is that
an application process's lifetime is not directly controlled
by the application itself. Instead, it is determined by the
system through a combination of the parts of the
application that the system knows are running, how
important these things are to the user, and how much
overall memory is available in the system.

19. Processes and Application Lifecycle
19
1. Foreground Process
2. A Visible Process
3. A Service Process
4. A Cached Process

20. Foreground Process
20
A foreground process is one that is required for what the
user is currently doing. Various application components
can cause its containing process to be considered
foreground in different ways. A process is considered to be
in the foreground if any of the following conditions hold:
It is running an Activity at the top of the screen that the
user is interacting with (its onResume() method has been
called).
It has a BroadcastReceiver that is currently running (its
BroadcastReceiver.onReceive() method is executing).
It has a Service that is currently executing code in one of
its callbacks (Service.onCreate(), Service.onStart(), or
Service.onDestroy()).

21. Visible Process
21
A visible process is doing work that the user is
currently aware of, so killing it would have a noticeable
negative impact on the user experience. A process is
considered visible in the following conditions:
It is running an Activity that is visible to the user on-
screen but not in the foreground (its onPause()
method has been called).
It has a Service that is running as a foreground
service, through Service.startForeground()

22. A Service Process
22
A service process is one holding a Service that has been
started with the startService() method. Though these
processes are not directly visible to the user, they are
generally doing things that the user cares about (such
as background network data upload or download), so
the system will always keep such processes running
unless there is not enough memory to retain all
foreground and visible processes.

23. A Cached Process
23
A cached process is one that is not currently needed,
so the system is free to kill it as desired when memory
is needed elsewhere. In a normally behaving system,
these are the only processes involved in memory
management: a well running system will have multiple
cached processes always available (for more efficient
switching between applications) and regularly kill the
oldest ones as needed.

24. Question
24