capuanomat / where-s-my-stuff2 Goto Github PK

Additionally, you should have a way for a user to search for items.

A user should be able to enter their lost items into the application. This will require a new screen to allow input of data. There should also be a way to view a list of all lost items. Note that filtering or searching is not yet required of the application.

List primary attributes and responsibilities. Note the RDD stereotype of the classes. Annotate relationships between objects (which objects need to use other objects). Show any multiplicity requirements. There is only one domain model required, so this is a team effort.

Persistence can be accomplished in many ways. In class, I will demonstrate four techniques and provide sample code: database (extra credit), custom text file, binary serialization, json serialization. You may use any of these (or a completely different method as long as the data is persisted across program invocations). You may also choose how the loading and saving of data occurs (by user command, automatically on startup and shutdown, or real-time (like a database) where data is saved immediately upon entry).

Add and remove files
Each team member should add a text file to the top level directory labeled readme.pn.txt where the pn would be p1, p2, p3, p4 or p5 based upon which person you are for the lab. The contents of the file can really be anything, but should include your name and email. Each team member should delete the text file useless.pn.txt where pn is p1,p2, p3, p4 or p5 based on your team member number. Do NOT delete the wrong files!!

Use good descriptive Log comments for your changes/commits

Roll back changes by viewing your original branch from an earlier step. Verify that none of the changes you have made are in the project version you checked out.

View Git logs. You can do this on github by viewing the blame and graphs provided
View a diff between two versions of a file
Keep playing with git until you feel comfortable. You will probably be using it extensively for the remainder of the semester.

Use the project description to brainstorm objects. Filter those to get rid of inappropriate objects.

Context diagram must cover all actors

Create a set of UI prototypes (these can be hand drawn) that show the major screens for the application. Then create a flow diagram that shows how the user would navigate from screen to screen.

Lost Item form displays
Lost Items are displayed in a list or other widget

This is where the puppy comes in.

You should now implement the ability to report on items that have been found by users

Edit and commit files as detailed below.

If you examine the src directory, you will see the files Person1.java Person2.java Person3.java Person4.java Person5.java (located in the edu.gatech.oad.antlab.person package)

Each person on the team should choose ONE of these so that everyone is working on a different file.

Now examine your individual file and complete the required method. The javadoc comment will explain what has to be done.

Commit your changes and push back to Git. Now each team member should edit the file edu.gatech.oad.antlab.pkg1.AntLabMain.java at the line indicated. You are basically sending your name to the constructor of the class you edited previously. Since you are all editing the same file, you will need to handle any merge requirements yourselves. You might want to get together and commit files to force a merge so you get some practice doing merges. You will run into them during the project.

During a disaster, morale is low, and suicides tend to increase afterward. So including a crisis hotline (to help the user or someone the user knows) can help avert them.

Initialize a new Git repository. Be sure that your teammates can access the repository also. You will need to work together to complete some portions of this lab. This step is not required if using GitHub hosting

Download the M2 resource file (M2.zip) and unzip it

Import the unzipped files (add, commit and push) as a new project named M2 (Only one person has to do this)

Note that the lib directory contains a resources.jar file. This is to simulate a 3d party library you have to link to. You will need to ensure during the lab that this .jar is on the classpath for compilation and execution.

Create a branch at this point called original.

Each team member should clone out the project M2

BE SURE THAT original REMAINS AS THE UNMODIFIED VERSION and that changes to the branch are done on the main (master) branch.

In the event that a user reporting a found item has stolen it (or somehow harvested it illegally), ban them.

Make sure:

During registration, the new user may designate their account type (User or Admin). In a real application, we would have controls for these, but for this class project, we will let the individual enter their capabilities during registration.

Need to make changes to M, V, and C so that students can add their class standing (Freshman, Sophomore, Junior, Senior, Super Senior).

Just need to make the initial login/welcome screen . They should be able to collect basic information.

This is a better way to hold our info and will enable us to standardize our inputs

Look into the Date and Location classes...
and store our object's date as a Date instead of a String
and an object's location as a Location instead of a String

Why do we do this?
Input constraints. We don't want our users to think, "But that is a perfectly acceptable place name!"
Plus our searching will be easier- think of the possibility that someone mistypes Atlanta as Atalnta and doesn't get to edit.

Standardize the date format. We don't want a string-parsing method every time someone puts in a date (that's highly inefficient). One user could follow the ISO/pretty-much-everyone-except-America standard of DD/MM/YYYY and another could follow MM/DD/YYYY when putting it in a String. These should all be the same:
July 10, 2017 ; Monday, July 10, 2017 ; 十日 七月２０１７*; 10 July 2017 ; 10 juillet 2017* ; 10 julio 2017*; 07/10/2017 ; 07102017; 10/07/2017

*This brings us to a side benefit: internationalization will be a piece of cake in this regard. Our non-English speakers who live here will then be able to use the app!

Update: Made category and condition enums

You may have fewer than 10 user stories if you can cover the entire system in fewer.

Each person on the team pick 1 user story and fully elaborate it (this is an individual grade, so you do not have to cover for a team mate).

Recall from class that an elaborated user story is performed at the start of the sprint/iteration when this story moves into the current sprint and is no longer just in the backlog.

The data for an elaborated user story includes:

• Detailed work tasks to accomplish the story. These should be at a level that allows the developer to check off their progress so team members have an idea how the implementation is going.
• Acceptance Scenarios: In the format: GIVEN: some initial condition relevant to this story, WHEN: the user takes some action or some system event happens , THEN: The system's response to that action. These scenarios should cover both success and failure conditions (what should system do with bad data or other things that can go wrong).
• Done Done criteria: What does it take for the story to be marked done? This can be a standard team criteria shared by all stories (be sure and mark this for TA), or custom for each individual story.

something that pops out when you tap the three-rectangle logo in the corner or swipe from the far left part of the screen
this will let the user access the other parts of the app

Each individual team member will create a build file using gradle that will allow you to perform key tasks to build the application. Name your file with your gtid.gradle for instance: gburdell3.gradle Store your file in the repository,

To run gradle with your file (build.gradle is the default if no file specified) use the -b option, for example: gradle -b gburdell3.gradle

First, each team member should install Gradle onto their machine. Instructions are in the gradle manual at: external link: http://www.gradle.org/

The manual and documentation on the gradle site covers most of the features of gradle. For this lab, we will only be using the most basic of Gradle features and the Java plugin.

You will need to create an executable jar for the project. To do that, you will need to create a manifest. If you are unfamiliar with manifests, then see the official tutorial at: external link: http://docs.oracle.com/javase/tutorial/deployment/jar/

The application you are building also uses packages. You will need to understand how to use packages, as all professional Java projects use them extensively. Again, if you unfamiliar with packages, see the official tutorial at: external link: http://docs.oracle.com/javase/tutorial/java/package/index.html

Your build file should support the following tasks:

compileJava compiles and builds the project
compileTest compiles the unit tests for the project
javadoc creates the html documentation for the project
clean removes all the files created by this project
jar creates the executable jar file for this project

The jar task should be the default if no task is designated when running gradle. Otherwise, gradle will execute the task you request, for example: gradle compileJava will compile your java project.

Each person should pick a non-trivial method (one that has loops and/or conditional statements) and test that method to achieve branch coverage.
Tests will be implemented in JUnit.
Also for the method chosen, write the contract for that method. Remember that the contract should include the signature, pre and post conditions, any invariants and the framing conditions. These are all explained in chapters 4 and 6 of the book.
As I said in class, it is easiest to test back-end classes that do not depend on Android. You can use the special android extensions (like espresso) to test the UI components if you need to.

A new user should be able to register by entering their information (like name, id, and password). If accepted, the new user should be added to the system. If cancelled, the user should not be added.

An idea I had when my computer was out of commission last week:
If we ever experience coding burnout, we should probably take some time off and have fun with this- and get extra credit. See the "concept-for-app-trailer" file for more details.
It's only an initial idea right now, and, of course, we want to do mostly functionality and/or UI-related extra credit, but it is one way to show the UI, functionality, and business value :)

We will now add the ability to display locations of the lost and found items using Google Maps. We will also implement persistence so that you no longer have to re-enter your information every time you restart the application.

You should create a Map Activity and display a map on the phone. There should be pins showing all the locations of both found and lost items. Clicking on a pin should give you some information about the item from the report.

Now we will create sequence diagrams for the application. Go back to your previous design and analysis information and user stories created earlier, and make them into UML sequence diagrams. This is an individual requirement (as always, you do not have to cover for your team mates). Each person should make a sequence diagram that covers their user story and illustrates the dynamic interactions between objects in the design necessary to accomplish that story.

View Git logs. You can do this on github by viewing the blame and graphs provided
View a diff between two versions of a file
Keep playing with git until you feel comfortable. You will probably be using it extensively for the remainder of the semester.

Persistence can be accomplished in many ways. In class, I will demonstrate four techniques and provide sample code: database (extra credit), custom text file, binary serialization, json serialization. You may use any of these (or a completely different method as long as the data is persisted across program invocations). You may also choose how the loading and saving of data occurs (by user command, automatically on startup and shutdown, or real-time (like a database) where data is saved immediately upon entry).

Persistence can be accomplished in many ways. In class, I will demonstrate four techniques and provide sample code: database (extra credit), custom text file, binary serialization, json serialization. You may use any of these (or a completely different method as long as the data is persisted across program invocations). You may also choose how the loading and saving of data occurs (by user command, automatically on startup and shutdown, or real-time (like a database) where data is saved immediately upon entry).

Create the UML class diagram for the complete application. You do not need to show constructors, getters or setters in the methods. You do not need to show private methods or attributes which are for implementation only. This diagram should focus on your model classes. You do not need to model the UI screens (Activities), since these were covered in the UI prototypes/Flow diagram.