This task is to convert the current logic of storing gameplay history to use a proper database table, instead of the current json structure in SharedPreferences.
(Note: the "current" day's gameState can remain in SharedPrefs; this only applies to game history, which will need to be queried for statistics and archives.)
In order to future-proof the database table somewhat, let's think deliberately about the structure that the table should have:
Table name: DailyGameHistory
| gameName | language | year | month | day | score | playType | gameData |
| Identifier for the game, e.g. whichcamefirst | Language wiki on which this game was played | Year | Month | Day | The score for the game on this day | The "type" of gameplay this row represents. | Additional data for this game, e.g. results for each question; can be a json string |
example:
| whichcamefirst | en | 2025 | 04 | 20 | 4 | 0 | {"true","true","false","true","true"} |
- The score field is technically redundant, since it can be calculated based on the gameData field, but it will be useful and efficient this way for statistics.
- The playType field is a special field that indicates "how" this day's game was played. For example, was this game played on the day that it happened? Or was it played as part of an archived game? This can be an integer enum with values like PLAYED_ON_SAME_DAY=0 and PLAYED_ON_ARCHIVE=1. This will be useful for calculating proper "streaks". If we allow users to play previous days' games, those games should not retroactively increase the streak of the player.