Mobile Application Development

Mobile application development is the process of creating software applications that run on a
mobile device, and a typical mobile application utilizes a network connection to work with
remote computing resources. Hence, the mobile development process involves creating
installable software bundles (code, binaries, assets, etc.) , implementing backend services
such as data access with an API, and testing the application on target devices.

Mobile application development is the process of creating software applications that run on a
mobile device, and a typical mobile application utilizes a network connection to work with
remote computing resources. Hence, the mobile development process involves creating
installable software bundles (code, binaries, assets, etc.) , implementing backend services
such as data access with an API, and testing the application on target devices.

Mobile application development is the process of creating software applications that run on a
mobile device, and a typical mobile application utilizes a network connection to work with
remote computing resources. Hence, the mobile development process involves creating
installable software bundles (code, binaries, assets, etc.) , implementing backend services
such as data access with an API, and testing the application on target devices.

Mobile application development is the process of creating software applications that run on a
mobile device, and a typical mobile application utilizes a network connection to work with
remote computing resources. Hence, the mobile development process involves creating
installable software bundles (code, binaries, assets, etc.) , implementing backend services
such as data access with an API, and testing the application on target devices.

Mobile Applications and Device Platforms

There are two dominant platforms in the modern smartphone market. One is the iOS platform
from Apple Inc. The iOS platform is the operating system that powers Apple's popular line of
iPhone smartphones. The second is Android from Google. The Android operating system is
used not only by Google devices but also by many other OEMs to built their own
smartphones and other smart devices.

Although there are some similarities between these two platforms when building applications,
developing for iOS vs. developing for Android involves using different software development
kits (SDKs) and different development toolchain. While Apple uses iOS exclusively for its
own devices, Google makes Android available to other companies provided they meet
specific requirements such as including certain Google applications on the devices they ship.
Developers can build apps for hundreds of millions of devices by targeting both of these
platforms.

Alternatives for Building Mobile Apps

There are four major development approaches when building mobile applications

 Native Mobile Applications

 Cross-Platform Native Mobile Applications
  Hybrid Mobile Applications
 Progressive Web Applications

Each of these approaches for developing mobile applications has its own set of advantages
and disadvantages. When choosing the right development approach for their projects,
developers consider the desired user experience, the computing resources and native features
required by the app, the development budget, time targets, and resources available to
maintain the app.

Native Applications

Native mobile applications are written in the programming language and frameworks
provided by the platform owner and running directly on the operating system of the device
such as iOS and Android.

Cross-Platform Applications

Cross-platform native mobile applications can be written in variety of different programming

languages and frameworks, but they are compiled into a native application running directly
on the operating system of the device.

Hybrid-Web Applications

Hybrid mobile applications are built with standard web technologies - such as JavaScript,
CSS, and HTML5 - and they are bundled as app installation packages. Contrary to the native
apps, hybrid apps work on a 'web container' which provides a browser runtime and a bridge
for native device APIs via Apache Cordova.

Progressive Web Applications

PWAs offer an alternative approach to traditional mobile app development by skipping app
store delivery and app installations. PWAs are web applications that utilize a set of browser
capabilities - such as working offline, running a background process, and adding a link to the
device home screen - to provide an 'app like' user experience.
 Pros

+ Shared code base + Same app is

+ Best runtime + Single code base for
between web and available both for
performance multiple platforms
mobile apps web and mobile

+ Using web
+ No installation
+ Direct access to + Easy to build and development skillset
required, accessible
device APIs maintain your app for building mobile
through a URL
apps

Cons

- Higher costs when - Dependents on

- Lower performance - Limited support
building and bridges and libraries
compared to native for native device
maintaining your for native device
apps features
app features

- Performance - App capabilities

- Multiple code- - Limited support for
limitations due to depend on the
bases for each native device features
bridging browser in use
platform

Comparing Native vs. Hybrid Applications

At the highest level, there are four main ways that native apps differ from hybrid apps as
illustrated in the following table.
Native Hybrid

Platform Specific Cross Platform

Compiled Language Scripting / Compiled

Access to Device Hardware Plugins / Native Modules

Platform Frameworks Web Frameworks

Why Choose the Hybrid/Cross-platform Approach?

One problem with native mobile application development is that it requires a highly
specialized skill set. Although there are large and vibrant developer communities for C and
Java -- the language families that are mostly used for native development --, there are fewer
developers who are knowledgeable in platform-specific versions of those languages and their
respective IDEs. In fact, skilled native app developers are in such demand, that many
companies are hard-pressed to hire and retain them on staff, and instead they frequently have
to resort to outside 3rd party design and development houses to build their apps for them.

How Hybrid and Cross-platform Frameworks Work?

Hybrid apps allow developers to use web technologies of HTML5/CSS/JavaScript and then
encapsulate those web applications in a container that allows the web application to act like a
native application on the device. Since hybrid mobile apps are just web apps running on an
embedded browser environment, most of the code from a web app can be used to build a
mobile app. As rendering and runtime performance of mobile browsers are ever-increasing,
hybrid development is a viable alternative for web developers who want to build mobile apps
quickly.

Similarly, PWAs are written using traditional web application programming technologies
usually including some variant of JavaScript, HTML5, and CSS, and are accessed initially
through a browser on the device or computer.

Most cross-platform frameworks such as - React Native and Native Script - provides native
components to work with the cross-platform code, while some others such as Flutter and
Xamarin compiles cross-platform code to the native code for better performance.

The Mobile Application Development Lifecycle

There are two interlinked core components of a mobile application: 1) the mobile application
“Front-End” that resides on the mobile device, and 2) the services “Back-End” that supports
the mobile front-end.

Front-end vs. Back-end

In the early days of the modern smartphone applications era, mobile applications went
through a similar evolution as first websites. At first, the applications and sites where wholly
contained within themselves and acted as little more than static advertisements for the brand,
company, product, or service.

However, as connectivity and network capabilities improved, the applications became

increasingly connected to sources of data and information that lived outside of the app itself,
and the apps became increasingly dynamic as they were able to update their UI and content
with data received over the network from queries to data sources.
As a result, the mobile front-end applications increasingly rely on and integrated with back-
end services which provide data to be consumed through the mobile front-end. Such data can
include, for example, product information for e-commerce apps or flight info for travel and
reservation apps. For a mobile game, the data may include new levels or challenges and
scores or avatars from other players.

How Front-end 'Talks' to the Back-end?

The mobile front-end obtains the data from the back-end via a variety of service calls such as
APIs. In some cases, these APIs may be owned and operated by the same entity developing
the mobile application. In other cases, the API may be controlled by a third party and access
is granted to the mobile application via a commercial arrangement.

For example, a developer may obtain social media or advertising content by making calls to
media or advertising company services. In this case, a developer may have to sign a contract
in order to obtain credentials and a key that grants access to the API and governs how that
developer can use it, how much it will cost, or how frequently it may be called, or how much
data can be requested over what time period.

Why Developers Use a Cloud-backend?

For most of the applications, mobile developers are responsible for creating and managing the
back-end services for their application. The mobile developer may not be an expert or even
particularly skilled in spinning up and running a back-end infrastructure.

In such a case, developers may prefer to take advantage of a cloud services provider -- a
backend-as-a-service provider -- that handles all of the drudge work and heavy lifting of
managing back-end capabilities, so the developers can focus purely on the features and
functionality they are building in their app, without having to worry about scalability,
security, and reliability.

The Mobile Application Front-End

The mobile front-end is the visual and interactive part of the application the user experiences.
It usually resides on the device, or there is at least an icon representing the app that is visible
on the home screen or is pinned in the application catalog of the device. The application can
be downloaded from the platform app store, side-loaded directly onto the device, or can be
reached through the device’s browser, as in the case for PWAs.

What a Front-end Development Workflow Looks Like?

When a developer says they are a mobile application programmer, they are most often
referring to this front-end part of the application, and they are skilled in the languages and
technologies that are used to create this front-end application.

Depending on the size of the team producing the app, there may be many different people
involved in the design and development of the front-end mobile app. The team size can range
from a single developer who does everything associated with building the app, to tens,
hundreds, and more people with specialized skills.

For example, there may be dedicated creative/graphics designers who are responsible for
creating visual elements of applications like icons, backgrounds, colors, themes and other
parts of the app. The team may also have user experience and user interface designs who
work on the layout of the components, how they interact with each other and the user. In the
case of certain types of games, a team may include motion graphics developers and even
engineers who develop engines that govern the physics of how components move in the app,
like a car in a racing game.

How Mobile Aps Integrate with the Backend?

Regardless of the size of the team, a critical element of the development effort is building the
app logic that is responsible for making network calls to the back-end services, retrieve data
and update the data in the back-end systems with new information generated from the app.

These back-end services are typically accessed through a variety of application programming
interfaces, most commonly known as APIs. There are different types of APIs, such as REST
and GraphQL, and there are also a wide variety of means and styles of accessing them. While
some back-end service APIs are available directly to the application through calls in the
platform itself, many of the specialized services have to be integrated into the app via a
software development kit, commonly known as an SDK. Once the SDK has been added to
the app via the development environment, then the application can make use of the APIs
defined in the SDK.

How to Interact with the Backend Data?

An example of a back-end service for a mobile front-end could be a database that contains
information used in the app. To access the database directly, the mobile developer would
have to know the network location of the database, the protocol for accessing the database,
the credentials for authenticating and authorizing the data access, and the specific database
commands needed to extract the needed data.

Alternatively, the developer can utilize a specialized API when interacting with the database;
the developer may only have to know the parameters needed in a method call to get or
updated the needed information. In some cases, the mobile developer may develop these
APIs themselves or use the API definition provided to them by the owner/operator of the
back-end resource.

Typically, a REST API is used to interact with data sources on the cloud, such as a cloud
database. A GraphQL API is also another option for developers, as it makes easy to work
with backend data in a mobile application. GraphQL provides querying support through a
single API endpoint, and a data schema that can be used to build and easily extend data
models that are used in the app.

The Mobile Application Back-End

Regardless of what front-end platform or development methodology is being used, delivering

high-quality mobile applications that delight and retain users requires reliable back-end
services.

Given the critical importance of back-end services for the success of the mobile application,
the developers have several important architectural decisions that they must consider. These
decisions include which services should they build themselves and which third party services
should they leverage, and then should they run and maintain their own services or should they
take advantage of 3rd party services.
The answer is increasingly clear; to improve developer productivity and efficiency, mobile
app programmers should only build their own services if they are highly specific to the
domain of the application and embody unique intellectual property. Also, even for the
services they build themselves, they should almost always leverage cloud-based services to
build and maintain their backend infrastructure.

Key Mobile Application Services

There are hundreds of cloud and 3rd party services that mobile application developers can
leverage to speed up the development and delivery of their applications. However, it’s
unlikely that a developer is going to be able to become an expert in each of these individual
services.

Instead, the mobile developers should look for a development environment that makes it
easier for them to integrate, use, and consume the most commonly required capabilities into
their application quickly and easily, while still preserving the freedom to take advantage of
the many individual services available.

Essential

 User Sign-up/Sign-in and Management

 Social login (Facebook sign-in, Twitter sign-in, etc.)
 Analytics and User Engagement
 Push Notifications
 Real Device Testing

Data Services

 Cloud Storage
 Real-time and Offline Data
 Application Logic/Cloud Functions

Machine Learning

 Conversational Bots
 Image and Video Recognition
 Speech Recognition

Android Layout
Android Layout is used to define the user interface that holds the UI controls or widgets
that will appear on the screen of an android application or activity screen. Generally, every
application is a combination of View and ViewGroup. As we know, an android application
contains a large number of activities and we can say each activity is one page of the
application. So, each activity contains multiple user interface components and those
components are the instances of the View and ViewGroup. All the elements in a layout are
built using a hierarchy of View and ViewGroup objects.

View

A View is defined as the user interface which is used to create interactive UI components
such as TextView, ImageView, EditText, RadioButton, etc., and is responsible for event
handling and drawing. They are Generally Called Widgets.

View

A ViewGroup act as a base class for layouts and layouts parameters that hold other Views
or ViewGroups and to define the layout properties. They are Generally Called layouts.

ViewGroup

 The Android framework will allow us to use UI elements or widgets in two

ways: Use UI elements in the XML file
 Create elements in the Kotlin file dynamically
Types of Android Layout

 Android Linear Layout: LinearLayout is a ViewGroup subclass, used to

provide child View elements one by one either in a particular direction either
horizontally or vertically based on the orientation property.
 Android Relative Layout: RelativeLayout is a ViewGroup subclass, used to
specify the position of child View elements relative to each other like (A to the
right of B) or relative to the parent (fix to the top of the parent).
 Android Constraint Layout: ConstraintLayout is a ViewGroup subclass, used
to specify the position of layout constraints for every child View relative to other
views present. A ConstraintLayout is similar to a RelativeLayout, but having
more power.
 Android Frame Layout: FrameLayout is a ViewGroup subclass, used to
specify the position of View elements it contains on the top of each other to
display only a single View inside the FrameLayout.
 Android Table Layout: TableLayout is a ViewGroup subclass, used to display
the child View elements in rows and columns.
 Android Web View: WebView is a browser that is used to display the web
pages in our activity layout.
 Android ListView: ListView is a ViewGroup, used to display scrollable lists of
items in a single column.
 Android Grid View: GridView is a ViewGroup that is used to display a
scrollable list of items in a grid view of rows and columns.
Introduction to activities
bookmark_border

The Activity class is a crucial component of an Android app, and the way activities are
launched and put together is a fundamental part of the platform's application model. Unlike
programming paradigms in which apps are launched with a main() method, the Android
system initiates code in an Activity instance by invoking specific callback methods that
correspond to specific stages of its lifecycle.

This document introduces the concept of activities, and then provides some lightweight
guidance about how to work with them. For additional information about best practices in
architecting your app, see Guide to App Architecture.

The concept of activities

The mobile-app experience differs from its desktop counterpart in that a user's interaction
with the app doesn't always begin in the same place. Instead, the user journey often begins
non-deterministically. For instance, if you open an email app from your home screen, you
might see a list of emails. By contrast, if you are using a social media app that then launches
your email app, you might go directly to the email app's screen for composing an email.

The Activity class is designed to facilitate this paradigm. When one app invokes another, the
calling app invokes an activity in the other app, rather than the app as an atomic whole. In
this way, the activity serves as the entry point for an app's interaction with the user. You
implement an activity as a subclass of the Activity class.

An activity provides the window in which the app draws its UI. This window typically fills
the screen, but may be smaller than the screen and float on top of other windows. Generally,
one activity implements one screen in an app. For instance, one of an app’s activities may
implement a Preferences screen, while another activity implements a Select Photo screen.

Most apps contain multiple screens, which means they comprise multiple activities.
Typically, one activity in an app is specified as the main activity, which is the first screen to
appear when the user launches the app. Each activity can then start another activity to
perform different actions. For example, the main activity in a simple e-mail app may provide
the screen that shows an e-mail inbox. From there, the main activity might launch other
activities that provide screens for tasks like writing e-mails and opening individual e-mails.

Although activities work together to form a cohesive user experience in an app, each activity
is only loosely bound to the other activities; there are usually minimal dependencies among
the activities in an app. In fact, activities often start up activities belonging to other apps. For
example, a browser app might launch the Share activity of a social-media app.

To use activities in your app, you must register information about them in the app’s manifest,
and you must manage activity lifecycles appropriately. The rest of this document introduces
these subjects.
Configuring the manifest
For your app to be able to use activities, you must declare the activities, and certain of their
attributes, in the manifest.

Declare activities

To declare your activity, open your manifest file and add an <activity> element as a child of
the <application> element. For example:

<manifest ... >

<application ... >
<activity android:name=".ExampleActivity" />
...
</application ... >
...
</manifest >

The only required attribute for this element is android:name, which specifies the class name
of the activity. You can also add attributes that define activity characteristics such as label,
icon, or UI theme. For more information about these and other attributes, see
the <activity> element reference documentation.

Note: After you publish your app, you should not change activity names. If you do, you might break some
functionality, such as app shortcuts. For more information on changes to avoid after publishing, see Things
That Cannot Change.
Declare intent filters

Intent filters are a very powerful feature of the Android platform. They provide the ability to
launch an activity based not only on an explicit request, but also an implicit one. For example,
an explicit request might tell the system to “Start the Send Email activity in the Gmail app".
By contrast, an implicit request tells the system to “Start a Send Email screen in any activity
that can do the job." When the system UI asks a user which app to use in performing a task,
that’s an intent filter at work.

You can take advantage of this feature by declaring an <intent-filter> attribute in

the <activity> element. The definition of this element includes an <action> element and,
optionally, a <category> element and/or a <data> element. These elements combine to
specify the type of intent to which your activity can respond. For example, the following code
snippet shows how to configure an activity that sends text data, and receives requests from
other activities to do so:

<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon">

<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="text/plain" />
</intent-filter>
</activity>

In this example, the <action> element specifies that this activity sends data. Declaring
the <category> element as DEFAULT enables the activity to receive launch requests.
The <data> element specifies the type of data that this activity can send. The following code
snippet shows how to call the activity described above:

KotlinJava

val sendIntent = Intent().apply {

action = Intent.ACTION_SEND
type = "text/plain"
putExtra(Intent.EXTRA_TEXT, textMessage)
}
startActivity(sendIntent)

If you intend for your app to be self-contained and not allow other apps to activate its activities, you
don't need any other intent filters. Activities that you don't want to make available to other
applications should have no intent filters, and you can start them yourself using explicit intents. For
more information about how your activities can respond to intents, see Intents and Intent Filters.

Declare permissions

You can use the manifest's <activity> tag to control which apps can start a particular activity.
A parent activity cannot launch a child activity unless both activities have the same
permissions in their manifest. If you declare a <uses-permission> element for a parent activity,
each child activity must have a matching <uses-permission> element.

For example, if your app wants to use a hypothetical app named SocialApp to share a post on
social media, SocialApp itself must define the permission that an app calling it must have:

<manifest>
<activity android:name="...."
android:permission=”com.google.socialapp.permission.SHARE_POST”

/>

Then, to be allowed to call SocialApp, your app must match the permission set in SocialApp's
manifest:

<manifest>
<uses-permission android:name="com.google.socialapp.permission.SHARE_POST" />
</manifest>

For more information on permissions and security in general, see Security and Permissions.

Managing the activity lifecycle

Over the course of its lifetime, an activity goes through a number of states. You use a series
of callbacks to handle transitions between states. The following sections introduce these
callbacks.

onCreate()

You must implement this callback, which fires when the system creates your activity. Your
implementation should initialize the essential components of your activity: For example, your
app should create views and bind data to lists here. Most importantly, this is where you must
call setContentView() to define the layout for the activity's user interface.

When onCreate() finishes, the next callback is always onStart().

onStart()

As onCreate() exits, the activity enters the Started state, and the activity becomes visible to the
user. This callback contains what amounts to the activity’s final preparations for coming to
the foreground and becoming interactive.

onResume()

The system invokes this callback just before the activity starts interacting with the user. At
this point, the activity is at the top of the activity stack, and captures all user input. Most of an
app’s core functionality is implemented in the onResume() method.

The onPause() callback always follows onResume().

onPause()

The system calls onPause() when the activity loses focus and enters a Paused state. This state
occurs when, for example, the user taps the Back or Recents button. When the system
calls onPause() for your activity, it technically means your activity is still partially visible, but
most often is an indication that the user is leaving the activity, and the activity will soon enter
the Stopped or Resumed state.

An activity in the Paused state may continue to update the UI if the user is expecting the UI
to update. Examples of such an activity include one showing a navigation map screen or a
media player playing. Even if such activities lose focus, the user expects their UI to continue
updating.

You should not use onPause() to save application or user data, make network calls, or execute
database transactions. For information about saving data, see Saving and restoring activity
state.

Once onPause() finishes executing, the next callback is either onStop() or onResume(),
depending on what happens after the activity enters the Paused state.

onStop()

The system calls onStop() when the activity is no longer visible to the user. This may happen
because the activity is being destroyed, a new activity is starting, or an existing activity is
entering a Resumed state and is covering the stopped activity. In all of these cases, the
stopped activity is no longer visible at all.

The next callback that the system calls is either onRestart(), if the activity is coming back to
interact with the user, or by onDestroy() if this activity is completely terminating.

onRestart()

The system invokes this callback when an activity in the Stopped state is about to
restart. onRestart() restores the state of the activity from the time that it was stopped.

This callback is always followed by onStart().

onDestroy()

The system invokes this callback before an activity is destroyed.

This callback is the final one that the activity receives. onDestroy() is usually implemented to
ensure that all of an activity’s resources are released when the activity, or the process
containing it, is destroyed.

This section provides only an introduction to this topic. For a more detailed treatment of the
activity lifecycle and its callbacks, see The Activity Lifecycle.

Intents and intent filters

bookmark_border

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, there are
three fundamental use cases:

 Starting an activity

An Activity represents a single screen in an app. You can start a new instance of
an Activity by passing an Intent to startActivity(). The Intent describes the activity to
start and carries any necessary data.
If you want to receive a result from the activity when it finishes,
call startActivityForResult(). Your activity receives the result as a separate Intent object
in your activity's onActivityResult() callback. For more information, see
the Activities guide.
 Starting a service

A Service is a component that performs operations in the background without a user

interface. With Android 5.0 (API level 21) and later, you can start a service
with JobScheduler. For more information about JobScheduler, see its API-reference
documentation.

For versions earlier than Android 5.0 (API level 21), you can start a service by using
methods of the Service class. You can start a service to perform a one-time operation
 (such as downloading a file) by passing an Intent to startService(). The Intent describes
the service to start and carries any necessary data.
If the service is designed with a client-server interface, you can bind to the service
from another component by passing an Intent to bindService(). For more information,
see the Services guide.
 Delivering a broadcast

A broadcast is a message that any app can receive. The system delivers various
broadcasts for system events, such as when the system boots up or the device starts
charging. You can deliver a broadcast to other apps by passing
an Intent to sendBroadcast() or sendOrderedBroadcast().

The rest of this page explains how intents work and how to use them. For related information,
see Interacting with Other Apps and Sharing Content.

Intent types
There are two types of intents:

 Explicit intents specify which component of which application will satisfy the intent, by
specifying a full ComponentName. You'll typically use an explicit intent to start a component
in your own app, because you know the class name of the activity or service you want to start.
For example, you might start a new activity within your app in response to a user action, or
start a service to download a file in the background.
 Implicit intents do not name a specific component, but instead declare a general action to
perform, which allows a component from another app to handle it. For example, if you want
to show the user a location on a map, you can use an implicit intent to request that another
capable app show a specified location on a map.

Figure 1 shows how an intent is used when starting an activity. When the Intent object names
a specific activity component explicitly, the system immediately starts that component.

Figure 1. How an implicit intent is delivered through the system to start another activity: [1] Activity
A creates an Intent with an action description and passes it to startActivity(). [2] The Android System
searches all apps for an intent filter that matches the intent. When a match is found, [3] the system starts
the matching activity (Activity B) by invoking its onCreate() method and passing it the Intent.
When you use an implicit intent, the Android system finds the appropriate component to start
by comparing the contents of the intent to the intent filters declared in the manifest file of
other apps on the device. If the intent matches an intent filter, the system starts that
component and delivers it the Intent object. If multiple intent filters are compatible, the
system displays a dialog so the user can pick which app to use.

An intent filter is an expression in an app's manifest file that specifies the type of intents that
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.
Likewise, if you do not declare any intent filters for an activity, then it can be started only
with an explicit intent.

Caution: To ensure that your app is secure, always use an explicit intent when starting a Service and do
not declare intent filters for your services. Using an implicit intent to start a service is a security hazard
because you can't be certain what service will respond to the intent, and the user can't see which service
starts. Beginning with Android 5.0 (API level 21), the system throws an exception if you
call bindService() with an implicit intent.

Building an intent
An Intent object carries information that the Android system uses to determine which
component to start (such as the exact component name or component category that should
receive the intent), plus information that the recipient component uses in order to properly
perform the action (such as the action to take and the data to act upon).

The primary information contained in an Intent is the following:

Component name

The name of the component to start.

This is optional, but it's the critical piece of information that makes an intent explicit,
meaning that the intent should be delivered only to the app component defined by the
component name. Without a component name, the intent is implicit and the system
decides which component should receive the intent based on the other intent
information (such as the action, data, and category—described below). If you need to
start a specific component in your app, you should specify the component name.

Note: When starting a Service, always specify the component name. Otherwise, you cannot be
certain what service will respond to the intent, and the user cannot see which service starts.

This field of the Intent is a ComponentName object, which you can specify using a fully
qualified class name of the target component, including the package name of the app,
for example, com.example.ExampleActivity. You can set the component name
with setComponent(), setClass(), setClassName(), or with the Intent constructor.

Action

A string that specifies the generic action to perform (such as view or pick).
 In the case of a broadcast intent, this is the action that took place and is being
reported. The action largely determines how the rest of the intent is structured—
particularly the information that is contained in the data and extras.

You can specify your own actions for use by intents within your app (or for use by
other apps to invoke components in your app), but you usually specify action
constants defined by the Intent class or other framework classes. Here are some
common actions for starting an activity:

ACTION_VIEW

Use this action in an intent with startActivity() when you have some information that an
activity can show to the user, such as a photo to view in a gallery app, or an address to view in
a map app.

ACTION_SEND

Also known as the share intent, you should use this in an intent with startActivity() when you
have some data that the user can share through another app, such as an email app or social
sharing app.

See the Intent class reference for more constants that define generic actions. Other
actions are defined elsewhere in the Android framework, such as in Settings for
actions that open specific screens in the system's Settings app.

You can specify the action for an intent with setAction() or with an Intent constructor.

If you define your own actions, be sure to include your app's package name as a
prefix, as shown in the following example:

KotlinJava

const val ACTION_TIMETRAVEL = "com.example.action.TIMETRAVEL"

Data

The URI (a Uri object) that references the data to be acted on and/or the MIME type of that
data. The type of data supplied is generally dictated by the intent's action. For example, if the
action is ACTION_EDIT, the data should contain the URI of the document to edit.

When creating an intent, it's often important to specify the type of data (its MIME
type) in addition to its URI. For example, an activity that's able to display images
probably won't be able to play an audio file, even though the URI formats could be
similar. Specifying the MIME type of your data helps the Android system find the
best component to receive your intent. However, the MIME type can sometimes be
inferred from the URI—particularly when the data is a content: URI. A content: URI
indicates the data is located on the device and controlled by a ContentProvider, which
makes the data MIME type visible to the system.

To set only the data URI, call setData(). To set only the MIME type, call setType(). If
necessary, you can set both explicitly with setDataAndType().
 Caution: If you want to set both the URI and MIME
type, don't call setData() and setType() because they each nullify the value of the other. Always
use setDataAndType() to set both URI and MIME type.

Category

A string containing additional information about the kind of component that should handle the
intent. Any number of category descriptions can be placed in an intent, but most intents do not
require a category. Here are some common categories:

CATEGORY_BROWSABLE

The target activity allows itself to be started by a web browser to display data referenced by a
link, such as an image or an e-mail message.

CATEGORY_LAUNCHER

The activity is the initial activity of a task and is listed in the system's application launcher.

See the Intent class description for the full list of categories.

You can specify a category with addCategory().

These properties listed above (component name, action, data, and category) represent the
defining characteristics of an intent. By reading these properties, the Android system is able
to resolve which app component it should start. However, an intent can carry additional
information that does not affect how it is resolved to an app component. An intent can also
supply the following information:

Extras

Key-value pairs that carry additional information required to accomplish the requested action.
Just as some actions use particular kinds of data URIs, some actions also use particular extras.

You can add extra data with various putExtra() methods, each accepting two
parameters: the key name and the value. You can also create a Bundle object with all
the extra data, then insert the Bundle in the Intent with putExtras().

For example, when creating an intent to send an email with ACTION_SEND, you can
specify the to recipient with the EXTRA_EMAIL key, and specify the subject with
the EXTRA_SUBJECT key.

The Intent class specifies many EXTRA_* constants for standardized data types. If you
need to declare your own extra keys (for intents that your app receives), be sure to
include your app's package name as a prefix, as shown in the following example: