p4-budget

EECS 285 Project 4: Budget Tracker

First App Due Wednesday, 17 Nov 2021, 8pm

Project Due Friday, 10 Dec 2021, 8pm

In this project, you will build an Android application for keeping track of a budget. The application will allow a user to add individual transactions, specifying each transaction’s category. It will then display the total money spent on each category and overall, as will as allow the user to list the individual transactions.

The purpose of this project is to gain basic experience in Android development. You will have full freedom to design your code and layouts, as long as you adhere to the minimum specifications described here.

This project is divided into two parts, both of which need to be turned in on their respective due dates:

The setup tutorial, including the Android first app. Follow the instructions in the tutorial for completing and submitting the first app.
The full project described here.

Authors

The project was written by Amir Kamil for EECS 285. The concept was inspired by the Swing budget-tracker project by Andrew M. Morgan.

Project Roadmap
Required Behavior
Sample Video and Screenshots
Helpful Resources

Project Roadmap

This is a big-picture view of what you’ll need to do to complete this project. Most of the pieces listed here also have a corresponding section later on in the spec that goes into more detail.

This project will be graded by hand for correctness, and the correctness portion is worth 100% of your project grade. We will not grade your programming practices on this project. However, you should still adhere to good practices when writing your code.

The first app is worth 10% of your project grade, while the full project described here is worth 90%.

We recommend you work with a partner for this project. Please see the syllabus for partnership rules. Since the first app is submitted separately, you do not have to work in the same partnership for the first app as for the full project.

Set up your project

Follow the setup tutorial to set up your project.

Your Java files should all be in a package with the structure eecs285.proj4.<uniqname>budgettracker, where <uniqname> is your uniqname. If you are working in a partnership, then use both of your uniqnames, in alphabetical order, separated by an underscore. For example, if I am working alone, I would put the following package directive at the top of each .java file:

package eecs285.proj4.akamilbudgettracker;

If I am working with schatzju, then I would use the following:

package eecs285.proj4.akamil_schatzjubudgettracker;

Familiarize yourself with the requirements below

Read through the rest of the specification to determine the required behavior that your app must support.

Design, implement, and test your sources

Start by designing the structure of your app, determining what activities it will have and how they will connect to each other. Then design the internal code structure and layouts before proceeding to implement them. Finally, test your code thoroughly on the target device.

Submit

Submit the following files to the autograder.

src.zip, an archive of the sources for your project (the app/src directory for an Android Studio project)
build.gradle from the app directory of your project (NOT the build.gradle that is one level up from the app directory)

Refer to the guide on preparing files for submission for how to obtain the required files.

As per course policy, we will grade your last submission to the autograder. It is your responsibility to ensure that your last submission is complete.

Early Submission Bonus

If your final submission for the full project occurs at least two days before the due date (at or before 11:59pm two days before the due date), you will receive bonus points calculated at 5% of your overall score for the project (including both the setup and full project). In other words, if your overall score is N, it will be 1.05 * N after the bonus is applied.

If your final submission occurs on the day before the due date (by 11:59pm), you will receive bonus points calculated at 2.5% of your overall score for the project. In other words, if your overall score is N, it will be 1.025 * N after the bonus is applied.

Required Behavior

As mentioned above, the purpose of the Android app is to keep track of a budget. The app keeps track of individual transactions, while also associating them with categories (e.g. food, utilities, entertainment, etc.). Categories should not be hard-coded – instead, the user should be able to specify what categories they care about. The app has the ability to display the total monetary value for individual categories as well as the overall total. The app also enables the user to see a list of all transactions and to clear the transaction data.

You may develop your app on either a phone or a tablet. However, we will only test your app on a phone. We recommend testing your app on a phone emulator to make sure the interface works properly. We will only test your app in portrait mode.

We will test your app on Android Oreo 8.1. You must use a target API of 27 or lower. We recommend API 24, which gives you more support for Java 8 features and libraries than earlier API levels.

You must submit your application sources to the autograder. Refer to the Submit section for instructions on how to submit the required files. Your app must compile correctly on the autograder for us to be able to grade it.

The next two sections detail the required structure and behavior of your app. Aside from the base, required functionality, you have full freedom to design the look and feel of your app, as well as to add any extra features you want. However, we will only grade the required elements below.

App Name

Your app must include your uniqname(s) in the application name. Use a format similar to the package structure. For example, if I am working alone, the following would be my app name:

If I am working with schatzju, then it would be:

You can specify the application name when you create an Android project. If you have already created your project, you can edit the name in res/values/strings.xml:

    <string name="app_name">akamil_schatzju Budget Tracker</string>

List of Requirements

You must have at least two activities, with proper “Up” navigation between the child and parent activities.
You must have an activity that displays the total for each category, as well as the overall total. The categories must be sorted in alphabetical order. This must be your app’s initial activity.
You must have an activity that displays every transaction, sorted by the order in which the transactions were added. Display more recent transactions first. At a minimum, each transaction should display its name, category, and cost.
Your app must have at least one dialog.
Any lists that you have must be scrollable. We recommend using either a ListView or a RecyclerView, with a custom ArrayAdapter for representing the list elements.
You must have a way of adding transactions and categories. It is up to you whether to separate the task of adding a new category from that of a transaction, or combine them as in the instructor solution.

When adding a transaction, you must require that the user provide a category, a transaction name, and a cost. The cost can be entered either as a whole dollar amount or as dollars and cents. Your app must use a numeric keyboard for entering the cost.

Your app should prohibit invalid entries (e.g. empty name or category, a cost of zero, a cost that isn’t a valid dollar and cent amount).
You must have a way of removing transactions. This can either be individually or all transactions at once.

When removing transactions, your app must ask for confirmation before proceeding to remove any data.
The transaction data your app stores must be persistent. This means that if the app is closed and restarted, all the data must still be there. We recommend using binary I/O (i.e. serialization) to store files on internal storage.
Money values must be displayed as dollars and cents with a decimal point in between, and the cents portion must be exactly two digits. We recommend storing money values in cents, using an integral type (e.g. long), so that you don’t have to worry about rounding issues. Then simply divide by 100 to get the dollar value and mod by 100 to get the cent value. You can use formatted output to ensure that cents are always printed out as two digits.
Your app’s user interface must be intuitive and self-explanatory. We will not read through documentation to figure out how to use your app.

Optional Features

Autocompletion for categories, as in the instructor solution, is optional.
Showing the date and time of a transaction, as in the instructor solution, is optional. If you to decide to add this, you may either use the current date and time at the instant the transaction is added or require the user to specify them manually. In the latter case, you may chose to sort transactions by order of entry or by date and time.
You may add any additional features you like. Examples include an activity to display a single category’s transactions, the ability to delete individual transactions or categories, enabling a transaction to be repeated, allowing a user to manually sort categories, the option to show transactions by day or month, and so on. We encourage you to make your app as full-featured as you want.
You do not have to use AsyncTasks – your app is permitted to do all the work in event handlers.
You may use any color palette you like for your app.

Clarifications

Multiple categories may not have the same name.
Multiple transactions may have the same name, whether or not they share the same category.
You do not have to worry about overly long category or transaction names. We will only test with data similar to what’s in the sample video and screenshots.
You do not have to worry about capitalization of category or transaction names. We will always capitalize the first letter when we test.

Sample Video and Screenshots

The following is a sample video of the instructor solution. Your design does not have to match ours, but it must support the same basic functionality, as described above.

The following are screenshots from the instructor solution:

Initial app startup:
Tapping on “ADD” results in a dialog to add a transaction:
Attempting to add an invalid transaction results in error text being displayed:
The standard keyboard is used to enter in the category and name:
The numeric keyboard is used to enter in the cost:
The result of adding a transaction with a new category:
Example of adding another transaction to the “Food” category:
This results in the total for the food category to be $18.20 from the two transactions:
A transaction price can just be a dollar amount, with no cents:
Adding more transactions with other categories adds those categories to the summary view. The categories are displayed with their individual totals, and they are sorted by alphabetical order. The total across all categories is at the bottom:
Tapping on “TRANSACTIONS” results in a view of every transaction, with most recent shown at the top. The category and date/time are shown above each transaction in small, colored text:
Returning to the previous activity and tapping “CLEAR DATA” results in a confirmation dialog: