0% found this document useful (0 votes)
3 views8 pages

Task 2

The document outlines the design and functionality of an Expense Splitter feature for an Android app, enabling users to fairly divide shared expenses among a group. It details input requirements, validation rules, UI feedback states, and the importance of reactive validation in ensuring user-friendly interactions. The design emphasizes immediate feedback and accessibility to enhance usability for all users.

Uploaded by

LORD23
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)
3 views8 pages

Task 2

The document outlines the design and functionality of an Expense Splitter feature for an Android app, enabling users to fairly divide shared expenses among a group. It details input requirements, validation rules, UI feedback states, and the importance of reactive validation in ensuring user-friendly interactions. The design emphasizes immediate feedback and accessibility to enhance usability for all users.

Uploaded by

LORD23
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

Mind Matrix – AADK Session 7

ANDROID APP DEVELOPMENT: FIRST STEPS

GAGAN BV

ASCENDERS

Task 2 — Input, Validation & UI Feedback Plan

Date: 27 / 2 / 2026
AADK Session 7 2

1. Feature Description — Expense Splitter

The Expense Splitter enables groups of students to divide shared expenses — such as restaurant

bills, trips, or study materials — quickly and fairly.

Users provide:

 Total bill amount

 Number of people

 Optional tip percentage via a Slider

 Three toggles:

o Round Up Tip

o Split Equally

o Save to History

After calculation, the UI displays:

 Per-person payment amount

 Total bill including tip

This feature eliminates manual arithmetic errors and reduces friction in group expense

situations, particularly common in student environments.

2. Input & State Variables

State Variable Type Composable Validation Error UI Feedback


Rule
billAmountInput String OutlinedTextField Must be non- Error text: “Bill must
([Link]) blank and be greater than ₹0”.
parsed value Field border turns
>0 red (isError=true)
numPeopleInput String OutlinedTextField Must be non- Error text: “Enter at
([Link]) blank integer least 1 person”. Field
AADK Session 7 3

≥1 highlighted red
tipPercent Float Slider Always valid No error. Live
(0f–30f) (clamped by percentage label
slider range) updates dynamically
roundUp Boolean Switch No validation Switch color changes
(false) required (green/grey). Result
updates immediately
splitEqually Boolean Switch No validation If false → reserved
(true) required for future custom
split UI
saveToHistory Boolean Switch No validation Enables Save button
(false) required after successful
calculation

3. UI Feedback States

Valid Input State

All validation checks pass.

 OutlinedTextField borders show primary color

 No error helper text visible

 Calculate button enabled (primary styling)

 Result card animates into view with computed values

 Save button enabled if saveToHistory == true

Invalid Input State

One or more fields fail validation.

 Invalid fields display red border (isError=true)

 Error helper text appears beneath field


AADK Session 7 4

 Calculate button disabled (alpha=0.4, clickable=false)

 Result card displays placeholder (“—”)

 Focus automatically shifts to first invalid field

Empty State (Initial Launch)

 Fields show placeholder hint text

 Calculate button disabled

 Result card hidden (AnimatedVisibility=false)

 No error text visible until user taps Calculate (lazy validation)

Loading / Calculating State (Future-Ready Design)

If calculation becomes asynchronous (e.g., currency conversion API):

 CircularProgressIndicator replaces result text

 Buttons disabled during processing

In the current local-only implementation, derivedStateOf ensures instant calculation without

loading state.

4. Validation Logic — Reactive Implementation


AADK Session 7 5

Expense Splitter

■) (
Total Bill Amount

Number of People

Your Name (optional)

Tip Percentage: 18%

Round Up Tip?

Split Equally?

Save to History?

■Enter valid bill amount≥1and


person

Calculate Save Clear

Screen: bill TextField, people TextField, name TextField (optional), tip Slider, three toggles, error zone, three action
buttons (Calculate/Save/Clear),
Each Pays:■393.33 result card.
Total:■1,180 | Tip:
■180
People: 3 | Tip: 18%

Input Validation Flow — Valid vs Invalid Decision Path

Input Validation Flow — Valid Path vs Invalid Path

User Taps Calculate


All inputs submitted

false isValid? true


✗Show Errors validate(inputs) ✓Calculate
■field, button disabled
error text under ■button stays active
result shown

derivedStateOf recalculates
Compose recomposes result Text

Validation is implemented using derivedStateOf, ensuring automatic recomputation whenever

input state changes.

val isBillValid by derivedStateOf {

[Link]() &&

[Link]()?.let { it > 0 } == true

}
AADK Session 7 6

val isNumPeopleValid by derivedStateOf {

[Link]() &&

[Link]()?.let { it >= 1 } == true

val isFormValid by derivedStateOf {

isBillValid && isNumPeopleValid

Calculate Button Configuration

Button(

onClick = { [Link]() },

enabled = isFormValid,

modifier = [Link]().height([Link])

){

Text("Calculate Split")

Error Helper Text Example

if (!isBillValid && hasAttemptedSubmit) {

Text(

text = "Bill amount must be greater than ₹0",

color = [Link],

style = [Link]

}
AADK Session 7 7

This design ensures validation is declarative, consistent, and automatically synchronized with UI

state.

5. Reflection — Importance of Validation & Feedback

Validation and immediate feedback are foundational to professional-quality applications.

Without proper validation:

 A bill of “0” would produce meaningless results.

 numPeople = 0 would cause division-by-zero errors.

 Blank fields would propagate invalid state throughout the UI.

In a reactive Compose architecture, invalid state spreads instantly to all composables observing

it. This makes defensive validation critical.

Lazy validation — showing errors only after the first Calculate attempt — improves usability by:

 Allowing users to type freely

 Avoiding premature error flashing

 Providing correction guidance only when necessary

Combining:

 Disabled action buttons

 Clear descriptive error text

 Focus redirection

ensures accessibility compliance and usability for both sighted users and assistive technology

users (e.g., TalkBack).

If you would like, I can also tighten this into a shorter submission-ready version for strict word

limits while preserving technical quality.


AADK Session 7 8

You might also like