-
Notifications
You must be signed in to change notification settings - Fork 1
Report week 10
This week, I focused on polishing the application for the camera preview. I added no new features but did some refactoring and bug fixing. The ComputePOIPoints class was refactored and reorganised because it was not possible to have a clear overview of the class anymore with all the functionalities that were added to this class.
After that, I had two tasks to fix two bugs. The first one was that the chosen language was not set correctly at the startup of the application and the other one was that the retrieved data to display the peaks seemed to be requested in a loop. For the second problem, however, I was not able to reproduce it. Either the problem was fixed unknowingly in another PR or the problem was caused by the location listener of the device giving wrong data. Since I could not reproduce the problem, I could not fix it. Therefore, I addressed other bugs for the time that I had left. I managed to fix two other bugs in the estimated 3 hours that I had given myself to fix the bug with the multiple requesting of the data.
The two new bugs that were fixed are rather important bugs as they have a direct impact on the user experience. The first one was that the markers and compass were not staying at the same position when rotating. This was because the field of view was calculated for a camera-preview of aspect-ratio of 4:3. The other bug was that when changing the device from portrait mode to landscape left/right mode, there seemed to be an offset in the compass. This was because the coordinate system was not remapped correctly depending on the orientation of the device.
I finished all my tasks and was pretty happy with my time estimates. However, my last PR was uploaded really late. This is something that should not happen especially now where the pressure rises because the end is coming.
I had two tasks to accomplish this week, both related to the stress user story implementation. As Giovanni started the implementation of the challenges last week, I needed to improve and modify some of the classes he has done. I changed the points challenges to max points reached challenges. The previous version of the challenge needed to set a goal for the user to take the reward. I added creation/start/finish dates for the challenges and removed the goal. I also added a status attribute to see if the challenge is pending/ongoing/ended. The starting of the challenge has also be changed. When a user A creates a challenge, it is put in pending and as soon as a second user joins the challenge, it is passed in oingoing status. A handler has been created to handle the end of the challenges. When the user logs in the app, the handler scans all challenges and linke a timed callback function to each of them. When the challenge finishes, the callback gets called and the winner is retrieved among the enrolled users. A challenge is deleted from the database when every enrolled users have logged in to see if they won (since we don't have a server instance to handle the challenges, all clients must do their part).
At beginning I had trouble understanding the new database implementation, but in the end it is very conveniant to use. I respected the time of my two tasks this week.
This week I had two main tasks.
The first was to improve the DB abstractions, as the previous week I came up with a new idea to make the code easier to change whenever our DB provider stops working (even if it should not happen). Basically, I made a bunch of classes that enwrap Firebase API calls. This way we just need to change these classes and not all the classes that make use of the DB. This task took just a little more than expected, as for the wrapper DB classes I tried to follow the same logic of Firebase classes (no need to reinvent the wheel!), with Queries, References, and DataSnapshots.
The second was to connect the new profile activity made by Alexander to the actual authenticated account. I spent quite more time than I thought as I underestimated the time needed to solve some UI problems (like how to handle the registration phase of our app, how to make the change username UI prettier).
The last minor task I had was to solve a problem with the rankings tests. Until now, to fully test the functionalities, we used to add and then remove some test users from the DB. This was creating problems as these users had to be the first 20 users in the rankings. In addition, it was not that practical. I found another way of testing the rankings: we just check that the items displayed are in the correct order and that when a user's score/nickname changes, the rankings behave correctly. This should solve a lot of the problems with the rankings tests and is also more natural as a test for this functionality. However, I applied it just to the new social activity as the current RankingsActivity will be gone by the end of next week. As I finished this task earlier, I also implemented the connection between the avatars in the social activities and the actual profile images of the users.
This week I've worked a lot more than expected, but I finished all my tasks as we are running out of time. I'm also noticing that I'm quite good at estimating tasks of which I know well the possible problems, whereas I still need to improve my estimations when I'm not sure of the potential hurdles. It may be quite natural to have this problem, but I still feel like it is something that I need to work on, even after this course.
This week I focused on implementing more part for the new UI. I worked on creating a social activity that, would be the new way of showing ("rankings"). Me estimations was again a bit off, not good with the same issue twice in a row. It was the same issue as the week before, one small part of what I wanted to implement was hard to find the "correct" way of doing. Forcing me to "loose" several hours of googling.
I said the week prior that I would keep in mind with estimating UI too add some extra time, which I did. However obviously it was not enough. I will have to add more extra hours for finding solutions if I do a UI task again.
This week I worked on fixing a bug related to the line of sight that filters the POIs that are visible/not visible. I spent almost 8 hours finding the source of the problem, which was related to the Bresenham algorithm. I was able to fix the bug which required some lines of code to be changed but in the meanwhile, I found two other small bugs that cause the POIs not to be filtered correctly. This bugs should be an easy fix as the source of the problem is already tracked.
The hardest part was to find the source of the problem as I had to log a lot of data and try to understand where the problem was occurring. I have been working on a separate branch to do the debugging and then fixing it on another branch in order not to risk to make unwanted changes.
We are starting to notice that we are running out of time. However as a group we still believe our project is at a good position regarding the time.
This week we have focused on what could be categorized mainly three things Bugs, New UI and Challenges. Not all but a majority of the tasks completed this sprint was regarding one of these categorize. The week went well. Everybody was able to finish the task they set out to do, and we firmly believe that by the end of next week the App will be in good shape for presentation.