Frontend

Code-Structure

This section descibes the code-structure on the client side of our application. The client side consists mainly of the FAIL and the GUI componenent, therefore we can split our codebase into a package - the FAIL - and our actuall app. This approach has multiple advantages:

• We can split the application logic completely from the GUI, thus forcing both components into a specialized scope, making the codebase less complicated.
• We could reuse the FAIL component in other applications including a webside or deploying the logic on a server which has analytical features.
• The GUI can be developed without the FAIL beeing fully implemented.

FAIL

The FAIL is a dart package named 'cashcompass_hook'. We orientate the file-structure on dart's expected structure (see here).

Class Structure

We orientate the class stucture to the components in our archictecture wiki page. The only difference are the actuall data classes, because they are independent from the components for the most part.

Data Classes

Each dataclass consists of four classes:

1. The actual Data Class This class is the source of all application specific information, or say the data stored in the database. For example an transaction constists of two accounts an amount an label and other attributes. These information can be accessed via this class and the methods.

2. Builder Classes The builder class is responsible for creating new data-objects or deserializing it from a data storage (local or remote). The builder class is responseable for embedding objects into the data_manager correctly. Correctly means, that for relations in the database, only ids are stored - thus preventing us to link actual objects in these classes instead of storing just ids without a second step. This also applies to the relation between transactions and accounts. Because we store references to accounts in a transaction object, the account must exist before the transaction object. This is solved by using a logic of a "two step initialization".

3. Serializer Classes Serializer classes are quiet simple. They are the couterpart to the builder class by serializing objects to a Map, which can be used for writing it into a file or sth. These serializer classes are used by the local storage or the remote storage components.

4. Updater The updater classes are empty for now and are not planned to be used in the near future, because we planned to offer interactions with a server or the storage which is beyond simply storing or saving objects.

Currency

For now we've added a typedef which binds double to currency. If we could like to enhance the currency functionalities - or adding currency conversions - we would already have maked every attribute which is used as a amount of some currency.

Connection to the Server

REST classes

All REST-server calls should use the rest_client class. This class wrapps basic REST functions, where for example custom exceptions can be added. The class secured_rest_client is supposed to handle authentication and should extend called functions with given tokens etc.

HTTP-Errors

We can cover a lot of server-side errors etc. via HTTP-error-codes. For catching these, we wrap all requests in an error-handler (ErrorHandler - we should rename this to HTTP-error-handler or sth.). This Errorhandler can be extended for specific calls and expects a response-code and every code which is not this code should throw an error. These errors are defined in the class APIExceptions. More api-exceptions can be added via factory constructors.