What I learnt
Things I’ve learnt:
DEVELOPMENT - Testing Framework
I have to make sure that I’m doing the following for each module that we are developing:
- Testing API Calls via Postman
- Unit Testing via flutter_test
- Widget Testing via flutter_test
- Integration Testing via integration_test
It would worth spending time to go through a workflow template for each module.
POTENTIAL MODULES - Pipe dream?
Would be useful to determine if these potential modules could work:
- Timesheet - Replacement for Deputy
- Agenda - Let users set up meetings, set agendas, action items, notes, etc.
UPDATED - Working back-to-front or Who’s Layer Is It Anyway?
So yesterday’s post - I thought that layers worked in this way:
- Back-end architecture (database)
- Back-end providers (data fetchers)
- Back-end controllers & API (data source helpers or endpoints)
- Front-end business logic / state or data updaters / handlers (handlers)
- Front-end design / presenation layer
No turns out I’ve been wrong, it’s actually more like this (going from top-most layer first to lowest layer):
- Presentation Layer - Determines how thinks look, and how the user interacts with the app
- Abstraction between Presentation and Logic - Abstractions that define what actions the UI can request but not how they’re executed.
- Logic Layer - It decides what to do based on user input, processes data, and determines what data to fetch or store
- Abstraction between Logic and Data - Abstractions that define what data operations can be performed but not how they are executed.
- Data Access Layer - This is how we interact with information for use in the application
- Abstraction between Data Access and Database - Not needed for us for the App because of Firestore, but often required in traditional set-ups. Same idea, determines what can happen but not how it happens.
- Database - This is where actual storage of the data is kept.
A good way of conceptualising these abstractions is “Need to know basis”. What information does this layer require from the others?