-
Notifications
You must be signed in to change notification settings - Fork 2
Home
The home to our Habit Tracker app (name pending), in development for CMPUT 301's team project.
- Eric (ebrisson) [ericrbrisson]
- Mathew (lisowski) [Mathew-Lisowski]
- Jesse (jgrywach) [jegrywacheski]
- Moe (numasawa) [moenuma]
- Leah (lren) [grapse]
- Arthur (aiuwalak) [arthuruwalaka]
-team.txt file is linked here, with each team member's CCID and GitHub username, also stated above.
- The Backlog deliverable has been split into two sections:
- User Stories, along with their risk level and story points, can be found under the Projects panel, under User Stories here. It is currently sorted by Haven't Started, In Progress, and Completed categories.
- Our team backlog, with actionable development tasks, currently sorted per Java class, can be found under the Projects panel, under Backlog here. Each card contains references to relevant user stories pertinent to that functionality. This project board's cards may eventually be converted into GitHub Issues for more organized tracking, and it makes more sense to have the items on this project board converted into Issues rather than the User Stories themselves.
- CRC cards can be found here.
- Application UI Mockups and Storyboard Sequences can be found on the Wiki, here.
Changes made based on Project Part 2 feedback:
- Product backlog: a few user story cards had story points that didn't correspond to the risk level. The User Stories were updated to meet the new requirements as discussed in class, as well as the following changes to risk level:
- 1.5.1 risk level low -> medium
- 2.6.1 risk level low -> medium
- 3.1.1 risk level medium -> low
- 5.2.1 risk level low -> medium
- All cards on the User Stories Project page have been converted into GitHub Issues, for easy tracking of progress, along side commentary throughout the solution.
- CRC Cards: Interaction with HabitEvents was noted, and new cards to reflect changed internal design have been made.
And as for the deliverables for Project Part 3:
-
Addressing Feedback Please see changes made above this section pertinent to what was asked from TA feedback.
-
Code Base of Prototype Our Android Studio project code base is in the root of our repository. As per our User Stories project board, our goals for the halfway point have essentially been met, with roughly half of the user stories completed, with others having partial work done towards them. All functionality as required is there for a "done" user story -- but overall look and feel of application will be tailored as we go long to further match our storyboards.
-
Code Documentation All code files are commented where necessary, each with a header containing a description of the file, but additionally a changelog to see which team member made what change and when to a particular file. Javadoc interface documentation has been provided for our model classes and their public methods as required.
-
Test Cases
- Intent testing: comprehensive Intent testing has been created using Robotium upon all of our control classes to test a wide array of edge cases in development, and has proven very useful when making big changes to the project being able to rerun all of the Intent testing making sure nothing has broken in the process. Each control class has an accompanying Intent test class. For example, our LogIn class now has an accompanying LogInTest class, which tests many aspects of logging in: entering a correct username and a correct password, entering a correct username and incorrect password, entering an incorrect username with any password, leaving the username field empty but something in the password field, vice versa, as well as leaving both fields empty, and attempting a log in.
- Unit testing: we have fleshed out our model classes as much as necessary to allow for unit testing. Due to Firestore limitations, we are not able to test the functionality of Firestore through unit testing, despite the methods for our Firestore database interaction belonging to a model class. Therefore, we have intrinsically tied the fields and the views of our app to work with Firestore, so that it can be tested through Intent testing. For example, if a user adds a new habit, it should populate in the All Habits frame -- and the ListView on the All Habits frame will only populate from the Firestore database -- meaning if a habit was successfully added, it will appear in the All Habits ListView.
-
Object-oriented Design Our UML class diagram can be found on our wiki, under UML Class Diagram.
-
Project Backlog Both our project boards for User Stories and Backlogs have been consistently updated as we progress. User story completion is being tracked in the User Stories progress board, alongside relevant pull requests being linked, and any other kind of work that needed to be done for the project unrelated to a specific user story will have either been documented in a pull request of its own, or in the project board Backlogs (like setting up the navigation bar, for example).
-
UI Mockups and Storyboard Sequences Our UI Mockups and Storyboard Sequences are always updated as needed and can be found on our wiki, under UI Mockups and Storyboard Sequences.
-
Sprint Planning and Reviews On top of our weekly meetings on Wednesdays with our mentor TA, our team also hosted sprint meetings each Sunday over Discord voice chat to discuss. These team meeting notes can be found in the Wiki, under Weekly Sprint Planning. Please refer to this in addition to our Project Board for specific assignments of tasks over the course of each week.
User stories to be tackled by each group member is documented as shown on our project board User Stories. Additionally, we maintained communication nearly daily throughout our Discord server text chat. Should further documentation be required, we can share our Discord communication. Our practice typically involves work done by a pair or an individual, and then when their functionality is ready to be merged with the main code base, another team member will come in to resolve any merge conflicts and merge the pull request, so the team is looped in at all times (this is documented as per our pull request history). In this way, whatever code-base on main is always the most recent functioning version of our app, so steady progress can be easily and effectively tracked. As also shown in commit and pull request history, riskier requirements were done earlier. For example, Firestore related functionality and navigation bar functionality was set up much earlier in the project development, as to assure access to the database and core frame navigation to each team member when working on their own tasks. Additionally, continuous integration was setup through GitHub Actions to help with testing.
-
Demonstration To be done after reading week. Will demo the app to our mentor TA with our current progress.
-
Tool Use GitHub was comprehensively used for the creation of this project, with the use of GitHub Projects, GitHub Actions for our continuous integration, GitHub wiki for our bookkeeping, and much more.
Changes made based on Project Part 3 feedback:
- Renamed some ambiguous classes for better clarity, ie. Main.class -> MainActivity.class
- Color coded UML diagram to further clarify some ambiguities between Entity classes, GUI classes, etc.
And as for the deliverables for Project Part 3:
- Addressing Feedback
Please see changes made above this section pertinent to what was asked from TA feedback.
- Code Base of Prototype
Our Android Studio project code base is in the root of our repository. As per our User Stories project board, our goals for completion have been met! All user stories are completed and have functionality present within the app.
- Code Documentation
All code files are commented where necessary, each with a header containing a description of the file, but additionally a changelog to see which team member made what change and when to a particular file. Javadoc interface documentation has been provided for our model classes and their public methods as required. Since some changes were made in this project part to some model classes, Javadoc documentation has been updated accordingly.
-
Test Cases
- Intent testing: comprehensive Intent testing has been created using Robotium upon all of our control classes to test a wide array of edge cases in development, and has proven very useful when making big changes to the project being able to rerun all of the Intent testing making sure nothing has broken in the process. Each control class has an accompanying Intent test class. For example, our LogIn class now has an accompanying LogInTest class, which tests many aspects of logging in: entering a correct username and a correct password, entering a correct username and incorrect password, entering an incorrect username with any password, leaving the username field empty but something in the password field, vice versa, as well as leaving both fields empty, and attempting a log in. For this project part, more Intent testing was created, particularly for Profile, Feed, and Location functionality. Due to Robotium limitations, the camera functionality cannot be tested.
- Unit testing: we have fleshed out our model classes as much as necessary to allow for unit testing. Due to Firestore limitations, we are not able to test the functionality of Firestore through unit testing, despite the methods for our Firestore database interaction belonging to a model class. Therefore, we have intrinsically tied the fields and the views of our app to work with Firestore, so that it can be tested through Intent testing. For example, if a user adds a new habit, it should populate in the All Habits frame -- and the ListView on the All Habits frame will only populate from the Firestore database -- meaning if a habit was successfully added, it will appear in the All Habits ListView. Throughout the development of our project, we have found more use for model class methods and have written additional unit tests accordingly, as much as possible.
-
Object-oriented Design
Our updated UML class diagram can be found on our wiki, under UML Class Diagram.
- Project Backlog
Both our project boards for User Stories and Backlogs have been consistently updated as we progress. User story completion is being tracked in the User Stories progress board, alongside relevant pull requests being linked, and any other kind of work that needed to be done for the project unrelated to a specific user story will have either been documented in a pull request of its own, or in the project board Backlogs (like setting up the navigation bar, for example). More documentation was done in the User Stories board, as the Backlog board was for more misc. items.
-
UI Mockups and Storyboard Sequences Our updated UI Mockups and Storyboard Sequences are always updated as needed and can be found on our wiki, under UI Mockups and Storyboard Sequences.
-
Sprint Planning and Reviews
On top of our weekly meetings on Wednesdays with our mentor TA, our team also hosted sprint meetings each Sunday over Discord voice chat to discuss. These team meeting notes can be found in the Wiki, under Weekly Sprint Planning. Please refer to this in addition to our Project Board for specific assignments of tasks over the course of each week. User stories to be tackled by each group member is documented as shown on our project board User Stories. Additionally, we maintained communication nearly daily throughout our Discord server text chat. Should further documentation be required, we can share our Discord communication. Our practice typically involves work done by a pair or an individual, and then when their functionality is ready to be merged with the main code base, another team member will come in to resolve any merge conflicts and merge the pull request, so the team is looped in at all times (this is documented as per our pull request history). In this way, whatever code-base on main is always the most recent functioning version of our app, so steady progress can be easily and effectively tracked. As also shown in commit and pull request history, riskier requirements were done earlier. For example, Firestore related functionality and navigation bar functionality was set up much earlier in the project development, as to assure access to the database and core frame navigation to each team member when working on their own tasks. Additionally, continuous integration was setup through GitHub Actions to help with testing.
- Demonstration
To be done this week. Will demo the app to our lab, with each of our team members!
- Tool Use
GitHub was comprehensively used for the creation of this project, with the use of GitHub Projects, GitHub Actions for our continuous integration, GitHub wiki for our bookkeeping, and much more.
- Known Issues
We were having last-minute troubles with our backend implementation of Notifications and Pending Requests, since they provide two ways to follow other users, and don't communicate updates in pending following requests properly. For the Part 4 submission, we have hidden notifications from the UI but the functionality is still baked in underneath. Perhaps in a later commit we will try to tidy it up, but thankfully it's not required for the end of the project -- users can still add one another through the Profile frame.