Building a Todolist Manager Assignment 1

Assignment 01: Building a Todolist Manager

1 Assignment Information

2 Introduction

NOTE: read the whole assignment brief first before implementing it contains very important information

In this assignment you will build a Todo list manager as a way of becoming familiar with the integration of multiple SDK elements together. It will also get you familiar with the general structure of Android applications and how they are put together.

In this application the user will be able to create multiple todo lists and manage them. Todo lists are composed of zero or more todo items that may or not have a due date attached to them. if there are due dates attached to items then the main display can then react to this and inform the user of pending items. It is expected that reasonable input validation and checks will be performed along the way.

NOTE: This is an individual assignment. It is not a group assignment. You can discuss ideas/algorithms but you cannot share code

NOTE: that you are also required to show me a working example of your brackets in labs. I will only consider marking those brackets that I’ve seen in labs. If you have only shown me the first four brackets in a lab I will not consider the rest.

3 Submission and Penalties

You are required to submit two separate components to the Moodle

• An archive containing your complete Android Studio Project. The accepted archive formats are: zip, rar, 7z, tar.gz, tar.bz2, tar.xz. The use of any other archive format will incur a 10% penalty before grading.
• A PDF containing documentation of your code. If you do not provide documentation your code will not be marked. Copying and pasting code into a PDF does not count as documentation.

There are also a few penalties you should be aware of

• Code that fails to compile will incur a 30% penalty before grading. At this stage you have zero excuse to produce non compiling code. I should be able to open your project and be able to compile and run without having to fix syntax errors.
• The use of libraries outside the SDK will incur a 20% penalty before grading. You have all you need in the standard SDK. I shouldn’t have to figure out how to install and use an external library to get your app to work
• An omission of a git repository attached to your email address that is registered for GCD will result in your application and documentation not being graded.
• The standard late penalties will also apply

You are also required to submit as part of your archive a working Git repository.

• When I unpack your archive there should be a .git directory as part of it.
• This should be a fully working git archive.
• You are not permitted to upload your work to Github, Gitlab, or any other publicly visible git repository (assignment will be marked as a zero if it is)
• If you need a remote git repository the only permitted one is the college provided Gitlab which can be found at gitlab.griffith.ie
• There must be a minimum of seven commits in the git repository, one per completed bracket.

Very Important: Take note of the grade brackets listed below. These are meant to be completed in order. If you skip a bracket or do not complete a bracket following brackets will not be considered for marking. You should be well capable of producing strong and generally robust software by now. For example if there are six brackets and you fail the third one, then the fourth, fifth, and sixth brackets will not be marked. Documentation brackets will be treated separately from Coding brackets.

You should also be aware that I will remove marks for the presence of bugs anywhere in the code and this will incur a deduction of between 1% and 15% depending on the severity. If you have enough of these bugs it is entirely possible that you may not score very many marks overall. I want robust bug free code that also validates all user input to make sure it is sensible in nature.

Also note that the percentage listed after the bracket is the maximum mark you can obtain if you complete that many brackets without error. Everything in all brackets is mandatory.

4 Plagiarism

Be aware that we take plagiarism very seriously here. Plagiarism is where you take someone else’s work and submit it as if it was your own work. There are many different ways plagiarism can happen. I will list a few here (this is not exhaustive):

• Finding something similar online (full implementation or tutorial) that does the same job and submit that.
• Finding something similar online (full implementation or tutorial) and transcribing (i.e. copying it out by hand)
• Working together on an individual assignment and sharing code together such that all implementation look the same.
• Getting a copy of someone else’s code and submitting/transcribing that
• Doing any of the above and attempting to conceal it by moving functionality around and renaming functions and variables.
• Paying someone to do your assignment

I’ve had to deal with many cases of plagiarism over the last six years so I can spot it and diagnose it easily, so don’t do it. To prevent plagiarism include but not limited to the following:

• Do all your code by yourself
• Don’t share your code with anyone, particularly if anyone looks for a copy of your code for reference.
• If you need to find information online only query about very specific problems you have don’t look for a full assignment or howto.

Be aware that if you submit your assignment you accept that you understand what plagiarism is and that your assignment is not plagiarised in any way.

5 Coding Brackets (70%)

1. Bracket 1 (10%)
• Create the basic shell of an application with a single main activity.
• Generate a SQLite database helper that will create a DB when the app is started first time or will reopen the DB on subsequent starts.
2. Bracket 2 (20%)
• Add in a mechanism that will trigger an activity for adding a new todolist to the main screen (bracket failure if two lists with the same name can be added).
• When a list is added it should be created and stored in the SQLite database (bracket failure if sqlite not used).
3. Bracket 3 (30%)
• Add in a mechanism for a todo list that will enable the addition of a todo item
• A seperate activity should be used to add in the todo item. a name is mandatory but an optional due date should be made available.
• Store the todo item in the SQLite database.
• Display the todo item in the list after addition, a todo item should have a checkbox next to it to indicate if it is complete or not (bracket failure if this checkbox state is not stored and restored).
4. Bracket 4 (40%)
• If a todo is marked as finished it should be shuffled to the bottom of the list.
• Provide a facility for editing a todolist’s name (bracket failure if a duplicate list name is accepted).
5. Bracket 5 (50%)
• Provide a facility for editing a todo item’s name and due date.
• Provide a facility for removing a todo item.
6. Bracket 6 (60%)
• When in a todo list there should be live counters showing how many items are in the list and how many are completed.
• Add a facility for moving a todo item from one list to another (bracket failure if an item can be moved into a list that already has an item of the same name).
7. Bracket 7 (70%)
• In the main view show the date of the nearest item due for each list.
• If an item is due today highlight the list yellow.
• If an item’s due date is past then highlight the list red.

6 Documentation Brackets (30%)

NOTE: Documentation should be around 2,000 words in length total

8. Bracket 8 (0 to 10%)

Document every method in your code from a highlevel perspective. i.e. give an overview of what the method does. Do not copy and paste code you will be penalised for this.

9. Bracket 9 (10 to 20%)

Document every datastructure and database designyou have used in your code and why you chose them. You do not need to provide an E-R diagram for database designs.

10. Bracket 10 (20% to 30%)

Detail any design decisions you made that youconsider to have improved the ease of use of your UI or you consider innovative. If you have made custom views detail their design and mathematics here