@azdocuments

https://www.azdocuments.in/
Mobile Application Development 18CS651

MODULE
ODULE-1 : INTRODUCTION
1.1 Build your first app : Introduction to Android

The development process

An Android app project begins with an idea and a definition of the requirements necessary
to realize that idea. You may want to sketch user interfaces (UIs) fo
for the various app
functions. To show what a UI would look like and how it would work, use drawings,
mockups, and prototypes.

When you are ready to start coding, you use Android Studio to go through the following
steps:

1. Create the project in Android Studio and choose an appropriate template.

2. Define a layout for each screen that has UI elements. You can place UI elements on
the screen using the layout editor, or you can write code directly in the Extensible
Markup Language (XML).
3. Write code using the Java pr
programming
ogramming language. Create source code for all of the
app's components.
4. Build and run the app on real and virtual devices. Use the default build
configuration or create custom builds for different versions of your app.©
5. Test and debug the app's logic and U
UI.
6. Publish the app by assembling the final APK (package file) and distributing it
through channels such as Google Play.

AzDocuments.in 1
Mobile Application Development 18CS651

Using Android Studio

Android Studio provides a unified development environment for creating apps for all
Android-powered
powered devices. Andro
Android
id Studio includes code templates with sample code for
common app features, extensive testing tools and frameworks, and a flexible build system.

Starting an Android Studio project

After you have successfully installed the Android Studio IDE, double
double--click the Android
Studio application icon to start it. Click Start a new Android Studio project in the
Welcome window, and name the project the same name that you want to use for the app.

When choosing a unique Company domain

domain,, keep in mind that apps published to Google
Play must have a unique package name. Because domains are unique, prepending the app's
name with your name, or your company's domain name, should provide an adequately

AzDocuments.in 2
Mobile Application Development 18CS651

unique package name. If you don't plan to publish the app, you can accept the de
default
example domain. Be aware that changing the package name later is extra work.

Choosing target devices and the minimum SDK

When choosing Target Android Devices, Phone and Tablet are selected by default, as
shown in the figure below. The choice shown in the figure for the Minimum SDK—API
SDK
15: Android 4.0.3 (IceCreamSandwich)
(IceCreamSandwich)—makes
makes your app compatible with 97% of
Android-powered
powered devices active on the Google Play Store.

Different devices run different versions of the Android system, such as Android 4.0.3 oor
Android 4.4. Each successive version often adds new APIs not available in the previous
version. To indicate which set of APIs are available, each version specifies an API level.
For instance, Android 1.0 is API level 1 and Android 4.0.3 is API level 15.

The Minimum SDK declares the minimum Android version for your app. Each successive
version of Android provides compatibility for apps that were built using the APIs from
previous versions. That means your app should always be compatible with future versions
version
of Android, if you use the documented Android APIs.

AzDocuments.in 3
Mobile Application Development 18CS651

Choosing an Activity template

An Activity is a single, focused thing that the user can do. It is a crucial com
component of any
Android app. An Activity typically has a layout associated with it that defines how UI
elements appear on a screen.
Android Studio pre-populates
populates your project with minimal code for an Activity and layout
based on a template.. Available Activity templates range from a virtually blank template
(Add No Activity) to an Activity that includes navigation and an options menu.

You can customize the Activity after you select your template. For example, the Empty
Activity choice provides a single Activity with a single layout resource for the screen.
The Configure Activity screen appears after you click Next.. On the Configure
Activity screen you can accept the commonly used name for the Activity (such as Main
Activity),
), or you can change the name. Tip: This course covers the Activity class in more
detail in another practical. You can also read Introduction to Activities for comprehensive
introduction.

AzDocuments.in 4
Mobile Application Development 18CS651

The Configure Activity screen differs depending on which template you chose. In most
cases you can select the following options, if they are not already selected:

 Generate Layout file

file: Leave this checkbox selected to create the layout resource
connected to this Activity
Activity, which is usually named activity_main.
activity_main The layout
defines the UI for the Activity.
 Backwards Compatibility (AppCompat): Leave this checkbox selected to include
the AppCompat library. Use the AppCompat library to make sure that the app is
compatible with previous versions of Android, even if the app uses features found
only in newer Android versions.

1.2 Create Your First Android App

This lesson shows you how to create a new Android project with Android Studio, and it
describes some of the files
les in the project.

To create your new Android project, follow these steps:

AzDocuments.in 5
Mobile Application Development 18CS651

1. Install the latest version of Android Studio.

2. In the Welcome to Android Studio window, click Create New Project.
Project

Figure 1. Android
roid Studio welcome screen

If you have a project already opened, select File > New > New Project.

1. In the Select a Project Template window, select Empty Activity and click Next.
2. In the Configure your project window, complete the following:
 Enter "My First App"
pp" in the Name field.
 Enter "com.example.myfirstapp" in the Package name field.
 If you'd like to place the project in a different folder, change its Save location.
 Select either Java or Kotlin from the Language drop-down menu.
 Select the lowest version of Android your app will support in the Minimum
SDK field.
 If your app will require legacy library support, mark the Use legacy android.support
libraries checkbox.
 Leave the other options as they are.

AzDocuments.in 6
Mobile Application Development 18CS651

1. Click Finish.

After some processing time, the Android St

Studio main window appears.

Figure 2. Android Studio main window

Now take a moment to review the most important files.

First, be sure the Project window is open (select View > Tool Windows > Project)
Project and the
Android view is selected from the drop
drop-down list at the top of that window. You can
ca then see
the following files:

app> java > com.example.myfirstapp > MainActivity

This is the main activity. It's the entry point for your app. When you build and run your app,
the system launches an instance of this Activity and loads its layout.

app> res > layout > activity_main.xml

AzDocuments.in 7
Mobile Application Development 18CS651

This XML file defines the layout for the activity's user interface (UI). It contains
a TextView element with the text "Hello, World!"

app> manifests > AndroidManifest.xml

The manifest file describes the fundamental characteristics of the app and defines each of its
components.

Gradle Scripts > build.gradle

There are two files with this name: one for the project, "Project: My_First_App," and one for
the app module, "Module: My_First_App.app." Each module has its own build.gradle file,
but this project currently has just one module. Use each module's build.gradle file to control
how the Gradle plugin builds your app. For more information about this file, see Configure
your build.

To run the app, continue to the next lesson, Run your app.

1.3 Layouts

A layout defines the structure for a user interface in your app, such as in an activity. All
elements in the layout are built using a hierarchy of View and ViewGroup objects.
A View usually draws something the user can see and interact with. Whereas a ViewGroup is
an invisible container that defines the layout structure for View and other ViewGroup objects,
as shown in figure 1.

Figure 1. Illustration of a view hierarchy, which defines a UI layout

AzDocuments.in 8
Mobile Application Development 18CS651

The View objects are usually called "widgets" and can be one of many subclasses, such
as Button or Text View. The View Group objects are usually called "layouts" can be one of
many types that provide a different layout structure, such as Linear Layout or Constraint
Layout .

You can declare a layout in two ways:

 Declare UI elements in XML. Android provides a straightforward XML vocabulary

that corresponds to the View classes and subclasses, such as those for widgets and
layouts.

 You can also use Android Studio's Layout Editor to build your XML layout using a
drag-and-drop interface.

 Instantiate layout elements at runtime. Your app can create View and ViewGroup
objects (and manipulate their properties) programmatically.

 Declaring your UI in XML allows you to separate the presentation of your app from
the code that controls its behavior. Using XML files also makes it easy to provide
different layouts for different screen sizes and orientations (discussed further
in Supporting Different Screen Sizes).

The Android framework gives you the flexibility to use either or both of these methods to
build your app's UI. For example, you can declare your app's default layouts in XML, and
then modify the layout at runtime.

1.4 Views and Resources

All of the views in a window are arranged in a single tree. You can add views either from
code or by specifying a tree of views in one or more XML layout files. There are many
specialized subclasses of views that act as controls or are capable of displaying text, images,
or other content.

Once you have created a tree of views, there are typically a few types of common operations
you may wish to perform:

AzDocuments.in 9
Mobile Application Development 18CS651

 Set properties: for example setting the text of a TextView. The available properties
and the methods that set them will vary among the different subclasses of views. Note
that properties that are known at build time can be set in the XML layout files.
 Set focus: The framework will handle moving focus in response to user input. To
force focus to a specific view, call requestFocus().
 Set up listeners: Views allow clients to set listeners that will be notified when
something interesting happens to the view. For example, all views will let you set a
listener to be notified when the view gains or loses focus. You can register such a
listener
using setOnFocusChangeListener(android.view.View.OnFocusChangeListener).
Other view subclasses offer more specialized listeners. For example, a Button exposes
a listener to notify clients when the button is clicked.
 Set visibility: You can hide or show views using setVisibility(int).

Resources public class Resourcesextends Object

java.lang.Object

↳ android.content.res.Resources

Known direct subclasses

MockResources

Class for accessing an application's resources. This sits on top of the asset manager of the
application (accessible through getAssets()) and provides a high-level API for getting typed
data from the assets.

The Android resource system keeps track of all non-code assets associated with an
application. You can use this class to access your application's resources. You can generally
acquire the Resources instance associated with your application with getResources().

The Android SDK tools compile your application's resources into the application binary at
build time. To use a resource, you must install it correctly in the source tree (inside your
project's res/ directory) and build your application. As part of the build process, the SDK
tools generate symbols for each resource, which you can use in your application code to
access the resources.

AzDocuments.in 10
Mobile Application Development 18CS651

Using application resources makes it easy to update various characteristics of your

application without modifying code, and—by providing sets of alternative resources—
enables you to optimize your application for a variety of device configurations (such as for
different languages and screen sizes). This is an important aspect of developing Android
applications that are compatible on different types of devices.

After Build.VERSION_CODES#R, Resources must be obtained by Activity or Context

created with Context.createWindowContext(int, Bundle). Application#getResources() may
report wrong values in multi-window or on secondary displays.

For more information about using resources, see the documentation about Application
Resources.

1.5 Text and Scrolling Views

public class ScrollView

extends FrameLayout

java.lang.Object
↳ android.view.View
↳ android.view.ViewGroup
↳ android.widget.FrameLayout
↳ android.widget.ScrollView

A view group that allows the view hierarchy placed within it to be scrolled. Scroll view may
have only one direct child placed within it. To add multiple views within the scroll view,
make the direct child you add a view group, for example LinearLayout, and place additional
views within that LinearLayout.Scroll view supports vertical scrolling only. For horizontal
scrolling, use HorizontalScrollView instead.Never add a RecyclerView or ListView to a
scroll view. Doing so results in poor user interface performance and a poor user experience.

1.6 Activities : Understanding Activities and Intents

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
AzDocuments.in 11
Mobile Application Development 18CS651

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 in order
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.

AzDocuments.in 12
Mobile Application Development 18CS651

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
AzDocuments.in 13
Mobile Application Development 18CS651

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:
KOTLIN
JAVA
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.
AzDocuments.in 14
Mobile Application Development 18CS651

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.

1.7 The Activity Lifecycle and Managing State

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()

AzDocuments.in 15
Mobile Application Development 18CS651

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().
AzDocuments.in 16
Mobile Application Development 18CS651

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.

1.8 Activities and Implicit Intents

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.

AzDocuments.in 17
Mobile Application Development 18CS651

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 application will satisfy the intent, by supplying either
the target app's package name or a fully-qualified component class name. 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.

AzDocuments.in 18
Mobile Application Development 18CS651

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 ccomponent 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 filt
filter,
er, 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 uuse.

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.

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 ord
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:

AzDocuments.in 19
Mobile Application Development 18CS651

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.

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

AzDocuments.in 20
Mobile Application Development 18CS651

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()

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:

AzDocuments.in 21
Mobile Application Development 18CS651

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:

1.9 Testing, debugging and using support libraries

About testing

Even though you have an app that compiles and runs and looks the way you want it to on
different devices, you must make sure that your app will behave the way you expect it to
in every situation, especially as your app grows and changes. Even if you try to manually
test your app every time you make a change—a tedious prospect at best—you might miss
something or not anticipate what end users might do with your app to cause it to fail.

Writing and running tests is a critical part of the software development process. Test-
driven development (TDD) is a popular software development philosophy that places tests
at the core of all software development for an app or service.This does not negate the need
for further testing, it merely gives you a solid baseline to work with.

Testing your code can help you catch issues early in development—when they are the least
expensive to address—and improve the robustness of your code as your app gets larger
and more complex. With tests in your code, you can exercise small portions of your app in
isolation, and in an automatable and repeatable manner for more efficient testing.

AzDocuments.in 22
Mobile Application Development 18CS651

The code you write to test your app doesn't end up in the production version of your app; it
lives only on your development machine, alongside your app's code in Android Studio.

Types of tests

Android supports several different kinds of tests and testing frameworks. Two basic forms
of testing Android Studio supports are local unit tests and instrumented tests.

Local unit tests are tests that are compiled and run entirely on your local machine with the
Java Virtual Machine (JVM). Use local unit tests to test the parts of your app (such as the
internal logic) that do not need access to the Android framework or an Android-powered
device or emulator, or those for which you can create fake ("mock" or stub) objects that
pretend to behave like the framework equivalents.

Instrumented tests are tests that run on an Android-powered device or emulator. These
tests have access to the Android framework and to Instrumentation information such as the
app's Context. You can use instrumented tests for unit testing, user interface (UI) testing,
or integration testing, making sure that the components of your app interact correctly with
other apps. Most commonly, you use instrumented tests for UI testing, which allows you
to test that your app behaves correctly when a user interacts with your app or enters a
specific input.
For most forms of user interface testing, you use the Espresso framework, which allows
you to write automated UI tests. You'll learn about instrumented tests and Espresso in
another chapter.

Unit Testing

Unit tests should be the fundamental tests in your app testing strategy. By creating and
running unit tests against your code, you can verify that the logic of individual functional
code areas or units is correct. Running unit tests after every build helps you catch and fix
problems introduced by code changes to your app.

A unit test generally exercises the functionality of the smallest possible unit of code
(which could be a method, class, or component) in a repeatable way. Create unit tests
when you need to verify the logic of specific code in your app. For example, if you unit

AzDocuments.in 23
Mobile Application Development 18CS651

test a class, your test might check that the class is in the right state. For a method, you
might test its behavior for different values of its parameters, especially null.
Typically, you test the unit of code in isolation, and your test monitors changes only to that
unit. You can use a mocking framework such as Mockito to isolate your unit from its
dependencies.You can also write your unit tests for Android in JUnit 4, a common unit
testing framework for Java code.

The Android Testing Support Library

The Android Testing Support Library provides the infrastructure and APIs for testing
Android apps, including support for JUnit 4. With the testing support library you can build
and run test code for your apps.

You may already have the Android Testing Support Library installed with Android Studio.
To check for the Android Support Repository, follow these steps:

1. In Android Studio choose Tools > Android > SDK Manager.

2. Click the SDK Tools tab, and look for the Support Repository.
3. If necessary, update or install the library.

The Android Testing Support Library classes are located under

the android.support.test package. There are also older testing APIs in android.test. You
should use the support libraries first, when given a choice between the support libraries
and the older APIs, as the support libraries help build and distribute tests in a cleaner and
more reliable fashion than directly coding against the API itself.

AzDocuments.in 24
For more please do visit
www.azdocuments.in

@azdocuments

https://www.azdocuments.in/