commiting all the files from private repositories

RushabhBhansali · Jul 30, 2018 · 3d24fd4 · 3d24fd4
commit 3d24fd4
Show file tree

Hide file tree

Showing 205 changed files with 13,411 additions and 0 deletions.
diff --git a/Docs/DesignDocument.md b/Docs/DesignDocument.md
@@ -0,0 +1,78 @@
+# Design Document
+
+**Authors**: Rushabh Bhansali, Rob Sylvester (Team 48)
+##### Version 2
+
+## 1 Design Considerations
+
+This Android Application is intended to run smoothly on the Android version 6.0. The design should make the application to be as simple and lightweight as possible. The substitution cipher presentation needs to be intuitive, and the design should be mostly minimalist to support abstracting away the logic mostly behind the scenes and to keep the interface simple, especially for compatibility with all types of phones.
+
+### 1.1 Assumptions
+
+1. The Design assumes that the user is familiar with basic knoweledge about an Android Application usage and interactions. In particular, the user is expected to know how to launch an application if using a physical device, and how to use the back button.
+1. The application is targeted to run on an Android version 6.0 and above and the user accessing the application should have permission to write data to the SQLLite database on which this application is running.
+1. The application is designed to run independently. It will not communicate with any other application in the targeted device. The Android operating system should allow the application to be installed and access the required resources. The application is not expected to be run if any permission is denied.
+1. The application is designed to store user data on the device memory. The access to the external memory is not integrated in the application design at the time.
+1. he application is developed at a minimum sdk 23 and target sdk 26. 
+1. Finally, it should be stressed that the bulk of the activity tests in the application run on Android espresso, runner, and rule, so it is assumed that for testing purposes that these tools are present in Android Studio or any other IDE. This makes usage of mocking interactions much easier.
+
+### 1.2 Constraints
+
+Since the Application is designed to be run primarily on an android device with limited size screen, the amount of user interactions are limited on a specific screen. This constraint is highlighted in the GUI mockup of the design. You will notice that the majority of the activities hold between 3-5 components on screen, and they are mostly just simple text views or buttons to navigate between activities.
+
+In addition to this, the logic of the application is heavily abstracted away in a database. While the application likely will never run into memory issues with respect to the size of this database, it should be noted that if the database is never cleared (and it is), or if thousands upon thousands of users and cryptograms get created, things might begin to slow down.
+
+
+### 1.3 System Environment
+
+The Application is designed for the Android devices running Android version 6.0 and up. Again, we target SDK 26 with a minimum SDK 23. The user interaction with the app is touch-based, so the application is expected to be run on a touch screen device. The GUI of the app is primarily targeted for Standerd size mobile devices (upto about 6.0 inch). The Scaling of the App for larger screen devices such as tablet may not be intuitive for the user. However, the application is still expected to be functional in the large screen devices. This means that we can heavily make use of relative layouts, as well as constraint layouts in certain cases, so that we can define UI components in such a way that they will be visually appealing on all devices and the UI will appear as smooth as possible.
+
+## 2 Architectural Design
+
+### 2.1 Component Diagram
+
+Since all the application components are based locally on the device, a simple component diagram below sums up the simple three high-level components.
+![Component Diagram](Images/ComponentDiagram.png "Component Diagram") 
+
+The application itself consists of primarily activities, and these activities control UI interaction and access to the database. There are tentatively planned to be 10 activities in total, but this may increase to 11 depending on how we handle the statistics that are viewed for individual cryptograms. The database will be abstracted away from the activity logic through a database API. 
+
+### 2.2 Deployment Diagram
+
+All the components of the system are deployed locally on the device. The deployment diagram is unnecessary. That being said, we should state that the database itself is a SQLite database, which is accessed through android.database.sqllite. On the actual Android device filesystem, these files are stored away in /data/data/<packagename>/databases
+
+## 3 Low-Level Design
+
+The Application consists mainly of 2 components, the code base (Activity files) and the database. There are also, of course, a few hundred tests too for each of these components. The database lives in a single file, as do its tests, and each Activity file has its own Espresso test. 
+
+The class structure of the Codebase is depicted in the class diagram in the next section. The database is used to store user data and game data that is shared among all the users. We can now walk through these two components and break down their individual components, and what they are, and how they interact. Refer to the list that follows alongside the mockups that come in section 4.
+
+#### Code Base (List of Activities)
+1. **Main** - The landing page for the application. Users cannot work with cryptograms until they login. This means that they either login as an existing player, or create an account, and then login with that account.
+2. **Login** - Once a user has created an account, they enter their account name and login. There are no authentication systems present here. Simply enter a valid username and you will be taken to the home screen, otherwise an appropriate error message will be shown.
+3. **Create Player** - Users create players by entering a unique username, as well as some other basic info. This creates an entry in the 'players' database table, and promptly brings the player to the login page.
+4. **Player Home Screen** - Players that are logged in use this as sort of a home base. From here, they can create cryptograms, solve cryptograms, list their unsolved/solved cryptograms, see statistics for cryptograms, or switch users. So think of this like a set of buttons that will lead to each of these respective five activities, which is, well, exactly what the mockup shows.
+5. **Create Cryptograms** - A cryptogram must be created by a user before another user can play it, and of course you can play your own cryptogram, an endeavor that might be exciting to someone with severe Alzheimer's. Nonetheless, cryptogram creation will insert cryptograms into the database just like player creation inserted into the player database. Cryptogram names must be unique. Furthermore, since they use substitution ciphers, the design must verify that cryptograms are indeed solvable. Users choose the character->character mappings, and since players will be presented with encoded phrases, care is taken to verify that cryptograms are solvable before sent to the database. Users of course can view their encoded cryptogram text before it is saved in the database.
+6. **View Unsolved Cryptgorams** - This is simply a table of cryptograms that are yet to be solved by players. Clicking on an unsolved cryptogram brings you to the cryptogram solver. Note that if you fail to solve a cryptogram in the specified number of attempts by its creator, it will leave the unsolved table and enter the completed table.
+7. **Play Cryptogram** - Similar to the create cryptogram model and view, this is where players work in reverse order by working with an encoded phrase and entering the character->character mappings for the solution phrase. When a user first attempts a solution, an entry is creating in the puzzles table that stores information on the many:many mapping of users and cryptograms to the puzzles table. This makes it easy to store when and if cryptograms are solved, how many attempts there have been, and who has attempted which cryptograms.
+8. **View Completed Cryptograms** - This table is similar to the unsolved cryptograms, except you can't play them anymore (unless you make a new username). This stores the result of whether or not you actually solved it, as well as the time (if applicable) of when you did solve the cryptogram.
+9. **View Statistics** - This is where you get a table of all cryptograms, and if you click on one of them in this table, ordered by creation date, you'll be brought to...
+10. **View Statistics (Individual Cryptogram)** - This is where you get to see full stats for a given cryptogram, including when it was created, how many times it has been solved, and who the first three solvers were.
+
+#### Database
+1. **players table** - This will store the usernames of players and other information to control entry into the application for playing cryptograms and loading the tables properly.
+1. **cryptograms table** - This will store the cryptogram info, mainly the name, and the encoded and decoded strings.
+1. **puzzles table** - This will store how individual players are doing solving individual cryptograms. Between these three tables, we have everything we need to drive the logic of the application without really individual classes for the cryptograms, players and puzzles.
+
+Note that the Database itself will have a rich API that will have method calls for such things as playerExists(username), checkSolution(cryptogramName, solutionPhrase), and more. This API will allow for the activity logic to be simpler to follow, and allow for better unit testing on the database side of things. 
+
+### 3.1 Class Diagram
+
+The following Class diagram represents the static class structure for the components of the Application and their relationships.
+![Class Diagram](Images/ClassDiagram.png "Class Diagram") 
+
+## 4 User Interface Design
+
+The following image displays the graphical mockup of the User Interface. There are ten different Views in the App. All the specified user interactions are covered in these ten views. This mockup describes type of interaction on each view of the app, however the final decision regarding the format of these elements will be moved around during the final phase of the application.
+
+![GUI Mockup](Images/Android_Mockup.png "GUI_mockup")
+
diff --git a/Docs/ExtraRequirements.md b/Docs/ExtraRequirements.md
@@ -0,0 +1,19 @@
+# Extra Requirements
+**Author**:   **Chris Crabtree (Team 48)**
+## 1. The application must exhibit satisfactory response times
+-     The time interval between the user input to start the game and the game being ready to take input should not exceed 5 seconds.
+-     User interface elements should not display noticeable lag.
+-     Storage and update operations should take no more than 5 seconds to complete.
+## 2. The spplication must give appropriate user feedback
+-     Invalid or missing data fields should be indicated when the user attempts save or update operations.
+## 3. Operating System and Interoperability Requirements 
+-     The application must run on Android Marshmellow (API 23) or later.
+-     The application must scale to various screen sizes and resolutions
+-     The application must pause execution if the user answers a call or switches to another applicaiton.
+-     All traces of the application must be removed when the application is uninstalled from a device.
+## 4. Appearance
+-     The user interface must be attractive.
+-     The user interface must be easy to navigate.
+-     All forms should be based on a common template and have a consistent appearance.
+## 5. Security
+-     The application must not request any permissions beyond those needed to store cryptogram and user data.   
diff --git a/Docs/Images/Android_Mockup.png b/Docs/Images/Android_Mockup.png
diff --git a/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-26-18.png b/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-26-18.png
diff --git a/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-29-35.png b/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-29-35.png
diff --git a/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-34-43.png b/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-34-43.png
diff --git a/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-34-46.png b/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-34-46.png
diff --git a/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-35-52.png b/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-35-52.png
diff --git a/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-57-50.png b/Docs/Images/AppScrShots/Screenshot_2018-07-10-22-57-50.png
diff --git a/Docs/Images/AppScrShots/Screenshot_2018-07-10-23-04-50.png b/Docs/Images/AppScrShots/Screenshot_2018-07-10-23-04-50.png
diff --git a/Docs/Images/AppScrShots/Screenshot_2018-07-10-23-05-15.png b/Docs/Images/AppScrShots/Screenshot_2018-07-10-23-05-15.png
diff --git a/Docs/Images/AppScrShots/Screenshot_2018-07-10-23-05-28.png b/Docs/Images/AppScrShots/Screenshot_2018-07-10-23-05-28.png
diff --git a/Docs/Images/AppScrShots/completed.png b/Docs/Images/AppScrShots/completed.png
diff --git a/Docs/Images/AppScrShots/create_new_cryptogram.png b/Docs/Images/AppScrShots/create_new_cryptogram.png
diff --git a/Docs/Images/AppScrShots/cryptogram_game.png b/Docs/Images/AppScrShots/cryptogram_game.png
diff --git a/Docs/Images/AppScrShots/cryptogram_statistics.png b/Docs/Images/AppScrShots/cryptogram_statistics.png
diff --git a/Docs/Images/AppScrShots/list_unsolved.png b/Docs/Images/AppScrShots/list_unsolved.png
diff --git a/Docs/Images/AppScrShots/login.png b/Docs/Images/AppScrShots/login.png
diff --git a/Docs/Images/AppScrShots/new_player.png b/Docs/Images/AppScrShots/new_player.png
diff --git a/Docs/Images/AppScrShots/player_home.png b/Docs/Images/AppScrShots/player_home.png
diff --git a/Docs/Images/AppScrShots/statistics.png b/Docs/Images/AppScrShots/statistics.png
diff --git a/Docs/Images/AppScrShots/welcome.png b/Docs/Images/AppScrShots/welcome.png
diff --git a/Docs/Images/ClassDiagram.png b/Docs/Images/ClassDiagram.png
diff --git a/Docs/Images/ComponentDiagram.png b/Docs/Images/ComponentDiagram.png
diff --git a/Docs/Images/Individual_Mockup_Screens/completed.png b/Docs/Images/Individual_Mockup_Screens/completed.png
diff --git a/Docs/Images/Individual_Mockup_Screens/create_new_cryptogram.png b/Docs/Images/Individual_Mockup_Screens/create_new_cryptogram.png
diff --git a/Docs/Images/Individual_Mockup_Screens/cryptogram_game.png b/Docs/Images/Individual_Mockup_Screens/cryptogram_game.png
diff --git a/Docs/Images/Individual_Mockup_Screens/cryptogram_statistics.png b/Docs/Images/Individual_Mockup_Screens/cryptogram_statistics.png
diff --git a/Docs/Images/Individual_Mockup_Screens/list_unsolved.png b/Docs/Images/Individual_Mockup_Screens/list_unsolved.png
diff --git a/Docs/Images/Individual_Mockup_Screens/login.png b/Docs/Images/Individual_Mockup_Screens/login.png
diff --git a/Docs/Images/Individual_Mockup_Screens/new_player.png b/Docs/Images/Individual_Mockup_Screens/new_player.png
diff --git a/Docs/Images/Individual_Mockup_Screens/player_home.png b/Docs/Images/Individual_Mockup_Screens/player_home.png
diff --git a/Docs/Images/Individual_Mockup_Screens/statistics.png b/Docs/Images/Individual_Mockup_Screens/statistics.png
diff --git a/Docs/Images/Individual_Mockup_Screens/welcome.png b/Docs/Images/Individual_Mockup_Screens/welcome.png
diff --git a/Docs/Images/TestCoverage.PNG b/Docs/Images/TestCoverage.PNG
diff --git a/Docs/Images/UsecaseDiagram.png b/Docs/Images/UsecaseDiagram.png
diff --git a/Docs/ProjectPlan.md b/Docs/ProjectPlan.md
@@ -0,0 +1,76 @@
+# Project Plan
+
+**Author**: Chris Crabtree>
+
+## 1. Introduction
+
+SDPCryptogram is simple Android game puzzle game.  This game presents the user with a simple interface that can be used to generate and share cryptographic puzzles on an Android device.
+
+## 2. Process Description
+
+
+1. Coordinating
+   - Description: Coordination of team member schedules. Establishing communication protocols between team members
+   - Entrance Criteria: Triggered by release of project requirements for this phase
+   - Exit Criteria: Team members have all spoken in person. Collaboration platform chosen and all members have access
+
+2. Designing and planning
+   - Description:
+     - Refine the initial design based on new requirements and understand of the assignment.
+	 - Identify required documentation per the assignment.
+	 - Define functional tests
+	 - Define extra requirements
+   - Entrance Criteria: All team members have read the current assignment.
+   - Exit Criteria: Team members have assignments and know which deliverables they are required to produce.  
+
+3. Documentating
+   - Description:  Team member creates assgined documents.
+   - Entrance Criteria: Completion of design and planning activities (#2)
+   - Exit Criteria: Assigned documents are checked into the repo.
+
+4. Developing
+   - Description:  Team members create application activities and layouts.  Team members write Java code to support the app's activities.  Team members write unit tests to verify the functionality and correctness of Java code.
+   - Entrance Criteria: Design work has completed.  (#2)  Documentation is in progress or has been completed. (#3)
+   - Exit Criteria: All application activities and Java code have been written and checked into the repository.  The application meets functional requirements and the classes and methods of the Java code pass unit testing. (#5)
+
+5. Testing
+   - Description:  Team members execute unit tests on Java code.  Team members perform function testing on the application.
+   - Entrance Criteria: Unit testing for classes and methods begins when they are added to the repository.  Funcational testing of the application is carried out as features are implemented in development.  (#4)
+   - Exit Criteria: The application substantially passes functional testing.  Java classes and methods substantially pass unit testing.
+
+6. Reviewing
+   - Description:  Team members review documentation and test results.  Team members provide feedback and indicate any updates needed in processes 3 and 4.
+   - Entrance Criteria: Each document can be reviewed when it is submitted into the repo in the documentation phase. (#3)  Test results are reviewed as they are generated. (#5)
+   - Exit Criteria: All documents have been reviewd by at least one other team member.  All test results are reviewed by at least one other team member.
+
+ 7. Submitting:
+    - Description:  A single team member merges all branches and submits the assignment.
+	- Entrance criteria: All documents have been submitted and reviewed.
+	- Exit criteria: The last commit ID is submitted.
+
+
+## 3. Team
+
+*Describe the team and their roles (there may be more roles than there are team members)*
+
+- Team members:
+  - Rushabh Bhansali, rbhansali9, [email protected]
+  - Chris Crabtree, ccrabtree6, [email protected]
+  - Rob Sylvester, rsylvester6, [email protected]
+  - Jason Melton, jmelton32, [email protected]
+- Roles:
+  - Coordinator: The coordinator schedules meetings, checks on the progress of work, and manages collaboration tools.
+  - Designer: The designer transforms requirements into written and visual designs.
+  - Reviewer: The reviewer reads the work of other team members and gives constructive feedback.
+  - Developer: Creates activitity layouts.  Writes Java code.
+  - Tester: Executes functional and unit tests
+  - Submitter: The submitter merges the repo branches and submits the final revision of the assignment.
+
+
+
+|Member| Coordinator  | Designer |Documentor|Reviewer|Developer|Tester|Submitter|
+| --- | --- | --- | --- | --- | --- | --- | --- |
+|Rushabh Bhansali|X|X|X|X|X|X||
+|Chris Crabtree|X|X|X|X||X||
+|Rob Sylvester||X|X|X|X|X||
+|Jason Melton||X|X|X|X|X||