Ensure Client/Master action hierarchy is consistent

[hwray]

We need to make sure we adopt a consistent approach to whether the client phones wait to receive confirmation from the master before taking a local action. This approach should minimize the chance of Jam desyncing, and secondarily, maximize the speed and responsiveness of the UX.

We're doing things in several different ways right now, depending on the client method and server API endpoint. I'm doing some client/server changes right now, and will document the request/response relationship and when actions are taken for each of the messages we communicate.

[hwray]

• Add Song requests: Client phones send requests to the Master, without taking any local action beforehand or in the Async HTTP callback. Client server takes action when Master responds with the corresponding /addSong broadcast.

[hwray]

• Set Song requests: Client phones send a request to the Master, and actually set the song themselves and pop up with a notification when the AsyncHttpHandler returns onSuccess. The Master server broadcasts the same message to all clients, so the original client is both setting its own song and getting a redundant /setSong request from the Master.

[hwray]

• Move Song requests: For now, the Client actually performs local Jam rearrangement and redisplay before sending a message off to the Master. Otherwise, the drag-and-drop looks terrible: it seems to have no effect at first, and then the song jumps into the correct position a second or so later. This may be causing some syncing issues, which can hopefully be fixed by broadcasting the whole Jam to clients instead of hyper-specific rearrangement requests. For now, the Jam is avoiding rebroadcasting the same /moveSong requests back to the original client, so that will have to change as well.

[hwray]

After refactoring some things today, I think I have a basic idea for how we can balance UI responsiveness with reliable Jam syncing:

• All phones take whatever Jam actions the user performs immediately, regardless of whether they are the Master or a Client. This ensures that the user sees instant UI feedback in response to their adding/moving/removing songs from the Jam, which is crucial.
• To maintain sync, the Master phone just re-broadcasts the entire Jam state as JSON() after every Jam modification request it receives. This way, even if Client phones make an invalid edit to their local version of the Jam before waiting for the Master's response, the desynchronized move can be overwritten on the Client when it re-broadcasts the new shared Jam state.
• The Jam state broadcasts should be time-stamped based on when the original request that provoked the re-broadcast arrived. Client phones should not overwrite their local Jam state if they receive a Jam update post with a time-stamp that is prior to the time-stamp of their last saved update.

[JayThomason]

We should have a quick but thorough testing session so that we can verify that the jams are staying in sync well and then we can close this issue.

[JayThomason]

We have tested the application and have not seen consistency problems recently so I'm closing this.