I fixed a small typo in the package name.

Here are a couple of questions/issues I think need to be discussed:

• I think PersonManger should be creating people rather than taking Person objects as inputs for the methods. Taking Person as argument delegates the task of creating Person objects to other classes. This may result in violations of clean architecture, i.e. the task of creating Person objects may be delegated to a class that shouldn't know that Person exists.
• For the edit method, maybe we could split it up into different methods. That is, an editFirstName, editLastName, addTags, removeTags, changeDescription methods, or something like that.
• Using a hashmap that maps name to Person object may not be correct. For instance, what would happen if two people have the exact first name, i.e. imagine if we had a person named Jonathan Pace and a person named Jonathan Garvin. How would you store both? (or if we were mapping full names, how would you deal with two people with the exact same first and last names?). There are a couple of solutions to this problem that I came up with:
  • Use a hashMap< String, List< Person>> instead of a hashMap.
  • Use a regular List, i.e. List< Person> instead at the price of constant-time lookup.
  • Create a private static variable in the Person class called id. Each id will correspond with exactly ONE person, i.e. it is unique. Every time we create a new person we increase id by one. This is a cool idea but when enough people have been created the id variable may overflow. I'm not sure how java handles integer overflow but this should be something we consider.

  Feel free to use any ideas you come up with! These are just some tentative ideas that we can play around with.

• I feel like the role of PersonManager is not well defined. Here are some questions that come to mind:
  • Why is PersonManager storing Person objects? Are we using the stored data later? Maybe if we create two different events for a single Person, then we could use the existing Person and have two events reference it, instead of having two different Person objects represent the same person. If so, how should we implement this and what would we need to change? I would assume that we would need to be able to figure out if the Person is already created or not.
  • Should PersonManager be creating Person objects and then return the Person created for other classes to use? If so, we need to consider which classes are going to be using the returned Person classes so we aren't violating clean architecture.
  • Basically, on the implementation level, what do we want the PersonManager to be doing? That is, what do you need PersonManager to implement so that the class you're writing works?

Do you guys have any ideas or suggestions on what we should do?

That is all. Thanks for coming to my TED talk.

I deleted all the classes and files we won't be using anymore. This includes

• all the use cases, their tasks have been delegated to the repos
• all the interface adapters and input output boundaries.
• the anniversary and birthday classes (I think @romanZupancic thought they were redundant and I agree with him)

I also restructured our file structure like this

The ViewModel folder will probably go in the future, and we can put our view models in their respective UI folders.

Tell me if you disagree with any of these changes. These changes are pretty massive.

Added an add event page to the app. Also modified the navigation routes inside of MainScreen.kt to use strings because for some reason using dot notation wasn't working. Currently, the addEvent page adds events to the home screen ViewModels. This will change when we start using the database.

Okay, so I finally found the time to start reworking the design of events within our app.

This whole thing is still pretty bare bones (and there definitely some implementation-level kinks I need to work out), but the general structure is here.

• Basically, we now only have one Event class (event types not yet implemented)
• The behavior of event classes is designated by EventRepeaterStrategys: the idea being that each even repeater strategy contains the algorithm that designates how an even will repeat over time
  • Currently, each implementation of EventRepeaterStrategy subclasses will generate the dates for an event to repeat every time it is called; this might be slow if we're continually calculating on repeat intervals, but there is always an opportunity to implement some kind of adaptive memoization.
• The actual event objects, complete with their repetition strategies, can be requested through EventFactory
  • I'm still debating whether this is a good idea, it seems a little overkill? But otherwise we'd need outside code to interact directly with the Repetition strategies, which could get messy really quickly

I'm marking this as draft because there is still a ~~shit ton~~ bunch of stuff to do:

• First, I need to make sure it builds by updating EventManager and related functions
• I need to work out some kind of event-specific reminder system (could that be another subsystem all on it's own?)
• Then, I need to write some tests
• Then, I need to figure out some kind of interface that will allow us to select the repetition strategy from the front-end
• Probably other stuff

If you think I did bad, yell at me pls.

One point of feedback from our TA was that we weren't properly implementing ISP. This pr seeks to address this as well as ensure that our codebase conforms to DIP.

Additions:

• Interfaces for each of the manager classes were added
• There are multiple interfaces for each manager class, each with specific responsibilities (ISP)
• Hilt doesn't support directly injecting an interface into a constructor, so each interface was given a binding using an abstract class called Binding
• Here's some documentation on hilt interface bindings: https://developer.android.com/training/dependency-injection/hilt-android

Other Changes:

• Modified view models to depend on these new interfaces instead of the manager classes themselves.
• Updated view model documentation to account for these changes

This commit implements the bare-bones required for viewmodels to communicate data between the views and the models.

The goal is to produce a product that builds.

Actually makes these series of classes usable, but most of the event implementation still sucks. I will work on adding #16 in a future pull request, along with any tagging features we want implemented for events.

For this pull request: Do we want to get rid of the event heirarchy altogether, and just use tags instead on a single concrete event class?

I integrated the wrapper class into our views. Our viewmodels now fetch List and display it as a LiveData for the UI to observe. I did a lot of things, replaced/added a lot of code, let me know if you hate anything I did. Idk how good my changes are in terms of architecture, advice is appreciated.

Person and Users and Events are created in the ViewModel right now. Should we move this to the repos and just pass in the values from the viewmodels?

goodnight ✌

this is really big i'm sorry. main things to go over: https://developer.android.com/codelabs/android-room-with-a-view-kotlin#0 https://developer.android.com/codelabs/android-room-with-a-view-kotlin#0 https://developer.android.com/codelabs/android-room-with-a-view-kotlin#0 https://developer.android.com/codelabs/android-room-with-a-view-kotlin#0 ^^^^READ THIS IF YOU'RE TRYING TO WRAP YOUR HEAD AROUND SOME PART OF THIS FOR FRONTEND IMPLEMENTATION. it can probably explain better than me. with that out of the way:

• in theory this should mostly work. if it doesn't let me know.
• i think i deleted dataAccess or something. it was dead to me
• the database is still NOT INSTANTIATED ANYWHERE. we are still flying blind!
• it is far past my bedtime so no tests written yet
• for implementation, please please please do user functionality first since it is simplest and getting it working will pave the way for persons and events
• clean architecture wise, this is what is happening: we have our entities user person event. these are annotated for easy storage in the db.

we have data access use cases for each entity as daos. (data access objects) these connect to their respective repositories which are also use cases but i think they hold onto some data for interface adapters.

then we got viewModels which connect to frontend. how? not entirely sure. some stuff might need tweaking (events in particular atm) but its mostly there.

i hope to all that is holy i never have to make a commit this ungodly ever again. maybe just maybe it will simply work.

Adds BirthdayPresenter class, and InputBoundary and OutputBoundary Interfaces BirthdayPresenter should be class to run program for now. So it will handle "exit" input, not cli.

NEEDED:

• EventManager.view() function
• cli to implement InputBoundary, OutputBoundary

Resolves #5

I used a HashSet to store tags because I think that duplicate tags are redundant. This can be discussed if needed.

The event classes will need to be edited to use this person class.

JUnit needs to be added to path for any tests to be written.

Empty tests have been written as a placeholder for now.

Not sure how the directory will work so I just added the Person class in the main directory. This should be discussed before we implement anything else because we don't want to refactor code.