Architecture

General diagram of the FluxC architecture:

In the new architecture we're using Kotlin and coroutines instead of Dispatcher. New calls are now synchronous and defined as suspend. The dispatcher still exists and is used for backward compatibility. It is an event bus that should be used to broadcast events.

Notes:

• WP REST API client is not implemented yet (we have a proof of concept and discovery utils).
• Memory storage is optional, it makes sense to have some data in memory so we don't have to hit the DB everytime we call a Store's getter. The Account Store is currently the only Store using data stored in memory.

The calls to FluxC are now synchronous with the Store being the orchestrator of the flow:

1. App sends synchronous requests to the Store suspended function with an Action as a parameter.
2. Store sends request to the RestClient which synchronously waits for the Response from the API
3. RestClient returns the Fetched Payload object back to the Store
4. Store can send the object to the SqlUtils class to store it in DB
5. Store returns the OnChanged event back to the app.
6. App loads data via previously existing getters

Example:

1. App asks FluxC to FETCH_ACTIVITY_LOG for site X by calling ActivityLogStore::fetchActivities method and suspends the current coroutine.
2. ActivityLogStore calls the ActivityLogRestClient::fetchActivity and awaits result.
3. ActivityLogRestClient calls WPComGsonRequestBuilder::syncGetRequest and awaits result.
4. WPComGsonRequestBuilder builds a get request, adds it to the request queue and transforms callback to a synchronous call using suspendCoroutine.
5. ActivityLogRestClient receives a Response, transforms it into a FetchedActivityLogPayload and returns it to the ActivityLogStore
6. ActivityLogStore receives the payload and stores it into DB using ActivityLogSqlUtils
7. ActivityLogStore returns OnActivityLogFetched object containing the change information back to the app.
8. App loads Activity log using ActivityLogStore::getActivityLogForSite