Adopt new api architecture #475
Conversation
- use distanceFilter to reduce amount of requests that will be send to API - lower precision a bit to reduce battery consumption
- use path components array - add factory funcs for convenience - remove unused request structs
- rename - add post message - add get messages - add get locations - add put location
- fetch messages and locations in parallel on view appearance - on timer tick fetch messages and locations in parallel - fetch nextRide and postlocation in parallel - post location on locationmanager updateLocations event. Since it uses a distanceFilter now there should be less requests made
- update data type to reflect API arch changes - display alert when sending a message fails - remove network check before sending
temporary since I was not happy with them anyways and they grew too big TODO for me to write new test cases that better reflect what needs to be tests and since now we can disable the exhaustivity of the tests we can have more tests with smaller scope
| await send(.fetchLocations) | ||
| } | ||
| group.addTask { | ||
| await send(.fetchChatMessages) |
There was a problem hiding this comment.
just a question to understand how iOS is doing this: the desired outcome is that chat (post and get) and location (get) will only be run on demand, like only when the user opens that part of the app (map or chat window). the only thing that gets called on an interval (30sec) would be the locations put, is that right for that implementation as well?
There was a problem hiding this comment.
ok. the chat message get would be run on a timer tick (12 sec) as well as the getting the locations. The map is kind of open all the time due to the navigation structure we have but I could pause the timer when another view is openend of course.
regarding the chat feature: I can update the behaviour to only fetch messages when the view is open but then we would loose the "unread messages" feature I guess since it wouldn't make a lot sense anymore. But I am not sure if anyone was into that one anyhow 😅
The location put is currently triggered on location updates. If a user moves more then 40 metres the client will send that request.
There was a problem hiding this comment.
pausing once the map view is out of sight sounds like a good idea. there can be another call right after switching back to the map though.
There was a problem hiding this comment.
why would the "unread messages" feature not work anymore? wouldn't that just be a matter of comparing the last shown messages to the ones that we added since then? alternatively there could be a timestamp that saves the last shown message. when there is new content everything with an older timestamp would be considered "new". does that make sense or am i missing the point?
There was a problem hiding this comment.
since we are not getting message updates anymore when the view is not showing there will only be data available the user has already seen. the comparison behaviour from before is very close to what you suggested btw
- only fetch locations when no subview is presented - fetch messages when chat is presented
📝 Docs
📲 What
Update api service to use new endpoints and architecture
🤔 Why
The api needed to be updated and is now using a new architecture.
note
Tests will break after merging this and since I was not happy with the app core test suite I decided there will be an updated one