Flutter - Finance Overview (Framework)

Table of contents

• Framework
• Version 2
• Offline First
• Conclusion

After the planning of the pages and data has been completed, the first step is to revise the SwH connection framework. This revision should provide a fresh design, but also integrate missing features such as offline support and easier entity handling. We are also converting the development from Provider to GetX.

 

Framework

The first version of the Connection Framework is already being used for the development of the Resource Monitor and the App Planner. The framework provided various functions and data management. Here is a brief overview of the previous functions:

• Management of access to web APIs for apps and web (self-signed certificates)
• Embed login and registration for reuse
• User management model
• Reuse functions
• App configuration
• Different formatters

 

The framework should provide reusable functions that you would need for any app and create a clean connection to the Swh framework on the web. Since we use self-signed certificates for the HTTPS connection, we cannot use the Flutter standard to access the server, but need our own implementation to establish the connection.

 

Version 2

With the latest version of the framework, we want to completely revise some implementations that we noticed as a disadvantage from the last version. Therefore, here are the changes and new features again briefly:

• Changeover to GetX
• Offline first for CRUD requests
• Unit tests

 

A big change is the implementation of the new state management approach via GetX, as the provider package generated too much boilerplate code for us and clean interfaces were not possible in many places. GetX provides us with a better architecture of the app and easier reusability.

The next point we wanted to implement the offline-first strategy, to do this, the CRUD requests had to be rewired against the framework in order to coordinate the correct call sequence for the correct settings and target platform.

So far we have not had any unit tests in the framework that automatically put all functions and components through their paces. In order to be able to guarantee the stability of the framework, we also decided in this step to implement appropriate unit tests after the interfaces were converted and testability was established.

 

Offline First

With this strategy, we want to deliver the missing feature for offline mode. To do this, we have implemented a new class model for access to the various entities. As you can see in the UML diagram, there is an abstract class in the upper part that provides all CRUD operations.

 

The abstract class is modeled as follows, we use our own objects for request and response in order to clearly delimit the data flow:

/// CRUD operations for connection service
abstract class SwhConnectionType {
  /// Get request
  Future<SwhResponse> get(SwhRequest request);

  /// Post request
  Future<SwhResponse> create(SwhRequest request);

  /// Update request
  Future<SwhResponse> update(SwhRequest request);

  /// Delete request
  Future<SwhResponse> delete(SwhRequest request);
}

 

SwhEntity then forwards the corresponding calls against the corresponding implementations, depending on the situation. There are various points to consider:

• Web and PC applications only work online
• In the case of only offline, the online version must not be called
• Hybrid is enough to read in the offline version

 

In addition, a synchronization process must be implemented that synchronizes the data offline and online so that they do not diverge. We will examine this process again in a separate article.

 

Conclusion

The preparations for the actual development already take up a large part of the development time, but above all a stable basis for the development of the actual app is laid. The implementation of the automatic unit tests also contributes to the stability and rapid further development.