So Android apps are made of several high level components, the main components are.
Activities.
Fragments.
Enterprise has communication mechanism intense.
Broadcast receivers.
Content providers and services.
So all these elements are provided by the Android operating system in the form of predefined classes
available through APIs, so activities they'll make up the visible part of any app.
There's one activity per screen.
So an app with three different screens implements three different activities.
Activities are declared by extending the activity class, they contain all user elements, fragments,
views and layouts.
So each activity needs to be declared in the Android manifest.
With the following syntax activities not declared in the manifest, can't be displayed at attempting
to launch them will raise an exception.
So, like ABC's activities have their own life cycle and need to monitor system changes in order to
be able to handle them.
Activities can be in the following states active, paused, stopped and inactive, these states are
managed by the Android operating system and accordingly, activities can implement the following event
managers.
Now, an app may not explicitly implement all event managers, in which case default actions are taken.
A fragment.
Represents behavior or portion of the user interface within the activity.
Fragments were actually introduced in Android with the version Honeycomb 3.0.
Now, fragments are meant to encapsulate parts of the interface to facilitate reusability and adaptation,
especially for different screen sizes.
So fragments are autonomous entities, and that means that they include all of their required components.
They've got their own layout, buttons, et cetera, however, they must be integrated with activities
in order for them to be useful, fragments can't exist on their own.
They have their own life cycle, which is tied to the life cycle of the activities that implement them.
So to follow on from that, because fragments have their own life cycle, the fragment class contains
event managers that can be redefined and extended.
He's event managers include on attach uncreate, on start undestroyed and on detach, there's a few
more.
Now, we didn't use fragments in our quiz game, but it can be easily implemented by extending the fragment
class provided by Android like this.
Fragments don't need to be declared in manifest files because they depend on activities.
Now, as we've already learned, every Android process has its own sandbox address space.
But I want to introduce you to inner process communication facilities, because this allows APS to exchange
signals and data securely, so instead of relying on the default Linux IPC facilities.
Android's IPC is based on Binder.
A binder is an Android specific and a process communication mechanism.
And remote method invocation system.
So that means that one Android process can call a routine and another Android process using Binder to
identify the method to invoke and pass the arguments between processes.
And I communication can be simply understood as client server mode.
Client request service server receives a client request and processes it accordingly or may bring back
the result to the client.
The binding mechanism works briefly as follows.
One, the client obtained servers proxy through service manager.
To client sends request information to server by calling proxy.
Three proxy sends user request information to Linux kernel space and sends it to server.
For server processes, user requests and returns, the processing results to clients proxy through the
binder driver of the Linux kernel.
And five client receives the return result from server.
So here's a part of binder implementation with Java.
Intent messaging is an asynchronous communication framework, build on top of binder.
And intent is a messaging object that can be used to request an action from another app component,
although intense, facilitate enter component communication in several ways.
There are three fundamental use cases.
Starting an activity.
So an activity represents a single screen in the app, you can start a new instance of an activity by
passing an intent to start activity, then the intent describes the activity and carries the necessary
data.
Starting a service.
A service is a component that performs operations in the background without a user interface.
Starting with Android 5.0 and later you can start a service with job scheduler.
Delivering a broadcast.
So broadcast is a message that any app can receive, the system delivers broadcasts for a system event,
including system boot and charging initialization.
You can deliver a broadcast to other apps just by passing an intent to send broadcast or send order
to broadcast.
Now, an intense filter is an expression in Android manifest files that'll specify the type of intense
the component would like to receive.
For instance, by declaring an intent filter for an activity, you make it possible for other apps to
directly start your activity with a certain kind of intent.
So let's have a look at some intent actions from the SDK folder.
So when you go to Android Studio Open SDK manager.
Copy the SDK location and then go to this folder.
And under the platforms folder, Open Android 30.
Now, there is an activity actions file under this data folder.
So if you open it.
You can see a list and there are lots of intent actions here that we can use an Android application.
So some intense actions or for application error, for run search, set alarms at wallpaper and many
more.
So broadcast receivers are components that allow apps to receive notifications from other apps and from
the system itself.
So with these apps can react to events internal initiated by their apps or initiated by the operating
system, and they're generally used to update user interfaces, start services, update content and
create user notifications.
There are two ways to make a broadcast receiver known to the system.
One is to declare it in the Android manifest file.
And the manifest should specify an association between the broadcast receiver and an intent filter to
indicate the actions of that the receiver is meant to listen for, right.
Now, the other way is to create a receiver dynamically in code.
The broadcast receiver in the following example logs and displays the contents of the broadcast.
So let's have a look at the broadcast actions from the SDK folder.
So if you go to Android Studio Open SDK manager.
Copied the SDK location and go to the folder.
So under the platforms folder, Open Android 30.
And you'll find a file labeled Broadcast Actions, which is under the data folder.
So open it up.
Now, some broadcast actions will be for Bluetooth, hardware input, wi fi, power save and as you
can see, many more.
And as you look through the list, you can see that these actions are notifications that affect all
apps, so that means that they're sent to all apps, right?