Fundamental principles in FB4D and Firebase
This chapter explains the synchronous and asynchronous call types and describes their application.
Most of the interface methods are provided two times, once for synchronous and once for asynchronous calls. While the synchronous calls wait for the REST response and return the answer directly to the caller, the asynchronous calls start a REST request only and return immediately to the caller thread. When later the REST response arrives, a call back function will be started. Asynchronous methods are recommended for calls from the main thread within a GUI application. In modern operating systems like Android or iOS, it is forbidden to start an HTTP request directly in the main thread because the GUI is not responsive until the response arrives. That is why the simpler synchronous methods are limited for usage within background threads and GUI-less services.
On the other hand, all asynchronous methods may only be used from the GUI thread, otherwise the synchronization to the calling thread will not work. The underlying
TThread.Synchronizemethod is expected to work only between the GUI thread and a background thread. In services, threads and in the console application synchronous calls are therefore always to be used.
Asynchronous procedure-methods require always two callback pointers for methods of a class. While the first call back will be used in success case the second callback is for error cases. An additional string parameter, the RequestID, can be used for identifying the answer to a formerly started request. The current version of the library supports only one pending call per method. It is planned to overcome this limitation in a future version of the library.
Synchronous function-methods returns the result from the Firebase either as a JSON object or as an interface to a data class of the FB4D library (e.g. IFirestoreDocuments for queries from the Firestore database). Synchronous methods are named with the extension Synchronous while the default asynchronous methods do not have an extension.
The FB4D library supports both generations of Non-SQL Firebase database.
There are several aspects to consider when making a choice. For simpler structured data that changes frequently (e.g. sensor data) the RealTime Database is more suitable. For more complex data structures with many read accesses and few data changes the Firestore is recommended. Read and write transactions are only supported in the Firestore.
The following graphic shows the application scope of the both database types in relation to classical SQL databases.
This results in the following typical application for the different kind of databases.
For more information about the differences see also the Google Firebase Documentation: Firebase documentation about RT DB vs. Firestore