When I heard the MIT default CloudDB instance was upgraded, I decided to use it to try out CloudDB's list value handling, and show off my Unicode chess button board.
My test environment for a multi-player multi-device session was MemuPlay's Multi-Memu emulator on Windows 7. I made two different emulators, and loaded built .apk files onto each, both running on my desktop. Here's my test session, recreating the shortest of all chess games, the Fool's Mate ...
In Screen1, I choose a CloudDB tag FoolsMate for my game, and pass it to my second Screen ScrBoard through TinyDB1 tag GAMENAME.
The CloudDB1 component in my second screen scrBoard is set to default:
At scrBoard initialization, the board background is set up, the current game tag is retrieved from TinyDB, and a web request is issued to get the current game from CloudDB.
Each game is kept in CloudDB as a list under the game name tag, i.e. FoolsMate.
Each item in the list is a board status encoded into text using Forsyth-Edwards Notation (FEN).
Incoming CloudDB data drives board updates...
The new board is in the last item of the game board status list.
The load procedure drives the board,
and I show it just to explain the encoding of chat data versus board updates in the downloaded game data list.
Recording the current move is done through a list append to CloudDB:
Recording is mostly invoked from the generic button click event, after updating the screen components and generating a new FEN value:
Overview of all blocks: (open in other tab to see details)
Source:
chess_board_buttons.aia (26.7 KB)
Note that I have not implemented any game rules yet.
The problem I pose here is how to prevent or handle these intermittent problems with CloudDb access.
Could be it be a side effect of my Multi-Memu emulator setup?
Would any one care to compile the .aia and exercise the board with another player using a new game tag?
