This PR is more of a proof of concept for android speech recognition library with JetPack Compose.

Some key features

• Ask for persmission if not already granted by the user to use the mic

• Instanciate SpeechRecognizer (as Intent) and listen for results (event based/callback) when user hit mic icon.

• Use cancellableCourotine to execute start listening with SpeechRecognizer.

This PR uses the work of #201 and introduces some abstractions to simplify testing :

• SpeechFacade is a facade which provides access to the speech recognition facilities.
• SpeechRecognizerFactory is a factory of SpeechRecognizer, which is used by SpeechFacade.

This PR simply adds a navigation section to the list of tournaments screen (which is empty for now) and adds the functions' and classes' initial declarations for the view and view-model of this screen.

This PR able to see the correct pieces position in AR View.

This PR also contains a bit of refactoring of ChessScene . The parameter lifecycleScope is replaced by a CoroutineScope and we use the suspending function to deal with asynchronous model loading.

For the moment, we cannot see if a pawn is promoted, we still see the pawn model.

At the same time, I took the opportunity to fix #258

Closes #245

A bit of technical explanation about the view update :

• When ArChessBoardScreen call update, it passes the new piece position
• Inside the ChessScene when update is called, we save the position in case the all the model aren't loaded and try to move the pieces.
• When we move pieces, we make sure that models are loaded, otherwise give up
• When we finished loading all the model, call moveAllPieces to make sure that all pieces are in the correct position

This PR adds a board model and a pawn on a specified position. I change the model placement mode, the model will be displayed on the taped position. This mode is more user-friendly and remove some strange behaviours.

Some values are hardcoded :

• Chessboard border : This value cannot be computed, we find it by guessing the value
• The position : It's a temporary ChessBoardState.Position value to simulate what we have in the chessboard state

This PR contains also some code used to debug that I don't remove deliberately. It's allow use to display 3D axes, which is kind useful when you don't understand what happen.

Closed #161

Add a component (UI only) that shows a list of players that the user can follow

Bring a small modification on the display card, we have 2 modes that allow us to change the button behavior.

• Play : start a game against the player
• Follow : Add this player in the user following list

Missing :

• Button onClick action (Issues #79)

Close #76 and #77

This PR improves scrolling performance in the list of matches and puzzles for profiles. This is done in two ways :

• the LazyColumn state is no longer read in the composition but rather as a derivedStateOf, reducing and narrowing the scope of recompositions to animate the elevation of the toolbars;
• the matches and puzzles are now keyed, which may help with item re-using.

This PR fixes a problem I encountered while playing some of the provided puzzles.

In some rare cases, the en-passant behaviour could be proposed to pawns in puzzles when they were not located on the right row. This caused a problem for some specific puzzles if there was a piece located right behind the pawn which could be taken en-passant, since multiple Move would then be available for the pawn (both the en-passant, or the take of the piece behind). As a reminder, in case of ambiguous moves which are not promotions, the viewmodel simply drops the user action since it assumes there was an error in the engine.

This patch strengthens the en-passant conditions to make sure the ambiguous cases are not possible anymore, by enforcing that en-passant happens on a specific row, and that the target position of the "taking" pawn is free.

Refactor the AR scene to not destroy the piece's nodes at each update.

In this refactor, we integrate the AR screen with the new delegate introduced in #331

The update function takes the current a list of piece present on the board (from the state) and compare with the local version to update (move, delete, add piece for the promotion) the view.

This refactor produces the same behaviour that what we have in the main branch.

Some line cannot be tested because it required to create a screen, and we still have the bug #213.

This code still have a problem for the future issue #369, for some reason we cannot call smooth which is used to animate the 3D model. (Need more investigation)

Closes #284, Closes #377

In order to simplify the addition of the future DataStore<Preferences> in the TournamentFacade, many tests are migrated to use setContentWithTestEnvironment, which will make adding more dependencies to the facades considerably easier.

This PR is the 1st task of #279. Closes #282

We create a parser that convert a "perfect" voice input into our game engine Action. The input is perfect in the sense that we suppose that the input is well-formed.

Supported command "structure" :

• [rank] [fromPosition] to [toPosition] => To move a piece from FromPosition to toPosition
• [fromPosition] to [toPosition] [rank] => To promote a pawn

I'm not a chess player, so feel free to tell me if the command structure is not natural

Our speech recognition have some flaws and can be improved, here I will list some idea that we have (But still need more research):

• Use a phonetic algorithm
  • Pros :
    • This algo translate a word into phonetic. With this we didn't base on the spelling but how the word is pronounced.
    • "Copy-paste" an existing algorithm, this means that it's quite fast to implement this solution
    • We Can improve this with the Levenshtein distance to find the closest match
  • Cons :
    • This algo is developed for English word, It is hard to internationalized it
• Fine-tuned the existing model
  • Pros :
    • More specific to our problem and context
    • Faster than training a new model from scratch
  • Cons:
    • Time -> need a lot more research to how to fine-tune and use it inside our application
    • Dataset : I don't thing that we have a dataset that correspond our need. We need to create it ourselves
    • We don't know if we can achieve a better result. This kind of model use the context (Previous, next words) to estimate the probability of the current word. Given that our input is very short (4 words), we can say the context is almost inexistent.
    • Internationalization

We don't have THE solution for the moment.

I think it would be better to use the MaterialTheme here (onPrimary is this color)

Originally posted by @matt989253 in https://github.com/epfl-SDP/android/pull/316#discussion_r867839486

Our custom dictionary is a bit poor. This issue is here to allow us to group the missing homophone that we encounter during our development.

A log is put to allow us to capture what the recognizer understands. If your command is not recognizer, feel free to write a comment here, and we will add it in the dictionary.

Please follow this structure when you write your suggestion: [Type] : [wanted word] -> [what the speech recognizer interpret]

• The type can be : Rank, number, alphabet

Example : I say pawn but the recognizer understand "pond"

The report should be : Rank : "pawn" -> "pond"

Pawnies Code review

Hello team ! As promised during our last meeting, we do a small code review of your code base. We were really impressed by the code you were able to produce. It is clean, consistent and uses a lot of new technologies (Jetpack-Compose and Kotlin), this means that we have not much to say.

With your team, we can see that the code review process is really working and makes the code really really good. The small comments we will do mostly concern chess and missing comments but not on the implementation details.

General Remark

Code structure

• The package structure is relatively well organized. We were just wondering if the package mobile.state should be moved in mobile.ui or not.

Code style

• You use a lot of Kotlin features, making the core more readable.
• All the conventions you chose to apply at the start of the project make the code very understanble and consistent. Congratulations for that.
• The classes and functions are well commented.
• You could consider using enum values for the collection and field names instead of hardcoded string (e.g. games, users,whiteId, blackid, ...). By doing this, you avoid magic number(s) and potential mistakes in the code by writing the value again.

By file

Only files for which we have a comment are referenced here.

Package mobile.application.authentication

AuthenticatedUser

• Maybe you can just rename the firestore variable into store to avoid confusion.
• The parameters of the class are not commented.

Package mobile.application.chess

ChessFacade

• You could consider using enum values for the collection instead of hardcoded string (e.g. games, users,whiteId, blackid, ...)
• private data class StoreMatch not commented.

Package mobile.application.chess.engine

Board

• Missing comment for @return parameter on function set. Moreover, you could add a comment explaining that if the piece is null, it is deleted from the broad.

Color

• Missing comment for the function denormalize.

Package mobile.application.chess.engine.rules

Moves

• (Regarding TODO in line 204) Just to remind you, in the castling functions the position that should not be in check are not the same as the one that have to be empty. We advise you to take only the king's direction as an argument, as the rest is either a position known at the start (kingStart) or positions that can be calculated from this direction (empty = all positions where the rook passes, check = all positions where the king passes). For us, this seems better than hardcoded positions.
• We also think that should avoid magic number such as 3 line 239 in the code and use them as constant.

Package mobile.application.chess.engine.implementation

PersistentGame

• Missing comment for some @param of the constructor.

Package mobile.application.social

• In the search method, make sure not to query the database each time a character is entered as this will quickyl make you run out of Firestore resources.

Package mobile.infrastructure.persistence.store

Query

• Missing comment for @return parameter on function limit.

Package mobile.infrastructure.state and mobile.infrastructure.ui

We didn't check in full details how these two packages work since they consist of graphical stuff and it seems that you are more aware about how this works than us.

Tests

Your tests look very good, kudos for that

Conclusion

Your code is very good overall, you have nice abstractions and lots of efforts put in. The documentation and maning are clear and understable, the codestyle is consistent. The app design is very cool. Keep up the good work!