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.
The project was written by Amir Kamil for EECS 285. The concept was inspired by the Swing budget-tracker project by Andrew M. Morgan.
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.
Follow the setup tutorial to set up your project.
Your Java files should all be in a package with the structure
<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
If I am working with
schatzju, then I would use the following:
If you specify the appropriate application name when creating your project in Android Studio, it will automatically fill in the correct package name.
Read through the rest of the specification to determine the required behavior that your app must support.
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 the following files to the autograder.
src.zip, an archive of the sources for your project (the
app/srcdirectory for an Android Studio project)
app-debug.apk, the compiled target for your project
tablet.txt, depending on if you designed your UI for a phone or a tablet
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.
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 design your app’s interface for either a phone or a tablet.
You may also support both if you like. However, we will only test your
app on one or the other. Submit a file called
phone.txt if you want
us to test on a phone, and a file
tablet.txt if you want us to test
on a tablet. We will test your app in portrait mode whether you
choose to develop for a phone or a tablet.
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.
tablet.txt, you must submit both your
application sources (including both Java sources and the app’s XML and
other resources) and a compiled Android application package (APK).
Refer to the Submit section for instructions on how to
submit the required files.
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.
Your app must include your uniqname(s) in the application name. Use
the same format as in 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
res/values/strings.xml. You will need to escape the
apostrophe when you define your app name in
<string name="app_name">akamil_schatzju\'s Budget Tracker</string>
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.
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.
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.
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
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
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.
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.
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.
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
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:
The following are a few resources you may find helpful in implementing your app.