Closed mislavmatijevic closed 1 year ago
It wouldn't be over-engineering. It sounds like a good idea, however actual planning of the new backend deserves it's own repository, let alone it's own issue. I suggest we close this issue as soon as one of us two finds the time to test the entire app with the new way user data is accessed.
I added many commits, some are unrelated to user object directly and deal with some general issues with the app. My bad.
This PR introduces a lot of code refactoring, making the code much more maintainable.
Previously, many widgets depended on receiving the logged-in user object through their constructors. That got old pretty quickly, but it was hard to fix during rapid app development. The massive size of the first commit of this PR truly shows just how many of these widgets got much cleaner by removing their references to the User class. Another big issue was that the user object was constantly retrieved from secure storage. Since secure storage is a file (or a cookie on web build), a massive amount of reading of a such data source did the speed of the application no favors.
This PR introduces a lot of enhancements in the APIs as well. It's not unexpected, since APIs are most dependent on the user object. I was thinking about putting the logged-in user in the API class via setter (with no public getter) but was quick to change my mind since the logged-in user is needed in the rest of the app (to show "welcome" messages with the user's first name etc.)
Closes #19. Before closing of this PR and the connected issue, I would like an opinion.