awesominat / stonks Goto Github PK

see #92

tl:dr I originally misspelled _ViewModel and wrote _View (auto completion).

if you were to pass any controller through to the View, you'd need to first create the Interactor, but you can't create the interaction without the presenter, but you can't create the presenter without the View, but you can't create the View without the controller, but you can't ...

I noticed we are still hanging on to the old signup/login feature as we are still saving usernames in views and use cases. we need to get rid of them

Fix the implementation for dashboard view buttons so that they actually switch view properly. Thus, we also need to add the various views models to the attributes and constructor parameters. Finally, we can remove the quit button.,

This component would be responsible for rendering the views, handling user interactions, and ensuring that the UI is in sync with the data from the View Model and the entities.

should be thrown every time the API is called on a non-existent ticker

when a user searches a stock, I think it is very good to show the user how much of the stock they already own.

how to do it:

1. recognize that the user should have a portfolio, Hashmap<String, Double>
2. in the interactor, simply look up the stock's ticker in the user's portfolio
3. add it to the output data
4. if doesn't exist, put 0

for any file that doesn't have Javadoc, we should open PRs with the intention of documenting our code for future clarity.

Create and Implement the Presenter, DashboardState and DashboardOutputBoundary such that the necessary data is relayed to the view (the user's stats and the stocks currently owned).

contents:

1. what is the project about (general description)
2. what problem it attempts to solve
3. some use cases
4. set up instructions
5. picture examples of it working

not all of them should be created at once. PRs created to resolve this issue can tackle one of the contents, not necessarily all. however, the readme is an important part of the project

the dashboard use case should:
on execution, pass the user's:

1. stats such as:

• liquid money (balance)
• total assets (balance + worth of stock)
• days since last top up
• total profit
• aggregate trading volume (sum the amount of money spent buying and amount of money gained when selling)

2. portfolio in the form:

• stock ticker mapping
• info taken from the basic info use case

see #63

currently the file needs methods extracted so it looks cleaner as it doesn't look the best right now, but this is sufficient for purposes of getting the program working

completed by #110
in the PR, you can find the specifications

in a list format, allow the user to get a certain company's information (maybe cap it at 5 stories sorted by newest for now)

a possible design pattern we could implement is to build the CompanyInformation instead of passing all the arguments in at once.

This will allow us to input as many arguments as we want without creating at most 6 constructors.

However, now that our code has been developed further, I see that we don't have a case where we'd pass in less than 6 arguments.

As such, I am willing to close this issue.

Add to DashboardView the two following features:

• table of user stats
• preview of owned stocks in a table of some kind

currently, login was altered to allow one user instead of being completely removed.

as a result of this issue,

1. login / signup will be removed forever
2. a user.json fill will exist in the root directory
3. a parser will read from this json and construct the necessary nested data structures
4. all code will rely on the new structure defined by the DAO using JSON
5. user will incorporate a Builder design strategy to allow for direct building using the parsed data

Allow the user to create a User with their username and password, and save it locally to a file called users.csv

Create the interface to allow for getting, saving, checking if a username exists

Create the skeleton for in memory data access for future tests.

Allow the user to input a username and a password that is cross-checked with the users in users.csv
Usernames are the unique identifier.
After signing up, the user should be transferred to their dashboard view
If the password is incorrect or the username doesn't exist, prompt an error.

Allow the user to input a username and a password to later have an account stored in user.csv
Usernames are the unique identifier.
Default values should be given upon signing up found in the default User constructor / User factory
After signing up, the user should be transferred to the dashboard view

Login is not an essential feature and is too much of a headache.

This use case gives the user the option to reset their balance back to the initial $10,000 given that their current balance is less than $500. If the user has more than $500, then a Fail View should pop up with a message along the line of "You have too much money." If there is a successful reset of the balance, then this should be noted in the user's history.

Performs the following:

1. The ResetBalanceInputData Class should have an input of the user's username. (This is the type the controller wraps the User Input data in)
2. The ResetBalanceInteractor (which implements the ResetBalanceInputBoundary) should have an execute method with an input of the type ResetBalanceInputData.
3. This execute method should have a conditional check which ensures that the user has the appropriate balance in order to perform a balance reset.
4. If it passes the check, the user's balance should be reset.
5. Pass the relevant information to the ResetBalancePresenter

with the current way the data access objects are created, only the user's username and password are saved, so their portfolio, user history, and balance are discarded.

Performs the following functions:

1. The view gathers information about which stock the user wants to sell and how many units. It passes this information to the SellController.
2. The SellController creates a SellInputData object to bundle together this information and pass to an object that implements the SellInputBoundary.
3. The SellInteractor class implemented the SellInputBoundary and handles communication with the API drivers and data access objects. It bundles together the output data in a SellOutputData. It also instantiates an object that implements SellOutputBoundary and passes the output data to it.
4. The SellPresenter implements the SellOutputBoundary, taking the SellOutputData and updating the SellState.

Mimic the approach Gursi took in SellView to handle invalid inputs. Handle error at the View/ViewState level but also pass it down to the controller and the interactor and the input data so that it can be passed out to the prepare fail view.

implement the necessary enterprise business rules by creating the following entities,

enum OrderType
BUY,
SELL,
TOPUP

Transaction:
Public int amountBought
Public int identifier
Public OrderType orderType
Public LocalDate timeBought
Public double priceBought
Public Double priceSold

PricePoint:
Public LocalDate timeStamp
Public Double price

Stock:
Public Double lastSeenPrice
Public List priceHistory
Public String fullName
Public String ticker

TransactionHistory:
Public Stock stock
Public List transactions

User:
private TransactionHistory[] portfolio
Private String username
Private String password
private Hashmap<String, TransactionHistory> history
Private Double balance = 10000.0

any issues that come throughout the project might warrant entities to change to fit the changing specification. but for now, these entities work fine

we currently rely on Mockito to mock the file user data access object.
however, we also want fresh tests that use an in-memory version of the DAO to reduce the complexity of future tests and improve readability

our tests should be comprehensive and test almost every class and have a high coverage.

As indicated in the title, creating use case factories that initialize multiple objects like the Controller, Interactor, State, View Model, Presenter and View will make for easier and quicker testing and a simpler Main.java file when the app is completed.

when buying/selling a stock, take 3% of the users money and give them the number of the stock 97% of their money would've bought/sold.

this class should return placeholder values instead of querying the actual api.

creating tests is a problem using real-time data as the data we're collecting may change at any second, causing prices to sometimes fluctuate and throwing the tests off because of the randomness.

thus, the 'fake' API should return placeholder values when its methods are called and should be injected during testing instead of our current driver.

View names should be lower case, as seen in @gursi26's SellView, where the title is "sell" (lowercase). I believe multiple views may be affected by this.

GitHub artifact to carry over built project and separately run times

a user should be able to view a company's info as per the company info entity in a separate screen.

The buy stock interactor should be able to take info from the client such as their username, the stock ticker they want to buy, and how much they want to buy.

the interactor should check if they have enough money to purchase the stock by querying the api

The interactor should be able to get the user's history, add a BuyTransaction to it, update the balance, and update the portfolio accordingly. finally, it should return a success view

in the dashboard, the user should be able to view basic info on their portfolio in a LIST format such as:

1. what stock they bought
2. how many
3. what's their profit at the moment
4. when was it bought

As of right now, there is no main "operation" that is executed on the dashboard, so there is no button that triggers a DashboardController.execute call.

This is a problem because the SellView grabs owned stocks from the DashboardState, which will not be updated without a DashboardController.execute call.

Proposed solution: Add a refresh button on the Dashboard that refreshes the Dashboard view with latest stock prices (by executing the DashboardController). This should update DashboardState. Also, if the user buys or sells a stock and returns to the Dashboard, they would press the refresh button to see their most recent action reflected on the dashboard.

In progress on https://github.com/awesominat/stonks/tree/implement-sell-view

upon clicking the "View More" in any of the portfolio items in the dashboard, the user can view more detailed information about their stock such as:

1. the price graph for up to the previous month
2. stock name
3. profit
4. how much was it bought for
5. current price

if you have any ideas, write them down here as well

To begin, we need to create an API interface. To adhere to the Dependency Inversion Principle, we put this interface under use_cases.

We then need to implement a Finnhub driver in order to access the Finnhub API. We must implement various entities for the purposes of storing data that we access from the API, such as PricePoint, CompanyInformation, CompanyNews, Stock, etc. The Finnhub driver will get and then store information retrieved from the API, implementing the APIAccessInterface and aggregating the aforementioned entities.

Create the TransactionHistory view which allows the user to view their investment history from the DashboardView.