royil / skycast Goto Github PK

Need to create a view (buttons, panels, etc.) to display/set settings according to user input.

For users to toggle/set based on their preferences.

The use case that allows users to schedule and receive phone notifications about desired weather data for a specified region has not been implemented. This use case is central to the convenience aspect of our design and therefore should be a priority.

• Create use case interactor
• Create use case factory
• Create use case functionality
• Create use case popup view (TBD)
• Create use case popup view model (TBD)
• Create use case popup view State (TBD)

NOTE: TBD means that this may not be needed depending on the implementation

LoggedInView is the main interface of our project and as such is needed to make the project function. We need to create a view that users can interact with in order for them to access the program functionality such as the lookup function being built by @RoyIL.

• Create LoggedInView class
• Update LoggedInViewModel
• Update LoggedInState
• Add Functionality to Main/ViewManager

Need to add data persistence functionality to settings.

The API calls made should faithfully reflect the user's preferences as indicated by their selected settings.

Create a UserFactory that facilitates the dynamic creation of user objects based on provided information. As our application evolves, we anticipate the introduction of various user types, such as administrators, paid users, free users, and more. This factory design pattern proves beneficial in streamlining the instantiation process, ensuring that modifications to the constructor of user classes are centralized within a single location.

• Create UserFactory class and code.
• Move user creation to UserFactory.

This issue cannot be addressed until issue #11 is resolved as this is likely to require testing. The API implementation is what will actually allow Skycast to send notifications to the user's phone.

• add Twilio API call to the Create Notification use case
• add unit cases to test API calling format
• Verify functionality through live build testing

As the title suggests, now that we have decided on a preliminary design, we need to add the ability to look-up a location in accordance with the way the weather API we are using wants the location. In a way, we need to find a way to bridge between the user-inputted location and the way the API wants to receive the location. The look-up functionality will be used in the main "logged-in" view created by @DavisKHuehn.

• Add the ability to look up a location in various ways and formats.
• Find the best way/format to store the location in our DB.
• Add functionality of communicating to the user when a location cannot be found.

Some of our files, especially in the interface adapter package are poorly commented and/or lack javadocs which makes the code harder to work with. It would be beneficial to assembling test builds for all the code to be properly documented.

• Update Documentation in view package
• Update Documentation in use_case package
• Update Documentation in interface_adapter package
• Update Documentation in entity package
• Update Documentation in data_access package
• Update Documentation in app package

We need to add the ability to look-up the weather in a location provided by #3 and using the weather API. In a way, we need to find a way to use the inputted location to retrieve weather statistics such as rain chance, current temperature, and min/max daily temp, etc. The data will be displayed in the main "logged-in" view created by @DavisKHuehn and also through the notification API.

• Add the ability to look up the weather in a location through the API.
• Format weather data and decide on what the output of the UseCaseInteractor should be in accordance with Clean Architecture and SOLID (e.g. how much data should we provide to avoid future unnecessary changes?)