A good architecture allows better testability and maintability. In this project, code will be as clean as possible and although the architecture may not follow the most academic structure, this one allows this project in the most practical way. As we will see, this architecture allowed me to change the RESTful API without impacting the rest of the App but it also would allow to migrate from this MVI to a MVVM in a smooth maner.

The project Presentation layer (interacting with the UI) is where the Activity, Composables & theme and screens are found).

Composables of the UI get their state updated with every data base observed change at the time that send event to the upper layer to add new stocks to watch to the list. More information about this UI pattern can be found in this article I wrote a few days ago.

The Use Case layer handles the purpose of the project. In our use case we get data from the repository (pattern) -only-, but if for example we wanted to show a notification informing the user that within 50m there is a bank to purchase stocks, we would modify this layer or use case.

In the domain we have our business model and is were the business logic happens. Since we don't have business logic (we read data and display it), our domain layer is almost anectodotic.

The Data layer implemented with a Repository pattern is the one able to decide where to find the information and centralizing data access in one place (the StockRepository class) that persists objects, decoupling the business logic (domain layer) and the data access layers (this one). By using it we are hidding how the data is eventually stored or retrieved to and from the data store (see graph 2 below) which depends on the persisted data model and a remote backend data source.

More over, both are injected to the repository model, meaning that it implements an interface which in turns isolates it from the implementation of our local Data Access Object and the Network Service accessing our RESTful API.

In general terms we could say that each layer depends only on the layer one level below. But because we are using the MVI

Junit Tests are on both ends. One one side on the backend, to test the functionality of the API and on the other, on the Android client, to test that the API works as expected from the mobile App.It is not uncommon that different teams work in different parts of the project and that changes in the backend could "break" the client.

The repository stores backend data to the local database which when observed by the UI through the ViewModel updates the Stockwatcher list and their values. Every time after a user inputs a new stock, this generates and event that goes up to the ViewModel that through the useCase requests it to the repository. If this stock is not in our database (it will not be) this is read from the backend and stored locally. This in turns results in stored LiveData being observed by the UI through the ViewModel (and actually, updating the UI). Other than the user inputing a new value, the app uses the Network service to get it from the backend API and update the values of the stocks in the local database and also being displayed.

One way to continuously update the stocks values has been using a 2000ms fixedRateTimer in the ViewModel that has accessed the repository for each of the stock symbols in our database. Every time a new symbol was entered through the OutlinedTestField (input box), this was stored locally, its value observed as a State from the MainScreen (let's say, the old xml layout set in the content) and this state, beeing a parameter of the UI @Composables, triggereing an update of the UI. In the timer I have used the list of Stocks stored in the model database to get their values from the Remote Data Source (the RESTful API), update the model and let this update propagate again to UI through the observation of the state of the model LiveData as a StateFlow.

Another way to achieve the same has been done launching a suspended function in the viewmodel scope, which has looped forever.

In a coming article I will look at the bytecode of boths solutions using the Compiled Code with the Decompiler.

As expected, reducing the delay and/or the timer duration to a few milliseconds (10ms) resuts in the UI becoming irresponsive, not being able neither to add new stocks to the list neither nor to remove them.

One last thing worth mentioning is the fact that removing stocks from our local database doesn't propagate fast enough to the viewmodel LiveData when we are updating stock values from the backend. In other words, if I remove a stock while I already called the backend to read its new value, this stock will be stored again in the database and its value propagated again to the UI. Some handling had to be done to ensure that a removed stock was not saved again in the local database except of course that the user inputed it again from the UI input dialog.

The stock price has been calculated by addind the ASCII code of each of the symbol characters in module 100. The code belongs to the Google Cloud Function deployed as a RESTful API.

Stock price variation has been calculated using the time in milliseconds to produce a variation of up to +/- 0.5 the original stock price.

A coroutine is a light weight thread, like threads can run in parallel, wait for each other and communicate. They execute in some context. In particular we are refreshing the stock values in the viewModel scope, a scope that will cancel automatically all corroutines runing when the ViewModel would be deleted.

If our tasks are synchronous we have to use Squence and yield(...) a value to the iterator being built and suspend until the next value is requested. In suspend() functions whe have to use Flow instead and emit(..) the result of some processing. Sometimes, if we want our function to return LiveData() to make it easy for observing from the UI we use the liveData{} builder or we can transform the flow with a map transformation and use the extension .asLiveData() to collect Flow values and emit them to the UI.

To return multiple asynchronously computed values we use Kotlin Flows. Creates a cold flow that products a single value from the given functional type. Flows are cold streams similar to sequences - the code inside the builder does not run until the flow is collected with the collect() function (without parameters).

These are extensions for collection transformations. We use them to transform flows() into liveData{}.

At first I created a Free accounts and used both Alpha Vantage API and the Yahoo Finance API but they have many limitations on the free version. A Mocked API created with the Mock API was good to test retrofit but could not be customized to achieve the objectives of this project.