The document provides an overview of Android app development concepts including activity lifecycle, app architecture, navigation, and use of ViewModels. It discusses how activities transition through various states, principles of separation of concerns and unidirectional data flow in architecture, and how to implement navigation between screens in a multi-screen app while respecting architecture. Hands-on examples are provided for activity lifecycle, handling configuration changes with ViewModels, and navigation.
2. This work is licensed under the Apache 2.0 License
Aneesh Gupta
(2nd Year student in CSE Branch)
WHO AM I ?
My tech stack –
Android
Flutter
JAVA, Kotlin, Dart, XML
Real Projects Experience -> Working in start-ups to
accomplish real world problems.
Hobbies ->
Solving real problems
4. This work is licensed under the Apache 2.0 License
● Activity & Lifecycle
● What is Architecture & it’s Principles?
● Layers in Architecture
● What is Navigation?
● How to achieve Navigation?
Today’s AGENDA…
5. This work is licensed under the Apache 2.0 License
Faith-Based learning
Abstraction level of learning
How to study DEVELOPMENT ?
6. This work is licensed under the Apache 2.0 License
ACTIVITY
Activity is the entry point for interacting with the user.
During it’s lifetime, it transitions through various states which is known as
ACTIVITY LIFECYCLE.
Activity lifecycle extends from the creation of the activity to its destruction.
If an activity doesn’t respond correctly to lifecycle state changes, app can
generate bugs, strange behavior and may consume too many Android
resources.
7. Activity Lifecycle
onCreate() -> called
when activity is first
created.
onStart() -> called
when activity is
visible to user.
onResume() -> called
when activity is
interactable with the
user
onDestroy() -> called
when activity is
destroyed
onStop() -> called
when activity is no
longer visible to the
user
onPause() -> called
when activity is
about to lose focus.
8. This work is licensed under the Apache 2.0 License
Hands-on on
Activity Lifecycle
(A small demo on how activity lifecycle callbacks work)
9. This work is licensed under the Apache 2.0 License
ARCHITECTURE
Designing pattern and techniques to construct the app to have a right
structure to remain functional and safe under challenging conditions
Advantages –
Easier to Test
Makes App Robust
Easy to Collaborate
Makes App Scalable
10. PRINCIPLES
()(Must be Followed)
This work is licensed under the Apache 2.0 License
SOC
()(Separation of Concern)
Every component must have it’s own functionality and must not
intervene with the logic of other components.
For eg. UI components must know only about UI composables and
should not know anything about the data to be presented in the UI.
UDF
()(Unidirectional Flow)
UI Components must ask the Data component for the data to be
displayed on the screen and similarly, should expose any event /
user interaction to the data component to update the data
accordingly.
11. This work is licensed under the Apache 2.0 License
● Activity’s lifecycle is tied to the Android Operating System.
● Change in configuration of the app results in creation of a new
instance for the activity.
● If Data of the app is maintained within the activity, it might get
lost and hence, we would loose the state of our app!!
● So, it’s important to separate all the app data and resources into
such files which are independent of the Android framework.
How to Apply ??
To achieve the same, we’ll now think of UI and Data as 2 separate layers
Data Layer - a layer that displays the app data on the screen but is independent of
the data
UI Layer - a layer that stores, retrieves, and exposes the app data.
12. This work is licensed under the Apache 2.0 License
Hands-on on
Activity Configuration Changes
(How data is lost if stored in activity during
configuration changes)
13. WHAT IS STATE?
State in an app is any value that can change over time.
• For eg. In a TextField, state is the TEXT that is being entered by the user. As soon as the user types in a new
character, the state of the TextField (i.e. it’s text) is changed.
Compose is declarative and as such the only way to update it is by calling the same composable with new
arguments. (i.e. a New State)
Any time a state is updated a recomposition takes place.
As a result, things like TextField don’t automatically update like they do in imperative XML based views. A
composable has to explicitly be told the new state in order for it to update accordingly.
This work is licensed under the Apache 2.0 License
UI is what user sees, BUT UI State is what the app says
they should see…
UI is a result of binding UI elements on the screen with
UI state…
14. This work is licensed under the Apache 2.0 License
NEED OF UDF
If code in both layers hold refence of each
other and there’s no unidirectional flow, then
there’s no Separation of Concern.
There must be flow of data in the following
manner ->
UI exposes events to Data.
Data changes and updates are observed
by UI.
Data Layer
UI Layer
Data Layer
UI Layer
Events Data
Hence, Unidirectional Flow is important, else would lead to
Data dependency on Android Framework
15. Layers of UI
UI Layer has 2 components –
• UI Elements (Composables)
• State Holders (ViewModel)
ViewModel holds and exposes state that the
UI elements consume.
It stores the app related data that isn’t
destroyed when the activity is destroyed and
recreated by Android Framework
Unlike the activity instance, ViewModel
objects are not destroyed on configuration
change
This frees up the UI and make it focus solely
on to read and update the UI elements
accordingly.
This work is licensed under the Apache 2.0 License
16. This work is licensed under the Apache 2.0 License
How to implement ViewModel?
StateFlow
It’s a data holder observable flow that emits the current
and new state updates. (In our eg, the new UI State)
To update state and send it to the flow, assign a new
value to the value property of the Mutable State Flow
class.
It can be exposed from the new UI State, so that the
composables can listen for UI updates and make screen
state survive configuration changes.
Backing Property
A backing property lets you return something from a getter
other than the exact object.
To implement a backing property, you override the getter
method to return a read-only version of your data.
This backing property protects the app data inside the
ViewModel from unwanted and unsafe changes by external
classes, but it lets external callers safely access its value.
Before we proceed, we need to understand the following terms ->
17. This work is licensed under the Apache 2.0 License
Hands-on on ViewModel
(What do you need to know to implement a ViewModel)
18. This work is licensed under the Apache 2.0 License
Create UIState
Create GameUIState data class
consisting of the different state
components of the app which will
be exposed to UI by ViewModel to
make updates in UI
Get Current State
of the App
Use asStateFlow() on a
mutableStateFlow instance
(i.e. GameUIState instance here) to
implement Backing property on UI
State.
Get Random word
to be displayed
Implement a new function to get
unused random word.
Summarizing UnScramble App
Create ViewModel
Create a GameViewModel
extending ViewModel class
ViewModel in
Composable
Instantiate ViewModel in Parent
Composable.
Get State in
Composable from
ViewModel
Use collectAsState() to obtain
new UiState from ViewModel
Pass Lambda
Expressions for
events
ViewModel receives the events via
lambda expressions and update
UIState accordingly which is then
observed by the
mutableStateFlow instance in
Composable.
Handle Last
Round
As soon as the size of set
containing usedWords becomes
equal to 10, show a popup, to the
user, in which if Play Again is
selected, reset the game, else
finish the activity.
19. Let’s try change in
device configuration…
You’ll observe that when the device is rotated, though activity
gets destroyed and is being created again by the Android
Operating System, but the state of the app doesn’t change. This
is because ViewModel’s instance doesn’t get cleared off and
therefore the new Composables so formed get their data to be
displayed from the state stored with ViewModel.
20. This work is licensed under the Apache 2.0 License
ViewModel is a life-saver for change in
configurations…
21. This work is licensed under the Apache 2.0 License
NAVIGATION…
Till Now, you saw Single Screen Apps in all our session. But now, let’s deep
dive into Multi-Screen Apps.
Navigation Compose Component allows you to build multiscreen apps in
Compose using a declarative approach.
You’ll also get to know how to send data from your app to another
using intents.
22. This work is licensed under the Apache 2.0 License
● NavController : Used to navigate b/w destinations
(screens of the app)
● NavGraph : Maps composable destinations
● NavHost : Composable Container for displaying
current destination
Parts of Navigation Component
23. This work is licensed under the Apache 2.0 License
( How to properly implement Navigation in
multi-screen app while we respect the
architecture principles such as SOC )
Hands-on on Navigation
24. This work is licensed under the Apache 2.0 License
Steps to achieve Navigation
2 3 5
4
1
Define
Routes
• Route -> A string
corresponding to a
specific destination.
• Route is a unique
identifier for a
destination.
• HOW TO DEFINE
ONE -> Using Enum
classes
Initialize
NavHost
• Displays a specific
screen on the basis
of route selected.
• Mandatory
arguments ->
NavController &
StartDestination
(first screen to be
shown by default)
Understanding
NavController
• NavHostController instance
helps to navigate to
different screens using
navigate() function.
• Obtained by calling
rememberNavController()
Handle
Routes
• Navhost takes
composable()
function as it’s
content.
• For each screen, a
separate
composable() is
required which
consists of route name
and the Composable
to be displayed.
Respect
Architecture
• We can’t pass
NavController as a
parameter to every
screen to handle
navigation. (Each
screen should not be
aware of any other
screen)
• Hence, we pass a
function type in each
composable to handle
the navigation.
25. This work is licensed under the Apache 2.0 License
Sometimes, we have to send some data from our
app to another app (For eg. while making
payments, the app usually navigates us to some
other payment-making app).
Since, this functionality is provided by the Android
Operating System, we don’t use NavController, but
something called an INTENT.
Navigating to Another App
26. This work is licensed under the Apache 2.0 License
Steps to achieve Navigation to
Another App
• Pass any additional data
to intent by using
putExtra() method.
• Intent takes 2 extras ->
EXTRA_SUBJECT &
EXTRA_TEXT
• It’s required to pass type of
data being sent to the other
app.
• For eg. A simple piece of text is
sent using text/plain
• An image is sent using image/*
• A video is sent using video/*
• Create an Intent object
and specify the intent. (For
eg, ACTION_SEND)
An intent is a request for the system to perform some action, commonly presenting a new activity.
Create
Intent
Specify type
of data being
sent
Pass data
to Intent
Start the
Intent
• Call startActivity() method of
context.
• Context can be received using
LocalContext.current
27. This work is licensed under the Apache 2.0 License
POINTS TO NOTE:
To make the app fully interactive, the APPBAR should also support
navigation functionality.
System back button provided by
Android operating system.
Up button, located in the app’s
Top Bar.
Up button in the app’s top bar can be implemented properly using
currentBackStackEntry()
28. WHAT IS
BACKSTACK???
When the app is first launched and displays it’s start destination, Navigation
Component creates a new BackStack to represent the navigation state of your
app.
As soon as the app launches, the first screen’s instance is pushed to this
backstack
As the user navigates to different screen, each screen keeps on adding in the
backstack, so that the previous screen can be displayed if the user hits on back
button on the bottom navigation bar.
29. This work is licensed under the Apache 2.0 License
BACKSTACK
30. THAT’s IT??
This work is licensed under
the Apache 2.0 License
Nope…,
Let’s go for the
Q&A SESSION…
31. THANK YOU!!!
This work is licensed under the Apache 2.0 License
GDSC-NSUT thanks you all for
your valuable time…
Signing off…