Skip to content

Home

Jump to bottom
Z-Red edited this page Apr 9, 2018 · 50 revisions

Welcome to the CDProjektBlue wiki!

Project Components

Part 2

  1. Requirements can be viewed on a user story category basis for their individual specifications.

  2. User Interface and Storyboard

  3. Release Planning

  4. Glossary and Information Resources

Part 3

  1. Regarding mentor feedback:

    • Any links that can be made relative have been made so
    • Images were added to the wiki repository
    • Length and detail of the Glossary has been improved
    • Storyboard: hands removed, included two way arrows

  2. Object-Oriented Analysis and Design

  3. Unit tests can be found here. In coordination with the rubric, unit tests were only done for "model" classes. In particular, only two model classes exist that have functions that required testing. Those are the Task class and the User class. All other model classes did not have functions that should be unit tested.

Part 4

  1. Regarding mentor feedback:

    • Model classes have been highlighted in UML
    • Composition association has been resolved in UML between Bid and User class (changed to aggregation)

  2. Code base:

    • More than half of requirements implemented
    • Limit/error/boundary checking exists for user input parameters
    • Has server connectivity
    • Error checking (try/catch) exists for all server calls

  3. Code documentation (JavaDoc)

  4. Test Cases:

    • Unit Tests
    • Intent Tests
    • Note: could not find any documentation supporting access outside of application with only Robotium or Espresso. Thus, intent tests could not be preformed for Photograph related use cases
    • Note: if the emulator your run the intent tests on does not have updated Google Play Services, then a dialog box suggesting an update (created by the device, not our app) may override the current view on the screen, causing intent tests to fail since the underlying views cannot be accessed. If the dialog appears on your emulator, click outside the dialog box to dismiss it and have the tests continue to completion.

  5. Object Oriented Design (UML)

  6. Revised Release Plan

  7. Reuse Statement

Part 5

Please note that some of the link below direct you to the "Final" branch of the repository and not master.

  1. Regarding Mentor Feedback:

    • The User Interface has been overhauled to provide a better experience for the user
    • Connectivity issues have been addressed

  2. Code Base:

    • All requirements implemented
    • Complete connectivity to the server
    • Limit/error checking exists throughout the code for boundaries and exceptions
    • Code is in coordination with the textual use cases provided in the wiki

  3. Code Documentation:

    • Javadoc exists for model classes (Task, Review, Bid, User) and some other classes
    • Code comments exist throughout

  4. Test Cases:

    • Unit Tests
    • Intent Tests
    • You will notice that all geolocation use cases are supported by our intent tests :)
    • Note: could not find any documentation supporting access outside of application with only Robotium or Espresso. Thus, intent tests could not be preformed for Photograph related use cases. Moreover, we could not establish a way to provide a "mock" photo so photo viewing could not be performed as an intent test
    • Note: if the emulator you run the intent tests on does not have updated Google Play Services, then a dialog box suggesting an update (created by the device, not our app) may override the current view on the screen, causing intent tests to fail since the underlying views cannot be accessed. If the dialog appears on your emulator, click outside the dialog box to dismiss it and have the tests continue to completion. To prevent this, an emulator (like Nexus 5X API 26) with Google Play Store and Google Play package would work for intent testing our application.

  5. Requirement Specifications:

  6. Object Oriented Design (UML)

  7. Final/Future Release Plan

    • Please note, this does not contain a schedule like previous release plans as all work has now been completed. Instead, we provide a small section about potential and future improvements to the application.

  8. Reuse Statement

  9. Video Demo The video covers the following key points of the application:

    • Adding and editing tasks, including specifying the location of a task and viewing photographs (Task Basics, Geolocation, Photographs)
    • Finding and viewing tasks (Searching, Task Details)
    • Making bids on tasks and accepting task bids (Task Bidding)
    • Fulfilling requests (Task Assigned, Task Done)
    • Examining user reviews/ratings (Reviews / "Wow" Factor)
    • Although it was not explicitly stated that offline behaviour is a component, we left that as such because we did not feel it was a key point of the application, but rather supplementary to the application, and was more a "quality of life" improvement for the users. E.g., perhaps the user loses connection momentarily while adding a task, they need not know the offline functionality is working behind the scenes. Instead, we chose to cover the most important Use Cases with either audio explanation or direct use of the application through video capture.
    • The video leaves out the technical information by not mundanely iterating through each minuscule feature of the app. It instead provides an engaging way to intrigue a potential customer by combining app usage and live acting to keep the video interesting and maintain the viewers attention. For instance, a customer cares more about the general functionality of the app, and not necessarily how to navigate the menus.
    • Most importantly, the video demo conveys the general purpose of the application and provides reasons for why someone might use it.
    • Note: The textual transcription of the video is available both as closed captioning on the video and also in the video description.
Clone this wiki locally