-
Notifications
You must be signed in to change notification settings - Fork 1
Weekly Status Updates
This week we implemented localization for our application in Chinese. We also refactored the backend to more efficiently cancel pending MetroBike requests to the Google APIs. This involved changing the way it was previously implemented to using thread.interrupt to interrupt the sleeping threads. The reason the threads were sleeping was because the Google APIs wouldn't let us query them too quickly as required by the smarter algorithms. By using this command we are doing a better job of interrupting the threads to cancel the queries sooner. We also updated the UI to account for this.
- UI Localization->each person is in charge of their respective activity pages (Xinyun, Shuo, Sam, Qinyuan)
- Implement the thread.interrupt requirements at the UI level (Shuo)
- Create the new icons as required by localization (Qinyuan)
- Delete old cancel system (Jaylen)
- Figure out how to project our app on demo day (Jaylen)
- Wiki-Post (Corey)
- Implement new cancel system in backend (Adrian)
- Implement required backend functionality for localization (Adrian)
During the meeting we spent most of the time deciding what would be considered a valid refactor. This proved slightly difficult since we are fairly happy with our code, but we decided to refactor the cancellation functionality to use thread.interrupt. We decided to do localization for our application in Chinese since our team has multiple Chinese speakers.
We finished the Version 1 release of our app this phase. This included the following features:
- Route filtering by advanced options (and UI support)
- Rejection of overly long routes
- Advanced algorithm for route finding
- Ability to cancel search (and UI support)
- Copyright information
- Improved testing coverage
- Min and Max number of bus transfers option
- Min and Max bicycling distance option
- Enabled GPS location
- Enabled reading and writing history addresses to a android file
We also implemented special test cases such as load testing and simulating a connection failure on an android device. On top of this we added substantial logging and tested the UI with the UI Exerciser Monkey. We increased our testing coverage as well.
- Usability Test - Xinyuan, Sam
- Monkey test - Adrian
- Route filtering by advanced options (Backend) - Jaylen
- Route filtering by advanced options (UI) - Shuo
- Rejection of overly long routes - Adrian
- Advanced algorithm for route finding - Adrian, Qinyuan
- Ability to cancel search (Backend) - Jaylen
- Ability to cancel search (UI) - Shuo
- Copyright information - Shuo, Sam
- Improved testing coverage - Qinyuan, Corey
- Min and Max number of bus transfers option - Shuo
- Min and Max bicycling distance option - Jaylen
- Enabled GPS location - Sam, Shuo
- Enabled reading and writing history addresses to a android file - Sam
- Enhance result page - Qinyuan
- Enhance buttons and other UI details - Qinyuan, Shuo
- New details and Navigate page - Xinyun
At the meeting we decided we could no longer do the integration testing option from the TEST2 items because there was not a good test case to use JMock with. This caused us to switch to reliability testing. We also decided to implement a two stage code freeze. The first was a feature freeze that took effect Sunday morning at 4:00 AM. After this point, no more features were allowed to be added to the code base. Bug fixes were still okay. The second code freeze took effect on Sunday at 5:00 pm. At this point the project was essentially complete and no new additions to the code base were to take effect. This was in order to give Jaylen ample time take care of any remaining issues and to make sure the project was building. We also had a status update from the UI group regarding the usability studies. They reported them as completed and uploaded their documents to a Google Drive folder.
This week we completed mostly bug fixes for the project. We also started looking into setting up integration testing. We updated Jenkins to include checking the checkstyle formats in the testing files. We also fixed the testing files to make them mostly checkstyle compliant. We also added in the bus numbers and times to the backend so the users can see this.
- Email the TA features/testing Types. (Jaylen)
- Monitor Jenkins for build errors. (Jaylen)
- Add arrival time feature to backend so the user knows when the bus arrives. (Adrian)
- Look into GPS functionality/implementation for current location. (Shuo)
- Add in integration tests (Corey)
- Usability testing. (Xinyun)
- Cancelable request for when the Google request is taking too long. (Qinyuan)
- Make the history storage permanent. (Sam)
We discussed the previous weeks work and talked about how the new form of the code reviews was working. It was decided that the new more formal code review format was an improvement of the previous less structured form. We also decided which of the two "documentation" tasks we were going to complete. We decided to do integration testing and usability testing. We also talked about todos for the following week and assigned them to teams.
This week we completed all of the back-end testing. The majority of all the tests were calling the back-end code as it was difficult to write unit tests to hit the front-end code. We added bus number and departure times to the back-end code so that they could be displayed to the users. This was something that we had forgotten to do when we initially created the JSON parsing code. We also built the main part of the algorithm that combines transit directions with biking. We converted unit tests that were written using JUnit 4 into JUnit 3 as JUnit 4 tests will not run on Jenkins. We improved error handling messages in the back-end to not send duplicate messages and also improved error handling throughout the project to prevent it from crashing the app. One other noticeable change we made was stripping out the html tags in the instructions so we can display friendlier instructions to the user.
- Write Unit tests (black and white box) for the existing code. (Corey)
- Create the main algorithm that merges the transit directions with the bicycle directions. (Adrian)
- Set up the Jenkins automated build. Include checkstyle and code coverage. (Jaylen)
- Retain the map state when you hit the back button. (Shuo)
- Fix the maps to not use a hard-coded zoom window. It needs to be based on how big the route is so you can see the whole route. (Qinyuan)
- Fix the checkstyle issues in the UI code. (Qinyuan)
- Add the navigate activity so that the users can see the turn-by-turn directions after making the request. (Xinyun)
- Add the history activity so that we can incorporate the history functionality into the map app. (Sam)
We discussed in our meeting the progress from the previous week. This was getting Jenkins set up and unit test stubs running on Jenkins (as well as having Jenkins do checkstyle and code coverage). We came up with a more official code review format based on feedback from the previous week from the customer TA. The new format was described in Jaylen's email which can be found here: https://github.com/alaurenz/metrobike/wiki/New-Code-Review-Template . We then discussed what needed to be completed the following week. This was writing all the unit tests and adding some additional functionality/bug fixes.
We finished the Pure Jave stuff which is used for next phase. On the UI side, we finished drawing new good polyline on the graph now. The backend algorithm that supports this feature is also created. We fixed the problem of that the app will open new pages when switch around activities. This is an important step in android life cycle handling. We also start to think about how to test the backend and UI.
- Complete new backend methods (Jaylen/Corey)
- Decoding polyline (Adrian)
- Mixed bike-transit algorithm (Adrian, Qinyuan)
- Get UI Functional (UI Team)
We came up with what to do for next phase (Beta) We discussed what to do on the UI and how to test everything. We also define the tasks for each team member as described above. The meeting also included team member change which Qinyuan will be drafted to Algorithm team. But Qinyuan will still be in charge of the result page.
We finished the UML documents for this phase. The backend is also nearly complete aside from minor touch ups and tweaking. This includes parsing the JSON, making the Google Maps API requests, and returning routes back to the user. The UI has had major progress made and we are currently able to draw lines on the map (Though there are still some issues with correctly drawing them).
- Complete stub methods in backend so UI can begin developing->due Wednesday (Jaylen/Corey)
- Code/Style Guidelines (Corey)
- UML Docs (Adrian)
- Finish Backend (Corey/Jaylen)
- Get UI Functional (UI Team)
We came up with the timeline to finish the phase 2 part of the project. We determined when certain features in the backend had to be completed so that the UI team would not be blocked. We also figured out how we would be doing code reviews so that they would actually be completed in a timely manner. It was decided that everyone would be responsible for a specific person to code review. We also discussed our style guidelines and how to set that up.
This week we did most of the class design during one of our meetings. We started work on the official uml class diagram but need to complete it as well as the sequence diagram. We also set up the code and style guidelines. This document is a wiki named Coding Conventions. We set up another project in the repo called MetroBike that will house the actual production code since the ZFR wasn't necessarily going in the same direction as our final product. We went to the UI Demo meeting and found that our UI design was fairly intuitive to use. There were a couple of wordings we needed to change but all in all we were pleased with the outcome of this meeting.
- Set Up the Code Style Guidelines (Corey)
- Class docs UML class diagrams (Adrian)
- Use Case Email (Jaylen)
- UI Results (Qinyuan)
- UI About (Sam)
- UI Search (Shou)
- UI Results (Xinyun)
During this meeting we picked the use case to support and implement. We also resolved some GitHub issues and decided how to break apart the project into packages in order to minimize conflicts (We want an android package and a Java package->that way we can test the backend without needing the emulator). We then discussed policies on code reviews and pushing changes to the repos. We then figured out how to split up the work for the next two weeks.
This week we completed the UI Draft, the SRS document, and the ZFR. We also setup the bug tracking system in GitHub complete with milestones corresponding to each phase. We also completed the use cases document and the setup document for new team members. These have been committed to GitHub.
- Assign Tasks to members at next meeting (Jaylen)
- Wiki Post (Corey)
- Design the Classes (Team)
- Create Class Design Documents (tbd)
- Build Phase 1 UI (tbd)
- Link up the Google Web APIs to the Android Libraries (tbd)
In the meeting we went over the UI draft and gave the designer feedback. We also went over the project plan and decided what should be completed by each phase of the project. We went over and got consensus on the use cases. We verified everyone was able to successfully push to the repo. We also tweaked the HuskySoft logo. We decided on ways that our app could make revenue. We then assigned todos for the coming week.
This week the team got basic setup stuff out of the way. GitHub is now setup the team members downloaded the tools necessary for android development. Furthermore, the logo/icon was also completed
Setup
- Setup Phab/wiki (Corey)
- Setup GitHub repo (Adrian)
- Personal Hello World Test (Everyone)
- Make first wiki post (Corey)
Zero Feature Release (ZFR)
- Make icon/logo (Qinyuan, Shuo)
- Build “Hello MetroBike” App
- Connection for Google Maps Web API (Jaylen)
Software Requirements Spec (SRS)
- Draft UI (paper prototype) (Sam, Xinyun, Shuo)
- Requirements Spec Document (Corey, Adrian, Qinyuan, Jaylen)
- Use Cases (Corey, Adrian, Qinyuan, Jaylen)
- 2 formal
- 1 casual
- Prototype/Draft UI (Sam, Xinyun, Shuo)
In this meeting the team discussed what their strengths (programming languages and tool familiarity) were and what they would like to work on regarding MetroBike. We then discussed what needed to be done this week and started to assign tasks. We also decided that the team should all do basic setup and look over the Google Map's APIs. Any potential confusion about what exactly the project was is now hopefully cleared up among all the team members.