Final Semester Project Progress Report

on
( ANDROID EXPENSE TRACKER )
Bachelor of Technology
Degree
in
Computer Science & Engineering
By
MD KAIF ALI 1722210091
MD AZHARUDDIN 1722210090
SAIF QURAISHI 1722210138
ANUJ KUMAR 1722210046

Under the Guidance of:

(Mr. Devesh Garg )
Assistant Professor
APRIL 2021

I.T.S ENGINEERING COLLEGE

GREATER NOIDA

1
 Project Progress Report

1. Course : Bachelor of Technology

2. Semester : VIIth
3. Branch : Computer Science & Engineering
4. Project Title : Android Expense Tracker
5. Details of Students:

S. No. Roll No. Name Role as Signature

1 Team Leader
2 Designer
3 Coder, Tester
4 Report

6. SUPERVISOR:

(Name & Signature of Supervisor)

Remarks from Project Guide:

…………………………………………………………………………………
……………………………………………………………………………………
…………………………………………………………………………………
…………………………………………………………………………………
 ABSTRACT

In today’s fast and expansive life everyone is in a hurry to save money but at the end of the
month everyone felt disappointment. So we have come across an idea to track our expanse. This
application tries to solve the problem of every individual who is willing to know their expanse
and how they should count the expense. This is an android application which we can execute in
their smartphones and know about their expanse. Users can maintain their expanse which they
spend on different requirements. And at the end of the month they get to know how much they
spend money in the form of graphs and charts. This application also focused on new job holders,
interns and every individual who wants to keep record of their expanse can use this
application.This android expense tracker application tracks the income and expenditure of a user
on a daily basis and divides the income on a daily basis of expanse allowed. If the expanse
exceeds the daily expanse allowed then it will cut if from income and add it to the new daily
expanse amount allowed. If the expanse is lesser then it will add to savings and at the end of the
month it will generate a report which shows income expenditure from various multiple graphs.
 TABLE OF CONTENTS

CHAPTER NO. TITLE PAGE

NO.
SYNOPSIS III
LIST OF TABLES IV
LIST OF FIGURES

1. INTRODUCTION 8
1.1 SCOPE AND OBJECTIVE 8

2. SOFTWARE REQUIREMENTS AND SPECIFICATION 9

2.1 SYSTEM REQUIREMENTS 9

2.2 HARDWARE REQUIREMENTS 9

2.2 SOFTWARE REQUIREMENTS 9

2.3 SOFTWARE SPECIFICATION 10

2.3.1 INTRODUCTION TO ANDROID 10

2.3.2 USER INTERFACE 10

2.3.3 TOOL WINDOWS 11

2.3.4 NAVIGATION 12

2.3.5 GRADLE BUILD SYSTEM 12

2.3.6 MULTIPLE APK SUPPORT 13

2.3.7 DEBUG AND PROFILE TOOLS 13

2.3.6.1 INLINE DEBUGGING 13

2.3.8 PERFORMANCE MONITORS 14

 2.3.9 ALLOCATION TRACKER 14

2.3.10 CODE INSPECTIONS 14

3. SDLC METHODOLOGIES 15
1.1 WATERFALL MODEL 15

4. SYSTEM DESIGN 16

4.1 DATA FLOW DIAGRAM 16

4.1.1 DFD SYMBOLS 17

4.2 USE CASE DIAGRAM 19

4.3 SEQUENCE DIAGRAM 20

4.4 VIEWING EXPANSES 21

5. TESTING AND EVOLUTION 22

5.1 LEVEL OF TESTING 23

5.1.1 UNIT TESTING 24

5.1.2 INTEGRATION TESTING 24

5.1.3 SYSTEM TESTING 24

5.1.4 VALIDATION TESTING 24

5.1.5 OUTPUT TESTING 25

5.1.6 USER ACCEPTANCE TESTING 25

5.2 TEST CASES 26

5.2.1 USER LOGIN REGISTRATION 26

5.2.2 VALIDATION CRITERIA 26

6. PROJECT SNAPSHOTS 27
7. LIMITATIONS 29

8. FUTURE SCOPE 30

9 CONCLUSION 31
10. BIBLIOGRAPHY 32
 LIST OF FIGURES

CHAPTER NO. TITLE PAGE NO.

3 FIG 3.1 WATERFALL MODEL 15

4 FIG 4.1.1 DATABASE DETAIL 17
4 FIG 4.1.2 DATABASE LEVEL 18
4 FIG 4.2 USE CASE DIAGRAM 19
4 FIG 4.3 SEQUENCE DIAGRAM 20
4 FIG 4.4 VIEWING EXPANSES 21
6 FIG 6.1 PROJECT SNAPSHOTS 28
6 FIG 6.2 PROJECT SNAPSHOTS 29
 CHAPTER 1

INTRODUCTION

This Android Expense Tracker is an android based application that falls in the Finance
Category and serves the important purpose of managing finances which is a very important part
of everyone’s lifeThe software product went through the design, development, and the testing
phase as a part of the Software Development Lifecycle,The application’s interface is designed
using custom art elements, the functionality is implemented using Android Studio software,The
application is not much user intensive but just consists of having them enter the expense amount,
date, category and other optional attributes and With this entered information, the user is able to
see the expense details daily, weekly, monthly, and yearly in figures, graph the user is able to see
the expense details daily, weekly, monthly, and yearly in figures, graphs and the aim of this
project is to provide a solution to users on how to manage finances in any circumstance by
keeping track of their expenses every day. Ultimately, this contributes to societal well-being.

1.2 SCOPE AND OBJECTIVE

The aim of this project is to provide a solution to users on how to manage finances in any
circumstance by keeping track of their expenses every day. This application will help users to
manage the monthly budget more effectively.
 CHAPTER 2

SYSTEM REQUIREMENTS AND SPECIFICATION

2.1 SYSTEM REQUIREMENTS:

The Project application is loaded in Android Studio. We used Android Studio for Design and
coding of projects. Created and maintained all databases into SQL Server 2008, in that we create
tables, write query for store data or record of project.

2.2 HARDWARE REQUIREMENTS:

Laptop or PC

● i3 Processor Based Computer

● 1GB RAM
● 5 GB Hard Disk

Android Phone or Tablet

● 1.2 Quad core Processor or higher.

● 1 GB RAM

2.3 SOFTWARE REQUIREMENTS:

Laptop or PC

● Windows 7 or higher.
● SQL Server 2008
● Java
● Android Studio\

Android Phone or Tablet

● Android v5.0 or Higher

2.3 SOFTWARE SPECIFICATION

2.3.1 INTRODUCTION TO ANDROID

Android Studio is the official Integrated Development Environment (IDE) for Android app
development, based on IntelliJ IDEA . On top of IntelliJ's powerful code editor and developer
tools, Android Studio offers even more features that enhance your productivity when building
Android apps, such as:

● · A flexible Gradle-based build system

● · A fast and feature-rich emulator
● ·A unified environment where you can develop for all Android devices
● Instant Run to push changes to your running app without building a new APK
● Code templates and GitHub integration to help you build common app features and
import sample code
● · Extensive testing tools and frameworks
● · Lint tools to catch performance, usability, version compatibility, and other problems
● · C++ and NDK support
● · Built-in support for Google Cloud Platform, making it easy to integrate Google
Cloud Messaging and App Engine.

2.3.2 THE USER INTERFACE

● The toolbar lets you carry out a wide range of actions, including running your app and
launching Android tools.
● The navigation bar helps you navigate through your project and open files for editing. It
provides a more compact view of the structure visible in the Project window.
● The editor window is where you create and modify code. Depending on the current file
type, the editor can change. For example, when viewing a layout file, the editor displays
the Layout Editor.
● The tool window bar runs around the outside of the IDE window and contains the buttons
that allow you to expand or collapse individual tool windows.
 ● The tool windows give you access to specific tasks like project management, search,
version control, and more. You can expand them and collapse them.
● The status bar displays the status of your project and the IDE itself, as well as any
warnings or messages.

At any time, you can search across your source code, databases, actions, elements of the
user interface, and so on, by double-pressing the Shift key, or clicking the magnifying glass in
the upper right-hand corner of the Android Studio window. This can be very useful if, for
example, you are trying to locate a particular IDE action that you have forgotten how to trigger.

2.3.3 TOOL WINDOWS

Instead of using preset perspectives, Android Studio follows your context and
automatically brings up relevant tool windows as you work. By default, the most commonly
used tool windows are pinned to the tool window bar at the edges of the application window.

● To expand or collapse a tool window, click the tool’s name in the tool window bar. You
can also drag, pin, unpin, attach, and detach tool windows.
● To return to the current default tool window layout, click Window > Restore Default
Layout or customize your default layout by clicking Window > Store Current Layout as
Default.
● To show or hide the entire tool window bar, click the window icon in the bottom left-
hand corner of the Android Studio window.
● To locate a specific tool window, hover over the window icon and select the tool window
from the menu.
2.3.4 NAVIGATION

● ·Switch between your recently accessed files using the Recent Files action. Press
Control+E (Command+E on a Mac) to bring up the Recent Files action. By default, the
last accessed file is selected. You can also access any tool window through the left
column in this action.
● View the structure of the current file using the File Structure action. Bring up the File
Structure action by pressing Control+F12 (Command+F12 on a Mac). Using this action,
you can quickly navigate to any part of your current file.
● Search for and navigate to a specific class in your project using the Navigate to Class
action. Bring up the action by pressing Control+N(Command+O on a Mac). Navigate to
Class supports sophisticated expressions, including camel humps, paths, line navigate to,
middle name matching, and many more. If you call it twice in a row, it shows you the
results out of the project classes.
● · Navigate to a file or folder using the Navigate to File action. Bring up the Navigate
to File action by pressing Control+Shift+N (Command+Shift+O on a Mac). To
search for folders rather than files, add a / at the end of your expression.
● Navigate to a method or field by name using the Navigate to Symbol action. Bring up the
Navigate to Symbol action by pressing Control+Shift+Alt+N(Command+Shift+Alt+O on
a Mac).
● Find all the pieces of code referencing the class, method, field, parameter, or statement at
the current cursor position by pressing Alt+F7

2.3.5 Gradle Build System

Android Studio uses Gradle as the foundation of the build system, with more Android-
specific capabilities provided by the Android plugin for Gradle. This build system runs as an
integrated tool from the Android Studio menu, and independently from the command line. You
can use the features of the build system to do the following:

● Customize, configure, and extend the build process.

 ● Create multiple APKs for your app, with different features using the same project and
modules.
● Reuse code and resources across sourcesets.
● By employing the flexibility of Gradle, you can achieve all of this without modifying
your app's core source files. Android Studio build files are named build gradle. They are
plain text files that use Groovy syntax to configure the build with elements provided by
the Android plugin for Gradle. Each project has one top-level build file for the entire
project and separate module-level build files for each module. When you import an
existing project, Android Studio automatically generates the necessary build files.

2.3.6 Multiple APK Support

Multiple APK support allows you to efficiently create multiple APKs based on screen density or
ABI. For example, you can create separate APKs of an app for the hdpi and mdpi screen
densities, while still considering them a single variant and allowing them to share test APK,
javac, dx, and ProGuard settings.

2.3.7 Debug and Profile Tools

Android Studio assists you in debugging and improving the performance of your code,
including inline debugging and performance analysis tools.

2.3.7.1 Inline debugging

Use inline debugging to enhance your code walk-throughs in the debugger view with
inline verification of references, expressions, and variable values. Inline debug information
includes:

● Inline variable values

● Referring objects that reference a selected object
● Method return values
 ● Lambda and operator expressions
● Tooltip values

2.3.8 PERFORMANCE MONITORS

Android Studio provides performance monitors so you can more easily track your app’s memory
and CPU usage, find deallocated objects, locate memory leaks, optimize graphics performance,
and analyze network requests. With your app running on a device or emulator, open the Android
Monitortool window, and then click the Monitors tab.

2.3.9 ALLOCATION TRACKER

Android Studio allows you to track memory allocation as it monitors memory use. Tracking
memory allocation allows you to monitor where objects are being allocated when you perform
certain actions. Knowing these allocations enables you to optimize your app’s performance and
memory use by adjusting the method calls related to those actions.

2.3.10 CODE INSPECTIONS

Whenever you compile your program, Android Studio automatically runs configured Lint and
other IDE inspections to help you easily identify and correct problems with the structural quality
of your code.

The Lint tool checks your Android project source files for potential bugs and optimization
improvements for correctness, security, performance, usability, accessibility, and
internationalization.
 CHAPTER 3

SDLC METHODOLOGIES

3.1 WATERFALL MODEL

Fig 3.1 : WATERFALL MODEL

The waterfall Model is a linear sequential flow. In which progress is seen as flowing
steadily downwards (like a waterfall) through the phases of software implementation. This
means that any phase in the development process begins only if the previous phase is complete.
The waterfall approach does not define the process to go back to the previous phase to handle
changes in requirements. The waterfall approach is the earliest approach that was used for
software development.
 CHAPTER 4

SYSTEM DESIGN

4.1 DATA FLOW DIAGRAM

A data flow diagram is a graphical tool used to describe and analyze movement of data through a
system. These are the central tool and the basis from which the other components are developed.
The transformation of data from input to output, through processing, may be described logically
and independently of physical components associated with the system. These are known as the
logical data flow diagrams. The physical data flow diagrams show the actual implements and
movement of data between people, departments and workstations. A full description of a system
actually consists of a set of data flow diagrams. Using two familiar notations Yourdon, Gane
and Sarson notation develops the data flow diagrams. Each component in a DFD is labeled with
a descriptive name. Process is further identified with a number that will be used for
identification purposes. The development of DFD’s is done at several levels. Each process in
lower level diagrams can be broken down into a more detailed DFD in the next level. The lop-
level diagram is often called a context diagram. It consists of a single process bit, which plays a
vital role in studying the current system. The process in the context level diagram is exploded
into another process at the first level DFD.

The idea behind the explosion of a process into more processes is that understanding at one level
of detail is exploded into greater detail at the next level. This is done until further explosion is
necessary and an adequate amount of detail is described for analysts to understand the process.

● Larry Constantine first developed the DFD as a way of expressing system requirements
in a graphical form, this led to the modular design.
● A DFD is also known as a “bubble Chart” and has the purpose of clarifying system
requirements and identifying major transformations that will become programs in system
design. So it is the starting point of the design to the lowest level of detail. A DFD
consists of a series of bubbles joined by data flows in the system.
4.1.1 DFD SYMBOLS:

● In the DFD, there are four symbols

● 1.A square defines a source(originator) or destination of system data
● 2.An arrow identifies data flow. It is the pipeline through which the information flows
● 3.A circle or a bubble represents a process that transforms incoming data flow into
outgoing data flows.
● 4.An open rectangle is a data store, data at rest or a temporary repository of data

Fig: DATABASE DETAIL

FIG 4.1.1
LEVEL 0 DFD

LEVEL 1 DFD

FIG 4.1.2
4.2 USE CASE DIAGRAM

Fig 4.2 : Use case diagram of user

4.3 SEQUENCE DIAGRAM

Fig 4.3 : Sequence diagram of user

4.4 VIEWING EXPENSES

Fig 4.4 VIEWING EXPANSES

 CHAPTER 5

TESTING AND EVOLUTION

As the project is on a big scale, we always need testing to make it successful. If each component
works properly in all respects and gives desired output for all kinds of inputs then the project is
said to be successful. So the conclusion is-to make the project successful, it needs to be tested.

The testing done here was System Testing checking whether the user requirements were satisfied.
The code for the new system has been written completely using JAVA as the coding language
and Android Studio as the interface for front-end designing as the interface for front-end
designing. The new system has been tested well with the help of the users and all the applications
have been verified from every nook and corner of the user.

Although some applications were found to be erroneous these applications have been corrected
before being implemented. The flow of the forms has been found to be very much in accordance
with the actual flow of data.
5.1 LEVELS OF TESTING

In order to uncover the errors present in different phases we have the concept of levels of testing.
The basic levels of testing are:

Client Needs Acceptance Testing

Requirements System Testing

Design Integration Testing

Code Unit Testing

A series of testing is done for the proposed system before the system
is ready for the user acceptance testing.

The steps involved in Testing are:

5.1.1 UNIT TESTING

Unit testing focuses verification efforts on the smallest unit of the software design, the module.
This is also known as “Module Testing”. The modules are tested separately. This testing was
carried out during the programming stage itself. In this testing each module is found to be
working satisfactorily as regards to the expected output from the module.

5.1.2 INTEGRATION TESTING

Data can be grossed across an interface; one module can have adverse efforts on another.
Integration testing is systematic testing for construction of the program structure while at the
same time conducting tests to uncover errors associated with the interface. The objective is to
take unit tested modules and build a program structure. All the modules are combined and tested
as a whole. Here correction is difficult because the isolation of cause is complicated by the vast
expense of the entire program. Thus in the integration testing stop, all the errors uncovered are
corrected for the text testing steps.

5.1.3 SYSTEM TESTING

System testing is the stage of implementation that is aimed at ensuring that the system works
accurately and efficiently for live operation commences. Testing is vital to the success of the
system. System testing makes a logical assumption that if all the parts of the system are correct,
then the goal will be successfully achieved.

5.1.4 VALIDATION TESTING

At the conclusion of integration testing software is completely assembled as a package,

interfacing errors have been uncovered and corrected and a final series of software tests begins,
validation test begins. Validation tests can be defined in many ways. But the simple definition is
that validation succeeds when the software functions in a manner that can be reasonably
expected by the customer. After the validation test has been conducted one of two possible
conditions exists.One is the function or performance characteristics that conform to
specifications and are accepted and the other is deviation from specification is uncovered and a
deficiency list is created. Proposed system under consideration has been tested by using
validation testing and found to be working satisfactorily.

5.1.5 OUTPUT TESTING

After performing validation testing, the next step is output testing of the proposed system since
no system could be useful if it does not produce the required output in the specified format.
Asking the users about the format required by them tests the outputs generated by the system
under consideration. Here the output format is considered in two ways, one is on the screen and
other is the printed format. The output format on the screen is found to be correct as the format
was designed in the system designed phase according to the user needs.

For the hard copy also the output comes as the specified requirements by the users. Hence output
testing does not result in any corrections in the system.

5.1.6 USER ACCEPTANCE TESTING

User acceptance of a system is the key factor of the success of any system. The system under
study is tested for user acceptance by constantly keeping in touch with the prospective system
users at the time of developing and making changes wherever required.

5.2 TEST CASES

5.2.1 USER LOGIN REGISTRATION:

To begin with login, users need to register by filling up basic registration details. There are
multiple fields in the registration page and every field has to be filled by the user. Users cannot
use characters in the login id field.

5.2.2 VALIDATION CRITERIA

● In each form, no field which is not null should be left blank.
● All numeric fields should be checked for non-numeric values. Similarly, text fields like
names should not contain any numeric characters.
● All primary keys should be automatically generated to prevent the user from entering any
existing key.
● Use of error handling for each Save, Edit, delete and other important operations.
● Whenever the user Tabs out or Enter from a text box, the data should be validated and if it
is invalid, focus should again be sent to the text box with proper message.
 CHAPTER 6

PROJECT SNAPSHOTS

Fig 6.1
Fig 6.2
 CHAPTER 7

LIMITATIONS

● It has a localised database as MySQL is used. In this we have to feed data manually.
● Sometimes filing data manually consumes more time.
● Once data is erased from the device it is difficult to track the record.
 CHAPTER 8

FUTURE SCOPE

● We are planning to shift our database to server that is with the help of firebase
● Further we are planning to add alerts if the expenditure becomes more than 70%
of the income
● Also taking the user credentials and information into concern we are planning to
add 2 layer of authentication by confirming the user with the help if email
verification
● Apart from keeping a personal log, we are planning to extend this system to
incorporate a shared expense group.
● Payment gateway: We are planning to include a service so as to make the direct
cash payment within the application itself.
● Representing the interface multilingual
 CONCLUSION

The system we envisioned comes to practice, providing a centralized log inculcating all daily
expenses. No or less manual calculations are required by the user, with efficient and user friendly
interface.

Followings are some future development plans:

● Group: Apart from keeping a personal log, we are planning to extend this system to
incorporate a shared expense group.
● Payment gateway: We are planning to include a service so as to make the direct cash
payment within the application itself.
● Representing the interface multilingual
 BIBLIOGRAPHY

► Websites

● http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controlle
r
● http://www.sparxsystems.com/platforms/software_development.html
● ftp://ftp.ecs.csus.edu/nguyendh/CSC%20230%20Projects/Expense%20Track
er.pdf
● https://www.slideshare.net/laxmikant27/expense-manager-application-in-
java