Sprint Summary - polypoly-team/android-app GitHub Wiki

Welcome to our pretty Sprint Summary!


Sprint 1 (02/03 - 17/03)

victor (vrooomer)

During this first sprint I was the Scrum Master and it was quite difficult to make sure that everyone communicates and synchronize the whole team. However it turned pretty well and even if not all of the tasks were done, the final work is pretty encouraging :)

Also, I had to create the welcome screen in WelcomeActivity, it should have taken me 5h but because it was the first time I worked that much with Jetpack Compose (especially testing), it took me 8h. My second task was to implement music, it was easier than I thought but a lot of features aren't there (yet, maybe in next sprints?). I have a bug where the music stops with no reason at random times, I put that in the issues.

To conclude, I'd say that we had some issues with the PR and even if we do them, we never managed to agree on a way of merging them to the main branch. However we now have more experience and it will be an easier task for the next sprint.

~ v:)

Khalil

I managed to implements features related to location these last two weeks:

  • tracking current location
  • tracking distance to arbitrary checkpoints
  • counting distance walked

As well as a map overlay showing all the above. No main difficulties were encountered, besides running out of time to work my second task, and deciding to produce more code that would implement a feature without thinking about technical debt. This will be fixed by next week.

Hugo (Jharaxus)

I first implemented some backend data-structures to represent core concepts of the App. Then I connected the app with Firebase to register User-related data in the database. To do that, I decided to split the list of user ids and the actual users' information into two separate objects in the DB to improve the access efficiency. However when doing that I had some issue to retrieve the list of existing ids which I will have to fix during the next sprint.

Maxime (Kaz-ookid)

I started the sprint with the easy task of finishing the implementation of the google authentication system to our app. It lays in the google_auth branch, waiting to be used for good :) Then I implemented the ability to join a group given a code, all wrapped in the JoinGroupActivity. This was overall pretty easy and straight-forward, but the feature still relies on some mock functions imitating DB responses, like when checking if a group is existent or not.

I have had some issues figuring out how to effectively test Toasts values, and ended up finding a solution using Compose to replace Toasts. This solution works well but did make me spend way more than 8 hours on this task.

I am not worrying about the fact that I spend a lot more time than expected this sprint, because it had a lot to do with catching-up with Jetpack Compose!

Tamara

I implemented the player profile. In his profile, the player can:

  • Change his/her nickname
  • Change his/her bio
  • See his/her trophies won
  • See his/her stats

The only difficulty I encountered was to launch the app at the very beginning, I never managed to run the app on the emulator, it just puts me in a timeout every time when everything was working before the sprint.

Jad

I implemented a map activity backed by Open Street Maps using osmdroid. I added an overlay for the EPFL campus map on top of it. Both tasks took a bit less time than expected. Overall no major difficulties were encountered this sprint.


Sprint 2 (18/03 - 31/03)

Tamara

I improved the player's profile page and made the graphic chart. I had more things planned in my sprint, but I noticed that I misjudged the time I needed to do my features and that the graphic chart was added along the way. There are several reasons why I took longer than I estimated:

  • I encountered bugs that were hard to fix on small details and maybe I shouldn't have spent so much time fixing them because the bug didn't drastically change the GUI either.
  • I spent too much time on the aesthetics of small details (like for example so that the drop shadow is centered I designed my own modifier, etc).
  • I spent too much time on dealing with some edge cases.
  • I didn't count the time to write my tests.
  • I'm adding features as I go along.

I think my main difficulty this sprint was dealing with my perfectionism and attention to detail. I need to refocus more afterwards and concentrate on the main features first.

victor (vrooomer)

During this sprint I improved the overall menu, the user can now easily navigate between all the menu screens, i.e change profile, modify the music as wanted, watching the rules, joining the game.

The biggest task was to find a way to "roll back" to the calling activity. For example, finding a way to return to WelcomeActivity thanks to the top bar in SettingsActivity. So I tried a lot of different techniques but at the end I just used to wonderful notion of Activity stack, so now instead of launching activities each time, we just pop the given menu activity!

I'm very proud that I found a way to do it in a clean and modularized fashion. Now, we only need to call a simple function with no arguments to spawn a row or a column of buttons in any activity :)

Maxime (Kaz-ookid)

During this sprint I added a feature in the joinGameLobbyActivity that enables to show the currently joinable and public lobbies in the DB, that are waiting for players to join. The list refreshes every 5 seconds and shows the lobbies name, details, connected players and a button to join them. It was fun searching a way to link the lobbies in the DB to the active list display, and to find a way to create an auto refresh. No big issues, tasks took pretty much the time I declared for it :)!

I had to wait until very late to have the required DB support from (from another task), so even tho I managed to finish implementing the activity using DB queries, I could not make the tests in time. I will put this as a task for myself for next sprint.

Khalil

I worked on refactoring and merging similar tasks into the MapView Activity. We now do not need to handle current position using 2 different ways (Android API and OSM API), which used to require redundant permission checks and requests. I then worked on implementing the LocalizationRepository and MapInfoView classes which are basically used for the MapActivity to store data used for generating the view. This all means that:

  • we now have positions pinned on the map, corresponding to a few known IC buildings,
  • these localizations belong to a Zone, a set of localizations that share the same colour, to be used by the game,
  • We also now can click on a pin, which shows an infoview pop-up window, which can either be closed or used to load a betting screen, in which we are to input a certain amount of money to bet on the price of the building.

All in all, no major issues or fallbacks, the merging issues were just a little unfortunate, I tried to review and help my scrumMaster as much as I could :c

Jad

I implemented a heads-up display for the map activity. I learned a lot about Jetpack Compose as I hadn't used it yet. It was challenging to modularize the HUD composables in a useful way. The type of information shown on the HUD is not final as it will eventually change as we get into writing the actual game, but at least the main interface is here.

That being said, I feel like my contribution this sprint was lacking, I will try to achieve more the next one. I also currently have trouble giving reviews as it's hard for me to think critically of people's code, but I guess this will improve with time.

Hugo - Jharaxus (Scrum master)

Regarding my personal tasks, I realized a bit too late that the firebase data hierarchy that I had planned wasn't very efficient neither practical so I improved it. I also completely refactored the IRemoteStorage interface to make it more user friendly, while also adding a proper coverage to its implementation RemoteDB. Finally, I added the the support of GameLobby within the database and efficiently refactored RemoteDB at the same time.

This sprint went pretty well in terms of work accomplished, but my time split was way too messy as I mostly worked the evening before the sprint's end due to side projects that I focused more on during the rest of the time. This eventuality prevented me from merging the GameLobby support in main as I faced an unexpected bug while writing its corresponding tests, but this could have been prevented by handling my time better and having a bigger time frame margin before the sprint deadline. I will try to achieve that in the future by splitting better the time I am spending on my studies vs on my side projects and activities.

Finally, as per my scrum master role, I organized 2 meetings at the beginning of the sprint to prepare its beginning (set in stone everyone's task and prepare for the merge conflict and dependencies that will arise) and clearly define the global design of our application (to avoid doing unnecessary UI work). However I didn't organize a new one during the second sprint's week, judging it non-necessary especially considering the tight schedule everyone had. This was a mistake as it would have been a good opportunity to accelerate everyone's contributions and figure out what parts could already be merged. But as I didn't realize that, this lead us to publish our PRs far too late, which I as the scrum master had to mostly review and try to merge in a hurry to try to get a complete product (for that sprint) and use it for the sprint-end's demo presentation. The schedule far too tight therefore prevented me from being able to have the expected working demo, which then negatively influenced our presentation. I thus realized that it was a need to follow more closely everyone's job for the purpose of the sprint well development, and that merging should be made more regularly to keep conflicts and there risks smaller, as well as be processed by each PR's author (which we only partially did until now).

Overall team

We implemented almost all the features associated to the tasks we assigned ourselves during this sprint, and this will let us confidently continue implementing our application in the futur.

However we still had some noticeable gaps between the time we expected for some tasks and the actual time they needed, so we will continue improving that aspect in the following sprints.

Finally, some of the expected code coverage couldn’t be added in this sprint due to a lack of time. This issue is actually symptomatic of the lacking time management that we had and which we will definitely seriously improve starting from now as it also prevented us from successfully merging all PRs in the end and from being able to deliver a fine demo.


Sprint 3 (19/03 - 21/04)

Maxime (Kaz-ookid)

My tasks during this sprint were to:

  • implement user authentication
  • finish JoinGameLobby implementation and tests
  • create an activity that allos to create a new lobby, and manage settings for it.

During this sprint, I only could finish one of those task : implement user authentication . I managed to implement a good enough way to authenticate, but once the test part came in I figured out that mocking FirebaseAuth & else was not that easy, which I spent a lot of time into. I also figured out that my implementation would no be that good after this sprint, i.e. after some important changes from other PR (#82) that would require this this auth feature to be updated. I thus communicated with Hugo (working of #82, quick responses and very valuable help!) to come to the conclusion that I should rebase my branch onto his so that I could implement my feature nicely already. It went well even tho it added consequent extra time to this task.

As I lost a lot of time on the first Task, I preferred to make sure that it was well finished and to let the other tasks for a further sprint, since Auth was a big task, needed for most of upcoming tasks. Also, these undone tasks would need some of the upcoming features from various PRs of this sprint, thus I think it is a good idea to start them once all this is merged :)!

In conclusion, I would add that even though a lot of my tasks were dependent of others, communication was well managed and professional. My part could sadly not be merged due to tests passing in local but not in remote. It is a problem Hugo had as well, that needs to be fixed someway. However since I have spent a huge amount of time on this project for this sprint, after many tries I decided to accept not merging my feature yet, better than finding some bad practice solutions in a hurry. :(

Khalil

As a scrumMaster this week, I focused on making sure the previous week's messy merging resolutions were solved as soon as possible, in order to make sure we could all start from a clean slate. I made sure everyone was aware of their branches and gave a clear status of each task. This took the form of a meeting, following the end of sprint meeting. I then made sure everyone had sufficient tasks, and was are of every dependency related to them.

Once everyone knew what needed to be done, when it needed to be done, everything was smooth sailing on my end. I managed to update the app to show every POI of the game map, as well as some small refactoring here and there as my first task. I then implemented a dice roll action, allowing the playing to roll dice and get assigned 3 locations they can go to. More could have been done, but I was stopped in my tracks in the face of the sheer technical debt of the MapActivity.kt file. 3 issues were therefore opened to allow us to recover from it during the next sprint.

Finally, as the deadlines and the sprint final meeting approached, it was more about problem solving how and when branch merges were to be handled, as well as making sure PRs were getting reviewed in time for the demo.

victor (vrooomer)

During this week I had to work with different people in different parts of the code:

  • With Hugo, for the DB, at the end he managed to implement a solid DB version so I just had to use his code to properly use the DB
  • With Tamara, for the diagram. I created a draft diagram to implement the communication between the players and the game so that we can begin that huge part of the code (network and Game). Tamara then created another version of the diagram which can be found here, even if it is still not done, it is that version that we're gonna use and complete.
  • With Maxime, for the lobby. Sadly I didn't have enough time for that part of the task so we're gonna continue our collaboration at the next sprint.

So overall I contributed to begin the DB communication diagram and worked on the GameLobby. I didn't finish the activity but I created a draft PR, I still need to pull all the changes that are going to be merged to the main branch.

In my version, one can add and get GameLobbies to/from the DB and the activity shows the players that join it in real time thanks to a listener.

Hugo (Jharaxus)

During this week, I first took into account the feedbacks I received regarding the bad encapsulation of the IRemoteDB interface and redesigned it completely. Therefore, I turned it into a generic interface that is agnostic of the data it uses (except for the firebase-specific constraints that are checked in the unit tests).

Then, I proceeded with removing the FakeRemoteDB that was used until now in the app to use the real DB instead. This was time-consuming as I also had to refactor the existing calls that did not leverage the properties of futures.

Moreover, when I could, I tried to enhance through refactoring all the code that I had to touch one way or another while I was at it, in order to improve the overall code quality.

Finally, I modularized some utility behaviors needed across several test classes in the form of the PolyPolyTest class, which should be helpful in the future both to fix some already existing issues and share key test processes.

Tamara

This week, with Victor, we put on paper all the mechanisms that constitute the game. I made a diagram for the database inspired by a diagram on paper by Victor, you can find my diagram here.

Then I implemented in the code the classes and functions that constitute the game. In particular, I implemented the possibility to collect a bonus card, to bet on a location, to finish a game, to allow a player to win or lose money, to get the current rank of the players, and many other such features. All these new classes and functions have been put in the base package, which I have also refractor. The new classes represent new concepts that I have thought about carefully.

Jad

This sprint I worked on a game menu component for the heads-up display of the map activity, that shows the same menu as in the welcome activity. Then I worked on a rankings activity accessible from the welcome activity, that shows a few rankings of the players registered in the database. However I wasn't able to finish it this sprint so this will we brought to the next one.

I also wasn't able to review enough pull requests, as I had trouble finding suggestions to make on the code I'd read from my teammates, I asked some of them for tips on how I could improve on this, and I will focus on it next sprint.


Sprint 4 (22/04 - 05/05)

Maxime (Kaz-ookid)

This sprint worked really well for me. I have set two tasks that both took pretty much the time I planned for it, and had no issues in any way. I managed to get my PRs done and merged in time. I am thankful for the great reviews I've had that made me get a more robust and clean code.

Entering in details, my first task was to fully finish JoinGameLobbyActivity. This meant linking joining lobbies to an actual lobby, using the real current user logged in and writing some meaningful and useful tests. My second task was to create a menu to create games. This activity is linked to the create game button in WelcomeActivity and allows users to chose their game settings, then to create a lobby with these. It also sends them directly in this lobby.

Khalil

During this sprint, my main focus was on refactoring the GameActivity class and linking it to the Game instance. This involved a significant amount of code restructuring and cleaning, as well as improving the overall organization and readability of the class. This step was necessary to ensure a smooth integration of the Game logic into the existing activity.

In addition, I also reworked the GameActivity's UI to provide a more intuitive and user-friendly interface. This involved redesigning the layout, adding new UI elements, and improving the navigation flow within the activity.

Throughout the sprint, I faced some challenges related to managing dependencies between tasks and coordinating with other team members. However, I believe that our communication and collaboration efforts were effective in resolving these issues and ensuring the successful completion of our tasks.

Tamara

I did 4 PRs in total and merged the PRs from the last sprint. My 4 PRs consist of:

  1. Refractor the packages that were too messy
  2. Add a way to connect "as a guest" without requiring wifi
  3. Add a simplified menu for the guest
  4. Add a possibility to visit the map when you are a guest

As scrum master, I also made 3 meetings during the sprint to coordinate the team.

I did not encounter any particular difficulty.

victor (vrooomer)

During this sprint, I did two main things: I finished my dummy GameLobbyActivity so that one can enter the GameActivity from the app. I also did some code fixing as the huge merges that happened at the beginning of the sprint overwrote part of my code.

Then, I had struggle to find the best way to abstract and encapsulate all the DB usages, I ended up with a solution but we still need to figure out if this is the best way.

I'm very proud of us for this sprint, we worked a lot and had good communication/organization, I'm eager to see the final app! :)

Jad (jadtl)

This sprint I've done a few refactoring and I implemented a rankings activity to show the rankings of users for different categories.

This feature took me a lot more time to implement than expected, not because of any particular difficulty, but rather because I underestimated how long it takes to write a modular enough activity from scratch, although I also wrote a custom indicator for the tab row of rankings for a neater transition animation, which I could've avoided to meet the expected time.

Hugo (Jharaxus)

At the beginning of this sprint, I focused on rapidly doing a pr to provide a mock RemoteDB that could be used in testing, as using the real Firebase database lead to flaky tests.

Then, I progressively created a basic game loop by diving my work into 3 successive pr:

  • I first refactored GameLobbyActivity to wait for enough players connected before launching the game
  • Then, I added a circular loader to enhance UI when loading data
  • Finally, I implemented the simplest game logic possible to have a reliable working layer for later sprints, consisting in a game where the goal is simply to go to the last turn

To do that work, I browsed a lot of Android’s documentation to grasp the ModelView pattern that they recommend to implement a MVC model and which I used to refactor GameLobbyActivity and improve GameActivity.

I also discussed at the beginning of the sprint with Victor regarding the flaws of the existing DB, and made a huge review of his PR in order to fianally get to a final version of the DB interface (which is the reason why the pr became draft after that).

Sprint 5 (06/05 - 19/05)

victor (vrooomer)

During this sprint I had to touch to all the files of the project as I did a lot of refactoring. The last sprint I started implementing a better way to interact with the DB thanks to the superclass StorableObject. So with that abstraction, I had to adapt IRemoteStorage and all its usages in all the code (RemoteDB, MockDB and a lot of other classes/test files).

After this huge PR, I had the task to link the user to the DB, meaning that when the user signs in, their account is either retrieved from the DB or created (Now ProfileModifyingActivity effectively modifies the DB).

I also wanted to implement the ability to listen to a whole group of elements (e.g. all lobbies) in a last small PR, but I have a weird bug with Futures so I wasn't to finish that for that sprint :( I'm looking forward for some help to understand that issue.

It's very nice to have a working DB even though it is a bit late for that, I'm eager to see what we'll achieve in the last sprint that is coming :)

~ v:)

Khalil

During this sprint, I had to add the finishing touches to allow for a working game loop in gameActivity. I made an FSM for the playerstate and implemented it throughout the gameactivity interactions, making sure no illegal states were possible. I was able to finish this task quickly, so I had to pick up another task.

I ended up working on the landlord mode initial building assignments. This step was very smooth as there was nothing to do with maps and weird UI elements that do not fit together for testing. All in all was able to clear both tasks efficiently.

Tamara

During the sprint, I worked on my task about trades. I also gave feedback to the coaches and tried to better understand their expectations.

Maxime (Kaz-ookid)

I worked on the game lobby waiting room, where we can see players coming in and out, and where admin can launch the game when ready. This sprint worked well for me. I managed to get all my tasks done, even tho one of my task was given to Khalil. Khalil could finish his tasks early so he offered help, and since my first was looking to take more time than planned, I gave him my small task of distributing buildings in Landlord mode. It fit perfectly the worktime he needed to achieve his goals! I did have some issues with some of the new features that got merged while I was working on my branch, so I had to get help from the authors of the changes to get my branch back to work quickly! I could have done this myself, but It would have cost me a lot of extra time. They did fix these very quickly and I feel like this communication and reaction from them was well performed and usefull.

Overall I am proud of my feature, it looks and works well!

Jad (jadtl)

During this sprint, I implemented the background location service that polls the player's location in landlord mode and taxes them if they are close to a building that is owned by another player. This required learning about how to request permissions, and how services work. I also worked on a refactor of strings into string resources to facilitate localization, which took me much more time than anticipated. This refactor wasn't as important as other features so I should've given other tasks a higher priority.

Hugo (Jharaxus)

During this sprint, I focused on creating the effective game. I first created the game loop by implementing the Final State Machine of the player states currently handled (INIT, ROLLING_DICE, MOVING, INTERACTING, BIDDING). I then added the synchronization between players when some game data change (currently only at the end of turn). While doing so, I spent a lot of time to refactor the business vs UI logics by putting them in separate entities (viewModel vs Activity/Component). This was also needed to completely rely on the playerState FSM for transitions instead of having logic spread across files. While doing that, I went through a lot of troubles to have proper testing: according to the references that I found on the official android documentation, I tested separately the game logic in the view model and the ui logic in the gameActivity (which is an additional reason in favor to the refactoring above), but to prevent flaky test some additional code was needed to inject a coroutine dependency in gameViewModel while preserving the expected behavior, which caused my working time to exceed the expected one a bit. Finally, I gave a hand in Maxime's pr when he had troubles with some of his tests and contributed 2 commits to it.

Overall team (scrum master : Kaz-ookid)

Overall, we did get a lot of work done towards a playable and enjoyable game. We managed to get all disruptive tasks nearly done, but some PR have been worked on way too late and thus could not be reviewed nor merged. This sprint was a mix between well timed and performed PRs, and messy PR that were done in a rush. Most of the late PRs are due to personal issues, such as health and overload of work. This may have not been the best sprint to have these problems, as it was a decisive sprint to get a nice and working game to demo, plus we had some disruptive tasks to get done fast. But nontheless, the team worked well and communication within the sprint was quick, clear and useful.

Sprint 6 (20/05 - 26/05)

Jad (jadtl)

This sprint I cleaned up the game UI and added the missing UI game and player information, and I fixed some bugs I found along the way.

As a scrum master, this sprint planning went smooth although it was not possible to assign all the tasks in our backlog to build a reasonable roadmap time-wise, so we sticked to the most important tasks and left the other ones as optional if we have some more time.

Kha (AmLibra)

This print I took on a few tasks in order to get the finishing touches to the game done.

First I fixed some bugs where the user could reroll the dice infinitely. Then I reworked the dice roll UI in order to better integrate it to the rest of the app.

I then took on the task of updating the map markers appropriately, depending on whether they were owned or their level.

Finally, I added labels to the “going to” and “current location”.

victor (vrooomer)

This next sprint was tough! We needed to add our last features and make sure that everything works together, having only one week forced us to work even harder.

However we managed to finish what we wanted, my contribution was to implement an end screen (as the name says, when the game ends) with a ranking of the players. From this view you will be able to return to the menu (Welcome Activity). Also, when the game ends, the user's stats are updated so now our RankingsActivity will display valid information :)

I had some trouble with my tests though, there were some time outs that I tried to fix but I couldn't fix it so I had to comment the tests sadly, hopefully they only were UI tests that I managed to manually test in the app (and it works, yay!)

This has been a long and very instructive journey, thanks for everything polypoly team!!

~ v:)

Maxime (kaz-ookid)

This sprint I worked on plenty little features:

  • fill in the rules and missing icons
  • disable rounds duration and round number parameters when in Last standing game mode
  • add milestone reward gain (earn money by walking
  • implement a globalized transaction

Everything went well. Most of my work was done in time, and communication with the team helped a lot with finishing the remaining details for our app to be finnaly done. It was really condensed, but I am proud of the work I have done. But the end of the sprint was a rush, I had some obligations on friday that made me finish my very last PR late. It was a real mess and I am ashamed to finish this nicely done sprint in such a bad way. But in the end, our app is finished and beautifull!

This semester has been full of twists and turns and learning. Even if all the sprints weren't perfect, I'm proud of myself and my team. The fact that we had major concerns about our way of managing the scrum and MVP methods allowed me to learn from my mistakes and finally understand exactly what is at stake in a good organization from the start.

Tamara

I merged my PR from last week and it took me a really long time haha, there were a lot of problems from old PR that I fixed by recoding some parts. I also did refractoring and add comments, and just these tasks took me much more than 8 hours so I stopped there.

Hugo (Jharaxus)

I first added the biggest missing feature to have an interesting game loop which was bidding for buildings and giving them at the end of the turn, and I enhanced the UI by adding two notifications for a successful bid and the end of a turn as well.

Then, we figured out that there was a pretty serious bug that completely crashed the App when a Game with buildings owned by some player was pushed to the DB, so I tried to fix that as fast as possible to unlock everyone that relied on this feature for the one they were developing.

When this was done, I found out another pretty annoying bug that prevented the map overlays from updating once created, therefore preventing us from drawing indicators for buildings owned or for their level once the game was running, so I fixed it as well.

Finally, we were still missing a way to lose the game so I added the tax mechanism that occurs when you interact with (through trying to bid on) a building that already belongs to another player. While at it, I also added every turn for each player a random update of one building they own, the goal being to make the game more interesting through that, as well as making visible the custom indicators added by Khalil to show each building's level.

Additionally, following the deep review that I made for Maxime's pr regarding the Transaction concept, I discussed in more details with him regarding how to best integrate it with what was existing and was planned on being added, which then helped me quickly implement the tax mechanism as the logic was modular enough for that.

On a side node, as by the end of the sprint cirrus' long tests duration prevented us from merging separately each of Maxime's, Victor's and mine's works because of a lack of time, we merged everything on my branch which we then submitted in a pr after the first release (done before 23h59) as explained on discord, but the work in it is the sum of our three works and not mine only.