Hello everyone ! Welcome to our third blog article. We are nearing the end of our journey on providing an application that will help all of you in maintaining your budget. In this article we have explained about the design patterns we could have followed, people who could most benefit with this application, design solutions and few changes from our previous blog. We have also finally given our application a name and logo. Revealing !
Design Pattern
Design Patterns are the best reusable solutions to many of the repeating problems that arises during software development. It is the best practice followed by many experience developers to create a blueprint of the entire system, class structure and inheritance, object creation and relationship. We being new code warriors, were just introduced with these patterns. While we learnt about these, our design could adapt the design patterns mentioned in the following way.
Three structural patterns could be incorporated into our design if each transaction is created as an object from a class.
1. Facade design pattern - User has been given the option to add a new category. Using a facade class to hide the the implementation of all the other fields and the category behaviour, by just having a separate class for category and exposing the particular class alone for the user to manipulate by creating an object everytime an user adds a new category. Mainly to hide the complex implementation and provide a simple interface for user.
2. Bridge design pattern - Bridge design pattern for the new transaction class to use the category interface and inturn use the expense/income category objects based on whether the user selects income/expense. Income and expense are seperate classes inherited from the new transaction class. The reason is to seperate the abstraction of the category from the implementation of the transaction class so that it could be used in the above case too.
3. Decorator design pattern - Decorator design pattern to add recurrence only when the user selects such. Otherwise only the core fields needed for an transaction would be part of the transaction object. This is dynamically add the extra field whenever needed.
Coding Conventions
Implementation of functionality(Language) : Java Coding guide followed partially : Google Java Style Guide
1. Source File Name
The name of the source file is a unique, case-sensitive file name with .jave extension.
2. Source File Structure
The structure of the source file is as below,
2.a. Class content structure
Functionalities are coded in the same order as they are executed in the each screen. The methods and public defined variables are also coded in the order in which they are called.
3. Formatting
i) Braces: Braces are used for blocks as well as conditional statements. Even if the conditional statements have only one line, the braces are used.
ii) Indentation for blocks: Blocks are indented with 2 spaces. When one block ends, the next statement follows the previous indentation.
iii) One statement per line: Maximum of just one statement per line. And each statement if coded only after a line break.
4. Variable declarations
i.) One variable per declaration: One variable declaration declares only one variable
ii.) Declaration when needed: Local variables are declared close to the point they are first used and are typically initialized immediately after declaration.
5. Annotations
Annotations are used for a class or method like @Override for methods.
6. Naming Conventions
i) Pacakge : Package names are written in lower case
ii.)Class : UpperCamelCase- Starts with a capital letter and later follows camel case.
iii) Java Activity File names : UpperCamelCase- NameActivity/NameFragment (Example : AddExpenseFragment)
iv) Java Layout File names : lowercasse- fragment_name (Example : fragment_addexpense)
v) Methods: lowerCamelCase- Starts with a lower case letter and then follows camel case.
vi) Variables: Starts with a lower case letter and then follows camel case (Only lowercase is used when there is a need for same variable name)
7. Comments
All sections have comments that are code within /../ (Block comments)
Enforcement
We have enforced the coding conventions by peer reviewing every part of code once the developer finishes. We look into the above rules and would add comments on the at the end of the program on the conventions not followed. The developer would check the code again once notified and make the necessary changes.
Context of Use
The context of use describes the target user groups of our application. For this, user personas are created which includes the goals and frustrations, demoghraphic details and so on. Illustrated below are two user personas indicating two target user groups.
Design Solution
When we planned the design we wanted the most user friendly interface. We designed the interface considering two things.
- Familiar and Intuitive inerface
- Simple and Quick interface
We used the following items efficiently to attain our goal.
1. Navigation bar : Most of the applications available has a navigation bar and users have been familiar with this. This could be used to launch any functionality from anywhere in the application. Less back clicks and also user will have an idea of all the functions available when they just draw the navigation bar.
2. Tabs and swipe : As seen in the screenshots below tabs that can easily be swiped are used between expense and income. This gives the user easier way to switch between expense and income. Also make both the transactions look similar for the user though the implementation is different.
3. Fragments : The application is completely designed with one main activity and rest fragments as the transfer of data between fragments is a lot quicker than between transactions.
The screenshot below covers the epic and user stories related to adding a new transaction. A brief overview of each step is given below each image.
The screenshot below covers the epic and user stories related to seeing history of transactions in both summary tab and history tab. Also given a screenshot where the transaction could be updated/deleted. A brief overview of each step is given below each image.
Summary Of Changes
The following are the overview of the changes compared to basic prototype,
1. Look of the application(Cosmetic changes) Before : The application had monochromatic colour Now : Two colours (One colour for secondary background and another color for secondary text and buttons)
2. Summary page Before - Only total income, expense and balance values
Now - a) All Current month income and expense transactions b) Current month expense visualisation
3. History of transactions Before - No filters
Now - a) Filters based on Category, Date and Filter options b) Also format of the transactiosn displayed changed
4. Visulisation tab : Before - No filter Now -Filters based on Category, Date and Filter options
5. Login : Before - No login After - Login with Pin has been added and made optional
6. Setting page : Before - No setting were added Now - a) An option to add new category for expense and income b) An option to make login optional and another to set PIN
User stories : New must requirement that we had to add to the user story was to include category filter in addition to the date filter while seeing history of transactions.
Class diagram : Authorization activity is the main addition to the basic protoype, as there was no option to set login before. Setting up the login was the main change to the class diagram as the new activty “authorization” is the default activity and it depends on the main activity.
Working Prototype
Download link
Try our advance prototype by downloading the apk file by clicking this link
Screenshots
Many screenshots of the application are already posted above in the design solution section. Image 1 : Login screen of the application Image 2 : Settings tab - New category can be added and Login setting can be changed Image 3 : Visualisation tab - Filter are provided
