Skip to content
This repository has been archived by the owner on Apr 14, 2023. It is now read-only.

Home

Jump to bottom
richeek05 edited this page Nov 28, 2022 · 18 revisions

Welcome to the FoodBit wiki!

The homepage to our Foodbit app.

Team Members

CCID [Github Username]

  1. haobin4 [hobielee42]
  2. asahmed2 [a-s-ahmed]
  3. gjzhu [ggracez]
  4. hrjackso [hr-jackson]
  5. fanbang [Bon-Y]
  6. richeek [richeek05]

Project Part 1

Project Part 2

Project Part 3

  • Changes made based on Project Part 2 Feedback:

    CRC Card for Database Controller made and updated.

  • Deliverables for Project Part 3

Please be sure to check your run configurations and ensure the Activity is set to Default, not Select Activity

  1. Addressing Feedback:

    Please see changes made above this section pertinent to what was asked from TA feedback. Particularly the use of a database controller

  2. Code Base of Prototype:

    Our Project's code base is in the root of our repository(FoodBit). As per our User Stories project board, We have mostly achieved our goals for the midway point, with some partial work being done for the remaining User Stories. For a "done" user narrative, all necessary functionality is present; however, the overall appearance and feel of the application will be customized as we go forward to better match our storyboards.

  3. Code Documentation:

    Every code file has comments where necessary. Comments are made within the code so that the Javadoc interface documentation can be created by the TA as required.

  4. Test Cases:

    Unit Testing: >To enable unit testing, we have fully developed our model classes. Despite the fact that the methods for our Firestore database interaction belong to a model class, Firestore's restrictions prevent us from unit testing Firestore's functionality. As a result, our app's fields and views are integrally linked to Firestore's functionality so that Intent testing can be used to test it.

    Intent Testing: >All of our control classes have undergone thorough Intent testing to test a wide range of edge cases during development. This has proven to be very helpful when making significant changes to the project because it allows you to rerun all of the Intent testing to ensure that nothing has been broken. There is a corresponding Intent test class for each control class. For instance there is a RecipeTests() method in the class which calls another 3 testing methods which test adding a recipe, viewing it's detail, and deleting it respectively. This ensures all of 3 tests are run together everytime we run a UI test, to ensure consistency

  5. Object Oriented Design:

    The UML Class Diagrams are updated on the Wiki Page: https://github.com/CMPUT301F22T01/FoodBit/wiki/UML-Class-Diagram

  6. Product Backlog:

    Our Project Boards for User Stories and Backlogs have been updated consistently as we made progress. User story completion is being tracked in the User Stories Progress Board, along with relevant pull requests being linked. Any additional work that needed to be done for the project that was unrelated to a specific user story will have either been documented in a separate pull request or in the project board Backlogs.

  7. User Interface Mockups and Storyboard Sequences:

    Our UI Mockups and Storyboard Sequences are always updated as needed and can be found on our wiki, under Storyboard: https://github.com/CMPUT301F22T01/FoodBit/wiki/Storyboard

  8. Sprint Planning and Reviews:

    Apart from our weekly meetings during the lab session with our TA, we coordinated over Discord to discuss and assign tasks, and track our progress.

    User Stories to be completed were tracked on our Project Board User Stories. We maintained communication and coordinated almost daily over Discord. Tasks were assigned individually and pairwise, our practice involved working in our respective branch and then merging to main branch when the required functionality is achieved. Often 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, even when someone was facing any issues we discussed over Discord or during our meetings to resolve that at the earliest. 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, we tried to complete riskier requirements earlier.

  9. Demonstration:

    To be done after reading week.

    App Demo will be done in presence of the TA, with the current progress.

  10. Tool Use:

    This project was created using GitHub in its entirety, including GitHub Projects, GitHub Actions for our continuous integration, GitHub Wiki for our bookkeeping, and much more.

Project Part 4

  • Changes made based on Project Part 3 feedback:

    Product Backlog: Issued titles to contain some information about the User Stories, for better navigation.

    Test Cases: MealPlanTest fixed and added comments where necessary to make it easier to understand. Names of some of the tests have been changed and the tests have been made shorter

    OO Design: UML made consistent with the database

  • Deliverables for Project Part 4:

The User Interface Mockups and Storyboard Sequences can be found here: https://github.com/CMPUT301F22T01/FoodBit/wiki/Storyboard

The CRC cards following the Object-Oriented Analysis can be found here: https://github.com/CMPUT301F22T01/FoodBit/wiki/CRC-Cards

  1. Addressing Feedback:

    Please see changes made above this section pertinent to what was asked from TA feedback. Particularly the Product Backlog, Testing, and UML.

  2. Code Base of Prototype:

    Our Project's code base is in the root of our repository(FoodBit). According to our User Stories project board (Backlog), We have achieved our goals for the final submission. All user stories are completed and have functionality present within the app.

  3. Code Documentation:

    Every code file has comments where necessary. Comments are made within the code so that the Javadoc interface documentation can be created by the TA as required. Since some changes were made in this project part to some model classes, Javadoc documentation has been updated accordingly.

  4. Test Cases:

    Unit Testing: >To enable unit testing, we have fully developed our model classes. Despite the fact that the methods for our Firestore database interaction belong to a model class, Firestore's restrictions prevent us from unit testing Firestore's functionality. As a result, our app's fields and views are integrally linked to Firestore's functionality so that Intent testing can be used to test it.

    Intent Testing:(Please Test on Pixel 6 Pro) >All of our control classes have undergone thorough Intent testing to test a wide range of edge cases during development with some exceptions. Unfortunately, due to the nature of Android Espresso tests, the instrumented test gets stuck when auto complete text fields are present in a dialog fragment (presumably with multiple fragments on the backstack). More specifically, after this dialog fragment is "drawn", the test will fail to go back to idle state, which prevents the test to move onto the next step. Therefore, requirements that involves manipulating ingredients in a recipe (adding ingredients to, editing ingredients in, and deleting ingredients from a recipe) will not be possible to include in the tests. Similarly, since Android espresso is not entitled to operate in the camera app, adding a photo to, editing a photo in, and deleting a photo from a recipe will not be possible to include in the test. However, those requirements are guaranteed to work properly. This has proven to be very helpful when making significant changes to the project because it allows you to rerun all of the Intent tests to ensure that nothing has been broken. There is a corresponding Intent test class for each control class. For instance, there is a RecipeTests() method in the class which calls another testing methods. This ensures all tests are run together every time we run a UI test, to ensure consistency.

  5. Object-Oriented Design:

    The UML Class Diagrams are updated on the Wiki Page: https://github.com/CMPUT301F22T01/FoodBit/wiki/UML-Class-Diagram

  6. Product Backlog:

    Our Project Backlog has been updated consistently as we made progress. User story completion is being tracked in the Backlog Progress Board, with the pull requests being linked to the different branches and some to the Board. Any additional work that needed to be done for the project that was unrelated to a specific user story will have either been documented in a separate pull request or in the project board Backlogs. Please view the commit/push/pull history to see the progress throughout.

  7. User Interface Mockups and Storyboard Sequences:

    Our UI Mockups and Storyboard Sequences are always updated as needed and can be found on our wiki, under Storyboard: https://github.com/CMPUT301F22T01/FoodBit/wiki/Storyboard

  8. Sprint Planning and Reviews:

    Apart from our weekly meetings during the lab session with our TA, we coordinated over Discord to discuss and assign tasks, and track our progress.

    User Stories to be completed were tracked on our Project Board Backlog. We maintained communication and coordinated almost daily over Discord. Tasks were assigned individually and pairwise, our practice involved working in our respective branch and then merging to main branch when the required functionality is achieved. Often 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, even when someone was facing any issues we discussed over Discord or during our meetings to resolve that at the earliest. 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, we tried to complete riskier requirements earlier.

  9. Demonstration:

    To be done after during assigned Lab time.

    App Demo will be done in presence of the TA, with all the progress.

  10. Tool Use:

    This project was created using GitHub in its entirety, including GitHub Projects, GitHub Actions for our continuous integration, GitHub Wiki for our bookkeeping, and much more.

Attribution:

.

Clone this wiki locally