D6.md

D6 Implementation 2

Introduction

Our system works as a phone interface that for a user interacts with. They will begin by creating their account using a username input, this communicates with our Spring BOOT server application to create a user ID that's associated with their account. This ID is used by the client side application to lookup their data and make adjustments to their color set data that is loaded back in on app start up. Maintaining a users information is key to functionality between launches. A user creates their activities and is populated with data from the server. The server delivers the information through http requests, the data is processed and the color the user has assigned to their complete and incomplete values populates within the visible calendar. Updates are then set back to the server to update values to be consistent with input. The server side also writes usernames/ID to one CSV, and the data associated with days and the users associated with those days to another file when the server side is taken down to update to a new version. After the new one is loaded it reads in the CSV files to the user and dayData database list arrays to be manipulated by the client application.

Project Calandar Project is a free calendar app that helps users track habits and routines on a daily basis. Individuals can track their workout routines, eating habits, smoking habits, and other habits in a visual way which provides the individual with instant feedback. This gives the user gratification and motivation to continue keeping up with their habits. Our product is unique in that the user of the calandar app can extensively customize the colors of the app’s user interface and receive reminders about user habits. While we've held as true to this as we can, features are a work in progress and are planned for future implementations.

Links:
/~https://github.com/TJohnsonAZ/Calandar-Project
https://trello.com/b/DBgag9Ex/project-calandar-project-board-calandar-board

Implemented Requirements

1. As a user, I want there to be separate colors for each of my activities on my calendar, so that I can tell them apart.

   • Completed by Zach, Calvin
   • Reviewed by Zach
   • 

2. As a user, I should be able to have my own distinct calendar

   • Completed by Kadan, Adam, Calvin
   • Reviewed by Adam
   • 

3. As a user, I should be able to see multiple events on a single calendar

   • Completed by Adam, Kadan
   • Reviewed by Zach
   • 

4. Allow the user to scroll through all 12 months and mark each one

   • Completed by Calvin
   • Reviewed by Kadan

5. Color Picker for changing activity completion and noncompletion color

   • Completed by Zach
   • Reviewed by Calvin
   • 

6. As a user, I want to be rewarded for reaching my goals so that I can feel accomplished.

   • Completed by Trevor, Zach, Calvin
   • Reviewed by Adam

7. Support up to four separate users of the app

   • Completed by Kadan, Adam
   • Reviewed by Adam
   • 

8. As a user, I want to be able to see how many [units of time] in a row I’ve completed a certain event to see how much progress I’ve made.

   • Completed by Trevor
   • Reviewed by Adam

9. Synchronous calendar loading

   • Completed by Calvin
   • Reviewed by Kadan

Demo

• https://youtu.be/3Os71leqLtI

Code Quality

• Javadocs on all of our methods to facilitate understanding
• One true brace method for all code
• No one letter variables (excluding i for indexing)
• Meaningful method/variable/class names
• Each object had one purpose and we ensured that each part did its part well
• Looked for ways to reduce coupling within code
• Frequent meetings to discuss implementation
• Constant questioning to ensure high quality outcomes

Lessons Learned

Front-end:
- If development continued we would create a way for the user to create their own username or implement a way for a username to be auto generated when a new user opens the app.
- We would want to give the user a little more customization features, being able to customizes anything on the app, so it starts to feel more unique for each different users.
- We would want to implement some type of note feature, so the user can write notes for specific days and store these notes on their device in order to access them for later.
- We struggle with making sure that we were waiting for a response from the server before we populate the calendar with the correct days that were marked by the user and making sure that the calendar was reflecting the put request made when a user marks a day. We fixed this with blocking and doing an asynchronous http request. - We had another issue where we were making a volley and future.get http request from the server to get the summary information and we found some kind of bug where we could not use future like before to make an asynchronous request from the server to get JSON object that was populated with an integer Array. We fixed this issue by making a synchronous get request from the server without using the future/volley class.

Back-end:
- If development continued we would update our databases, as Spring has its own implementation, and SQL is an option, but due to our inexperience, we developed a simple csv database.
- We would change the users to be more secure, possibly with a password
- A bigger struggle than expected was the jump to multi-user support. Our code for first release did not work as expected, and so our multi-user code did not work when implemented. So we debugged the previous methods. Our solution involved the user objects working with the data for each of the days.
- Another issue was determining what would be included in the summary class. To figure this out, we looked at the summary type objects in other systems, and built our based off of that. So we included the days in a row an activity was completed, as well as the amount of activities, etc.
- Some issues involve the inefficiency of our database. Currently, it is simply a large csv with all of the data stored in it, which is O(n) complexity, and is thus very slow as the number of users increases. This is something that would be fixed in future implementations.