Technical Implementation: Difference between revisions
No edit summary |
|||
| Line 14: | Line 14: | ||
* All actions are asynchronous | * All actions are asynchronous | ||
* Send all waiting actions (in client) to one server script using a background thread. | * Send all waiting actions (in client) to one server script using a background thread. | ||
** The client application holds a list of actions waiting to be performed (with a generated serial id) | |||
** A json-list with actions | ** A json-list with actions | ||
** All actions have a serial number (unique to user and say 5 min?) and info on what to perform | ** All actions have a serial number (unique to user and say 5 min?) and info on what to perform | ||
** If the action already took place (serial number) just send the updated info (for that action) | ** If the action already took place (serial number) just send the updated info (for that action) | ||
** The server responds with apropriate data on all actions or error messages and also a part with new data (that might have been changed) | ** The server responds with apropriate data on all actions or error messages and also a part with new data (that might have been changed) | ||
** The client updates data and remove confirmed actions from the list of waiting actions | |||
** The client sends a new request with waiting actions (including those who where not confirmed) | |||
* Notification from server if nearby actions take place, the notifications shall contain enough data to update the info in the client (typically attacks) | * Notification from server if nearby actions take place, the notifications shall contain enough data to update the info in the client (typically attacks) | ||
Revision as of 11:37, 27 January 2016
Just some comments to myself:
- Server controls what is on the map (the client shall not assume anything)
Internal actions
- Show Map
- Show Map at pos x,y
- Show Map at nest n
- Help about n (predefined constants in app) - or use the wiki pages?
- Show spieces chat with prepared message/location x,y
etc
Client <-> Server
- All actions are asynchronous
- Send all waiting actions (in client) to one server script using a background thread.
- The client application holds a list of actions waiting to be performed (with a generated serial id)
- A json-list with actions
- All actions have a serial number (unique to user and say 5 min?) and info on what to perform
- If the action already took place (serial number) just send the updated info (for that action)
- The server responds with apropriate data on all actions or error messages and also a part with new data (that might have been changed)
- The client updates data and remove confirmed actions from the list of waiting actions
- The client sends a new request with waiting actions (including those who where not confirmed)
- Notification from server if nearby actions take place, the notifications shall contain enough data to update the info in the client (typically attacks)