Introduction

It is of greate importance to the user experience that errors between the client and the server and handled smooth and often without user interference. It is also important that communication with the server does not result in an unresponsive application.

Error Handling

Communication

Two types of scenarios

When communicating with the server we basically have two different types of communication.

Retrieving Data

We retrieve data from the server with an argument. The argument might be wrong, the connection may be lost and the returned data might be malformed.

A wrong argument is an error rooted deep in the the sourcecode, so are parsing failures. But lost connectivity or timeouts can be handled.

Sending Data

We update trip information regularly in order to provide a realtime map of moods. We could send malformed data or the connectivity could be lost. Malformed data is due to bad error checking or bad flow control in the source code, and cannot be handled in realtime, but connectivity can.

Different Architectures

The way errors are handled have a lot to due with how the sub system is designed. Due to the layer division between a repository and the technical solutions, which have to due with local or foreigndata, we can handle most technical errors on runtime.

Connectivity issues will result in delays it should be possible for the user to cancel the operation, well adviced about what the problem is, and what the consequences are.

Issues

It is of vital importance to handles the sequence of calls to the server in the right order. Some calls depend on others, some calls can be executed without worries.

For instance when updating a trip on the server with new events, it's important that the local trip which it belongs to, has a foreign id. In a perfect world the internet connectivity wouldn't be a problem and we could always be sure that all communication was stable and reliable, but because of the lack of reliability a situation can occur where a trip has been established, and a call to the server to obtain a foreign id has failed, but an event is still trying to update the trip without a foreign id.

Queues of commands

This architecture was out of scope but would provide a lot of solutions to our problems.

Every time the client wants to send data which is not important for the user experience of the client, the request is added to a database and the commands are handled once the connection to the database is established. It's very important that the commands are placed in the que in the right order, to ensure dependencies.

This implementation requires a separate thread to handle commands and a table in the database to persist commands if the application is forced to close or connectivity is not obtained while the application is active.