-
Notifications
You must be signed in to change notification settings - Fork 0
Weekly Meetings
- Introduction reformatting
- The project structure should be called System Structure and the image should be updated.
- How the timeline should be initiated
- Generalize the project's idea instead of specifying functionalities (at this time).
- Route categories:
- System defined.
- Attributed to routes by users.
- Helps to filter searched routes.
- Route predefined duration time:
- 1 hour, half a day, full day.
- How to present the route to the client.
- Search online for (DBMSs) optimized solutions related to geo locations.
- Use user input to filter route searching:
- reduces sample size of returned routes.
- Start by making a walking skeleton (minimalistic version of the system).
- Confirmed except DBMS if a better solution (instead of PostgreSQL) is found.
Too much work for little gain, SQL queries are not as controllable as required which is a disadvantage. JDBI suggested as an alternative.
To be changed. A switch from a 'pure' relational database to hybrid database should occur. PostgreSQL contains documental features: PostgreSQL JSON.
Not necessary to implement it, a simpler form of media should suffice due to the private nature of the API.
Use at will but with caution, maximum 10 per week. Less than that desired.
- Study JDBI and implement the server in a minimalistic to test.
- Improve the
ER Diagramwith the new considerations. - Think of a media form to export the data from the server. Consider always input and output model entities, never expose an entity as is.
Most of the application will not require an internet connection. The routes should be loaded when there is a connection available but must be allowed to be used when offline. The routes should be saved in a persistent fashion (Room). Online mode is only required when searching or saving routes for later usage.
The connection should be handled manually to avoid creation and destruction per database request. Ideally one request to the API requires one connection to handle all the database requests.
A user should be able to create a route just by performing it, without having to indicate route points by hand.
The user should be able to take pictures while on a route and those pictures can appear when checking the route. Saving performed routes necessary?
A route can have points of interest added by hand by the user.
Should be structured in the following way:
- Report of the work already made with links to a detailed version presenting results of the work.
- Analysis of the initial planning. Compare the completed goals with the planned ones.
- Reasons for the deviation from the planned goals if any.
- Replan the goals.
- Risks of the new plan.
To facilitate the creation of the API, a standardized structure will be used, in this case, Siren.
- Database
- Category
- Json
- Serial identifiers
- Authentication
- Communication between Client and Server
- Current development stage
Should be an entity in the database, with an N to N relation with the table Routes. No subtypes required.
Can be string before inserting into the database, provides more control over the exact json.
Can be serial primary keys.
Google authentication (id token). A table with authentications can exist in the database with a 1 to 1 relation with a user.
Retrofit can be used, but type returned from the API(siren or not) should be considered.
Minimalistic versions of search needs to be implemented. Report of the work done.
Next meeting is on the 18th of April at 11.00 a.m.
- Service
- Exception handling
- Command object
- Shared input model
- HTTPS and HTTP
- Exception Handling
- Command object
The handling of exceptions can remain in a controller advice. The exception must be decoupled from the error response. The problem+json type of response should be used in some cases but might not be necessary in others: An internal server error (500) might not need to expose details of the error that occurred, in that case a less detailed response should be built.
When a controller receives an input object (in the request's body) this object should be converted to a different type that is then passed to a service being called by the controller. The service must be responsible for building the domain object from this command object. It can be considered a DTO. Sometimes an input object will not have all the necessary information to build a domain object and as such, this intermediate command should provide enough information to make the conversion appropriately.
The input model of the server and output model of the client application are equal. They could be shared, but with care. Considering factors like deployment of a new API version without the update of the output model of the application (non synchronized updates of the application and API).
To be considered at a later phase of the project.
Next meeting is on the 26th of April at 4.00 p.m.
- Screens (Search, Route Creation, User Profile, Live tracking)
- person searching and profile viewing
- should post return created object?
- should created routes be in /person/routes or /routes/{personId}
- exception fields
- mappers / converters
- Progress Report
- Project Structure
- Progress
- Objectives