This project is an Android application for bank account management built using the MVVM architecture. It uses Room for local data persistence, LiveData for reactive UI updates, and ViewModel to separate business logic from the user interface.
The following sections describe the features implemented based on the instructor's roadmap. These 18 implemented features cover the requirements proposed in the assignment.
The RecyclerView was configured to display the list of accounts provided by the ContaViewModel through LiveData<List<Conta>>. This ensures that the UI is automatically updated whenever the database changes.
Each account item displays an icon based on its balance. Accounts with a negative balance show a warning icon, while accounts with a positive balance display a confirmation icon, making it easier to identify an account's status.
A delete button was added directly to each RecyclerView item. It invokes the corresponding method in the ContaViewModel, allowing accounts to be removed instantly, with changes immediately reflected in the UI.
The account number is passed through an Intent when opening EditarContaActivity. This allows the activity to identify and load the correct account for editing or deletion.
AdicionarContaActivity includes complete form validation, checking required fields and ensuring the account balance is a valid numeric value. This prevents inconsistent records from being stored in the database.
ContaDAO was extended with @Update and @Delete methods, allowing centralized update and deletion operations.
Custom SQL queries were implemented to search accounts by account number, account holder's name, or CPF, providing greater flexibility for searches.
ContaRepository and ContaViewModel were expanded to support updating, deleting, and searching accounts. All database operations run on background threads, following Android best practices.
EditarContaActivity retrieves the account number from the Intent, loads the corresponding account from the database, validates user input, and provides options to update or remove the account. The validation logic is consistent with the account creation screen.
BancoViewModel centralizes all financial operations, including deposits, withdrawals, and transfers. This keeps business rules separate from the UI layer.
The corresponding Activities validate that accounts exist and that transaction amounts are positive before performing deposits, withdrawals, or transfers. This prevents invalid or inconsistent operations.
Every financial operation generates a transaction record in the database. Transfers create two records: one debit transaction and one credit transaction, ensuring complete traceability.
PesquisarActivity provides a search system that allows users to search by account number, account holder's name, or CPF. Search results update the RecyclerView dynamically, improving the user experience.
The main screen displays the total balance across all accounts by summing every account balance, including negative balances, providing a realistic overview of the bank's financial status.
In TransacaoViewHolder, debit transaction amounts are displayed in red to improve the readability of the transaction history.
TransacaoDAO, TransacaoRepository, and TransacaoViewModel include search methods that filter transactions by account number, date, or transaction type (credit, debit, or all transactions).
TransacoesActivity initially displays all transactions and allows users to filter them according to different criteria, making it easier to review financial activity.
Financial operations performed through BancoViewModel are integrated with TransacaoViewModel, ensuring that every operation automatically generates and stores a corresponding transaction record.
UI Layer: ContasActivity, EditarContaActivity, AdicionarContaActivity, PesquisarActivity, TransacoesActivity, along with their adapters and view holders.
ViewModels: ContaViewModel, BancoViewModel, TransacaoViewModel.
Repositories: ContaRepository, TransacaoRepository.
DAOs: ContaDAO, TransacaoDAO.
Database: BancoDB class using Room as the local database.
| Application Structure | Component Interaction |
|---|---|
 |
 |
MVVM Architecture: The MVVM pattern was adopted to ensure a clear separation of responsibilities between the UI, business logic, and data layers.
Room Database: Room was chosen as the local persistence solution because of its simplicity, reliability, and seamless integration with Android Architecture Components.
Background Threads: All database operations are executed on background threads using @WorkerThread, preventing UI blocking and maintaining application responsiveness.
Intent-Based Parameter Passing: Intent.putExtra() is used to pass the account number between Activities, enabling smooth navigation and data sharing.
Reactive UI Updates: LiveData is used to observe account and transaction lists, allowing the RecyclerView to update automatically whenever the underlying data changes.
Conditional Icons: ContaViewHolder contains simple logic to display different icons depending on whether the account balance is positive or negative.
DAO-Level Filtering: Search filters are implemented directly in SQL queries within the DAO layer, improving performance and minimizing processing in the UI layer.
Code Organization and Reusability: Data access is centralized within the Repository layer, providing a single access point for database operations and making the codebase easier to maintain and extend.
UI Design: The application's color palette is based on the official colors of the Center for Informatics (CIn), giving the interface a visual style consistent with the institution's academic identity.