0% found this document useful (0 votes)
19 views

2 - Anatomy of AndroidApp - Unit-3

The document discusses the different components that make up an Android application including Context, Activity, Service, Broadcast Receiver and Content Provider. It describes what each component is, its purpose and lifecycle. It provides details about the Activity lifecycle states and transition between them. It also compares started and bound services as well as their lifecycles.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views

2 - Anatomy of AndroidApp - Unit-3

The document discusses the different components that make up an Android application including Context, Activity, Service, Broadcast Receiver and Content Provider. It describes what each component is, its purpose and lifecycle. It provides details about the Activity lifecycle states and transition between them. It also compares started and bound services as well as their lifecycles.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 82

Mobile Application

Development

U. V. Patel College of Engineering, Ganpat University 1


Anatomy of Android Application

2
3
Anatomy of Android Application
● An application consists of one or more components that are defined in the
application's manifest file.
● A component can be one of the following:
● Context
● Activity
● Service
● Broadcast receiver
● Content provider
● Intent

4
Context:
● The context is the central command center for an Android application.
● All application-specific functionality can be accessed through the context
● You can retrieve the Context for the current process using the
getApplicationContext()
● Context context = getApplicationContext();

5
Context:

6
Context:
Context is an abstract class, implemented in the Android system by some classes
like e.g. Activity, Service, Application.

Why I need it?

7
Context:

 We can use it to retrieve resources, start a new


Activity, show a dialog, start a system service,
create a view, and more.
 Context type depends on the Android component
that lives within it.

8
Context:

 getContext() — returns the Context which is linked


to the Activity from which is called,
 getApplicationContext() — returns the Context
which is linked to Application which holds all
activities running inside it,

9
Activity:

 An Activity represents a screen or a window. Sort


of.
 each activity is independent of the others.
 one of the activities is marked as the first one that
should be presented to the user when the
application is launched.

10
Activity:

11
12
13
14
15
16
17
18
Life Cycle of an Activity:

19
Life Cycle of an Activity:

20
Life Cycle of an Activity:

21
Life Cycle of an Activity:

22
Life Cycle of an Activity:

23
24
Life Cycle States:
It has three states
1. active / running
2. paused or
3. stopped

25
Life Cycle States
 Running
 It is active or running when it is in the foreground
of the screen(at the top of the activity stack for
the current task).
 This is the activity that is the focus for the user's
actions.
26
Life Cycle States
 Paused
 It is paused if it has lost focus but is still visible to the user.
 That is, another activity lies on top of it and that new activity
either is transparent or doesn't cover the full screen.
 A paused activity is completely alive(it maintains all state and
member information and remains attached to the window
manager), but can be killed by the system in extreme low
memory situations
27
Life Cycle States
 Stopped
 It is stopped if it is completely obscured by
another activity.
 It still retains all state and member information.
However, it is no longer visible to the user so its
window is hidden and it will often be killed by the
system when memory is needed elsewhere
28
Life time
 Life cycle of an activity:
 Visible life time: onStart() to onStop()
 During this life time the activity will not be interacting
with the user. Between these two activities, resources
are maintained that are needed by the system to show
the activity on the screen

29
Life time
 Foreground life time: onResume() to onPause().
 During this life time the activity will be in front of all
other activities.
 Entire Life time: onCreate() to onDestroy()

30
Life time
 When you open the app it will go through below
states:
 onCreate() –> onStart() –> onResume()
 When you press the back button and exit the app
 onPaused() — > onStop() –> onDestory()

31
Life time
 When you press the home button
 After pressing the home button, again when you
open the app from a recent task list
 After dismissing the dialog or back button from
the dialog
 ?
32
Life time
 When you press the home button
 onPaused() –> onStop()
 After pressing the home button, again when you
open the app from a recent task list
 onRestart() –> onStart() –> onResume()
 After dismissing the dialog or back button from
the dialog
33
 onResume()
Life time
 If a phone is ringing and user is using the app
 After the call ends
 When your phone screen is off
 When your phone screen is turned back on

34
Life time
 If a phone is ringing and user is using the app
 onPause() –> onResume()
 After the call ends
 onResume()
 When your phone screen is off
 onPaused() –> onStop()
 When your phone screen is turned back on
 onRestart() –> onStart() –> onResume()
35
36
37
Services

38
Service Life Cycle

39
Remote Service

40
Service
 Service is the one of the critical application component which can perform
long-running operations in the background.
 It may continue running for time, even user dealing with to another
applications
 also you can perform interprocess communication.

41
Service
 It may continue running for time, even user dealing with to another
applications
 also you can perform interprocess communication.

42
Service
 Why we should use services?
 Developers should use services for long-running operations.
 Handle network transactions, play music, perform file I/O, or interact with a
content provider.
 Services run in the main thread of in hosting process, not create its own
thread, so developers should run any blocking operations on the separate
thread(manage yourself) for avoiding Application Not Responding (ANR)
errors.

43
Service
 Types of Services

44
Service
 1- Foreground:
 Type of services that perform operations in the background that is noticeable
for the users.
 This kind of services must display a Notification and It should continue
running even user is not dealing with the app.
 Have own lifecycle that independent from activity or fragment that they were
created.
 Music Player App(notification of the current song)
-Fitness App(show the distance that user has traveled)

45
Service
 2-Background:
 Type of services that perform operations in the background that is not giving
any information to user via notification.
 Background services have own lifecycle that independent from activity or
fragment that they were created.
 Example: compact its storage.
 API-26 or Higher - imposes restrictions on running background services.
 Developers should not access location informations from the background

46
Service
 3-Bound:
 client-server interface that allows components(Activity, content provider and
service can bind to the Bound service) to interact with the service, send
requests, receive results, and even do so across processes with interprocess
communication (IPC).
 no own lifecycle
 multiple components can bind to service at once, but when all of them
unbind, the service is destroyed.
 use the lifecycle of the activity or fragment they were bounded

47
Service Life cycle

48
Service Life cycle
 1.Started Services
 when an application component calls startService().
 This service can be stopped only in one of the two cases:
 By using the stopService() method.
 By stopping itself using the stopSelf() method.

49
Service Life cycle
 2.Bound Services:
 A service is bound only if an application component binds to it
using bindService().
 When all clients unbind from bound service by calling unBindService()
function, service ends with onUnbind onDestroy functions.

50
Difference

51
Difference

52
Service methods
 onStartCommand()
The system calls this method when another component, such as an
activity, requests that the service be started, by calling startService(). If
you implement this method, it is your responsibility to stop the service
when its work is done, by calling stopSelf() or stopService() methods.

53
Service methods
 onBind()
The system calls this method when another component wants to bind
with the service by calling bindService(). If you implement this method,
you must provide an interface that clients use to communicate with the
service, by returning an IBinder object. You must always implement this
method, but if you don't want to allow binding, then you should return
null.

54
Service Life cycle
 onUnbind()
The system calls this method when all clients have disconnected from a
particular interface published by the service.
 onRebind()
The system calls this method when new clients have connected to the
service, after it had previously been notified that all had disconnected
in its onUnbind(Intent).

55
Service Life cycle
 onCreate()
The system calls this method when the service is first created using
onStartCommand() or onBind(). This call is required to perform one-time
set-up.
 onDestroy()
The system calls this method when the service is no longer used and is
being destroyed. Your service should implement this to clean up any
resources such as threads, registered listeners, receivers, etc.

56
Service Code
Android Manifest file:

57
Service Code
Android MainActivity.kt:

58
Service Code
Android MainActivity.kt:

59
Service Code
Android MyService.kt:

60
Service Code
Android MyService.kt:

61
Broadcast Receiver
● Android BroadcastReceiver is a dormant component of android that listens to
system-wide broadcast events or intents.

● When any of these events occur it brings the application into action by either
creating a status bar notification or performing a task.

● Unlike activities, android BroadcastReceiver doesn’t contain any user


interface. Broadcast receiver is generally implemented to delegate the tasks
to services depending on the type of intent data that’s received.

62
Broadcast Receiver

63
Broadcast Receiver
● Following are some of the important system wide generated intents.
1. android.intent.action.BATTERY_LOW : Indicates low battery condition on the
device.
2. android.intent.action.BOOT_COMPLETED : This is broadcast once, after the
system has finished booting
3. android.intent.action.CALL : To perform a call to someone specified by the data
4. android.intent.action.DATE_CHANGED : The date has changed
5. android.intent.action.REBOOT : Have the device reboot
6. android.net.conn.CONNECTIVITY_CHANGE : The mobile network or wifi
connection is changed(or reset)

64
Broadcast Receiver in Android
● To set up a Broadcast Receiver in android application we need to do the
following two things:
1. Creating a BroadcastReceiver
2. Registering a BroadcastReceiver

65
Broadcast Receiver

66
Broadcast Receiver
Creating the Broadcast Receiver
A broadcast receiver is implemented as a subclass of BroadcastReceiver class and overriding the
onReceive() method where each message is received as a Intent object parameter.

import android.content.BroadcastReceiver
import android.content.Context
import android.content.Intent

class MyReceiver : BroadcastReceiver() {

override fun onReceive(context: Context, intent: Intent) {


// TODO: This method is called when the BroadcastReceiver is receiving
// an Intent broadcast.
throw UnsupportedOperationException("Not yet implemented")
}
}
67
Broadcast Receiver
Registering Broadcast Receiver
An application listens for specific broadcast intents by registering a broadcast receiver in AndroidManifest.xml
file. Consider we are going to register MyReceiver for system generated event ACTION_BOOT_COMPLETED
which is fired by the system once the Android system has completed the boot process.

<application android:icon="@drawable/ic_launcher" android:label="@string/app_name"


android:theme="@style/AppTheme" >
<receiver android:name="MyReceiver">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED">
</action>
</intent-filter>
</receiver>
</application>

68
Content Provider

69
Content Provider

70
Content Provider

71
Content Provider

72
Intent

73
Intent
An Intent is a messaging object you can use to request an action from another app
component. Although intents facilitate communication between components in
several ways

74
Intent
An Intent is a messaging object you can use to request an action from another app
component. Although intents facilitate communication between components in
several ways

75
Intent
Starting an activity
startActivity().

Starting a service
startService()
bindService().

Delivering a broadcast
sendBroadcast()

76
Intent Type
Explicit intents

Implicit intents

77
Intent Type
Explicit intent:-

78
Intent Type
Explicit intent:-
MainActivity.kt

79
Intent Type
Explicit intent:-
SecondActivity.kt

80
Intent Type
Implicit intent:-
MainActivity.kt

81
Intent Type
Implicit intent:-
Manifest.xml

82

You might also like