Adds separate activity repository and extracts reusable csv code.
Architectural Consistency
Test Written & Running Properly
Foundations for UI State Management with Bloc/Cubit
What's Next
Persistence of progress on activities
Dependency Injection fixes: UseCases, Presenters?
Full move to Bloc/Cubit UI state management
Migrate to Null safety (flutter beta?)
Later
Add more Bingo Cards
Bingo Card selection screen
Continue from most recent card UseCase
Bottom of screen navigation bar
Blog roll
The Feed: aggregation of blog, issued bingo cards & others
About Us page
Scoring display on PlayCard screen
Public scoreboard (submitting and viewing)
By card, by given username/persona
Builtin social media incentives (i.e. sticker next to public score
Improved content & experience for on card activities
Target Tasks
No NULL safety
No extra cards needed yet
[x] Upgraded / switched to flutter beta channel
[x] Re-jig directory structure to fit design goals. Subdirectory names in singular emphasizing borders. No folders under lib/ named after what they contain (i.e. lib/entities/)
[x] Configure Analyzer and Fix (or disable) ALL errors & warnings
[x] ~Change any BLoCs to Cubits, for now~ Simple enough, leave it.
[x] Plug BingoCardBloc into the widget tree, allow to load from navbar to compare with current approach.
Injectors on Main & Tests:
UseCases implementation is injection to the
[x] for Repository/DataSource implementations (used by UseCases)
[x] replace current "Service locator" approach (class of static fields) with true dependency injection
Architecture So Far
These only represent what's needed for Friday to have a working/running app on iOS.
They are ugly and not representing target architecture.
The Strictest pieces are:
BLoC widgets only know about (1) ViewModels (states from BLoCs), (2) BLoC events, (3) other screens/routes, (4) their own subtree of Widgets. Implement directly in the screen widgets.
NO RESTRICTIONS yet on anything between UseCases and BLoC. Keep the BLoC files under lib/usecases/ for now for convenience.
Screens have ViewModels which are returned as BLoCStates by the respective BLoCBuilder Widgets.
BLoCBuilder Widgets have a BLoC it invokes on build and events, child widgets that use the extracted ViewModel.
BLoCs will call a UseCase by handing it a RequestModel and a Presenter as part of an Event which will inject the Presenter with a ResponseModel?
Extra Questions
Should a ViewModel (state) return ID numbers, used for request/responses, as raw integers or convert them to strings as well?
Should each tile on the BingoCardScreen have its own BLoC instance or should each tile get it's data from an aggregate on the BingoCardBLoCState object?
How should the tile grid building be conducted given the raw viewModel data (strings & flags) of the BingoCardBLoCState?
High Points
What's Next
Later
Target Tasks
Injectors on Main & Tests:
Architecture So Far
These only represent what's needed for Friday to have a working/running app on iOS. They are ugly and not representing target architecture. The Strictest pieces are:
lib/usecases/for now for convenience.Screens have ViewModels which are returned as BLoCStates by the respective BLoCBuilder Widgets. BLoCBuilder Widgets have a BLoC it invokes on build and events, child widgets that use the extracted ViewModel. BLoCs will call a UseCase by handing it a RequestModel and a Presenter as part of an Event which will inject the Presenter with a ResponseModel?
Extra Questions