0% found this document useful (0 votes)
26 views5 pages

AAD Week3 LDQ

Uploaded by

Naveen S
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views5 pages

AAD Week3 LDQ

Uploaded by

Naveen S
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Android Application Development

Week 3 - Long Descriptive Question and Answer

1. Discuss About different types of Android Architecture.

In Android development, there are different architectural patterns that


developers can use to structure their applications. Each architecture has its
own set of principles and guidelines aimed at promoting separation of
concerns, scalability, maintainability, and testability. Here are some of the
most commonly used Android architectures:

Model-View-Controller (MVC):

In MVC architecture, the application is divided into three components:

 Model: Represents the data and business logic.


 View: Represents the UI elements and displays the data to the
user.
 Controller: Acts as an intermediary between the model and the
view, handling user input and updating the model accordingly.

MVC is straightforward and easy to implement, but it often leads to tight


coupling between components, making the codebase difficult to maintain
and test.

Model-View-Presenter (MVP):

MVP is an evolution of MVC, aiming to improve testability and separation


of concerns.

Model: Represents the data and business logic.


View: Represents the UI elements and delegates user input handling to the
presenter.

Presenter: Acts as an intermediary between the model and the view,


handling user input, updating the model, and updating the view
accordingly.

MVP separates the concerns more clearly compared to MVC, making it


easier to test and maintain the codebase.

Model-View-ViewModel (MVVM):

MVVM is another evolution of MVC, focusing on data binding and


separation of concerns.

Model: Represents the data and business logic.

View: Represents the UI elements and binds to the ViewModel.

ViewModel: Acts as a mediator between the model and the view, exposing
data and handling user actions. It also abstracts the UI logic from the view.

MVVM promotes a more reactive and declarative approach to UI


development, leveraging features like data binding and LiveData in
Android.

Clean Architecture:

Clean Architecture, proposed by Robert C. Martin (Uncle Bob), emphasizes


separation of concerns and dependency inversion.

The architecture is divided into layers:

 Presentation Layer: Contains UI components like activities,


fragments, and views.
 Domain Layer: Contains business logic and use cases.
 Data Layer: Contains data sources such as databases, network
services, and repositories.
Clean Architecture promotes testability, maintainability, and scalability by
enforcing clear boundaries between layers and minimizing dependencies.

Model-View-Intent (MVI):

MVI is a reactive architecture inspired by Redux and Flux.

Model: Represents the state of the application.

View: Represents the UI elements and observes changes in the model.

Intent: Represents user actions or events that trigger state changes in the
model.

MVI promotes unidirectional data flow and immutable state, making it


easier to reason about the application's behavior and maintain a
predictable UI.

Redux Architecture:

Redux is a predictable state container architecture originally developed for


web applications.

The architecture revolves around a single immutable state tree.

Actions: Represent user events or intents that trigger state changes.

Reducers: Pure functions that specify how the application's state changes
in response to actions.

Store: Holds the application's state tree and provides methods to dispatch
actions and subscribe to state changes.

Redux can be adapted to Android development using libraries like


ReduxKotlin or implementing custom solutions.

These are some of the most commonly used architectural patterns in


Android development. Each architecture has its own advantages and trade-
offs, and the choice of architecture depends on factors such as project
requirements, team preferences, and scalability needs.

2. Differentiate Implicit and Explicit Intent

In Android development, intents are used to facilitate communication


between different components of an application or between different
applications. There are two main types of intents: implicit intents and
explicit intents. Let's differentiate between them:

Implicit Intent:

 An implicit intent does not specify the exact component to be


invoked, such as the activity, service, or broadcast receiver.
 It is used to request functionality from other components of the
Android system that can handle the specified action.
 When an implicit intent is sent, the Android system determines
which component should respond based on the intent's action, data,
and category (if specified) and the capabilities of the installed
applications.
 Implicit intents are typically used for actions that can be performed
by multiple components, such as opening a web page, sending an
email, or viewing a map location.
 Example: If you want to open a web page in a web browser, you can
create an implicit intent with the action Intent.ACTION_VIEW and the
data URI of the web page. The Android system will then launch the
appropriate web browser application to handle the request.

Explicit Intent:
 An explicit intent specifies the exact component (e.g., activity,
service, or broadcast receiver) that should be invoked.
 It explicitly identifies the target component by providing its class
name or package name.
 Explicit intents are used for interactions within the same application
or for invoking specific components of other applications.
 When an explicit intent is sent, the Android system directly launches
the specified component without needing to resolve which
component should handle the intent.
 Example: If you want to navigate from one activity to another activity
within the same application, you can create an explicit intent that
specifies the target activity's class name. The Android system will
then launch the specified activity directly.

In summary, the main difference between implicit and explicit intents lies
in how the target component is specified. Implicit intents allow the
Android system to determine the appropriate component dynamically
based on the intent's action and data, while explicit intents explicitly
specify the target component to be invoked.

3. Create an android application which allows you to navigate to


two different websites from its home page. Implement navigation
to first website through implicit intent and second using explicit
intent.

Attached .apk file and zip file of the project.

You might also like