Add an implementation for fetching alternative legs - #4071
Conversation
hannesj
added
!New Feature
|
|
||
| static void writeScheduledTransitLeg(LegReference ref, ObjectOutputStream out) throws IOException { | ||
| if (ref instanceof ScheduledTransitLegReference s) { | ||
| out.writeUTF(s.tripId().toString()); |
There was a problem hiding this comment.
I couldn't immediately understand from the Java documentation how this works. How are the various parts separated from each other? Does ObjectOutputStream do it automatically?
There was a problem hiding this comment.
I find the LegReference concept very interesting since some of my clients would like to have a feature to completely restore an itinerary including realtime updates.
The use case is the following: you buy a ticket for a particular itinerary which is saved on your phone. On the day of the travel you open the app and want to see the exact itinerary that you booked but also want to see the realtime updates for it.
Why am I talking about this? I think for this feature we want to future-proof those references a tiny bit. What to you think about including a version number in the encoded form?
There was a problem hiding this comment.
Yes, ObjectOutputStream is responsible for writing the values to the buffer, the various parts are not separated from each other, but instead it is the responsibility of the implementer to write and read them in the same order.
This feature can support that functionality, at the moment for only scheduled transit leg, but is is possible to create references to other types of legs as well. When we have an implementation for all types, it would be possible to concatenate the legs in order to create a reference to a complete itinerary. Already now, you could store references to all transit legs, and use them to fetch the status of each trip.
The LegReferenceType already has a version in the type name. That way we can have an individual version number for each type of leg.
| tripPattern, | ||
| fromStopPositionInPattern, | ||
| toStopPositionInPattern, | ||
| GregorianCalendar.from(serviceDate.toZonedDateTime(timeZone, boardingTime)), |
There was a problem hiding this comment.
Totally out of scope but want to get your feedback: what do you think about replacing the Calendar type with something from java.time?
There was a problem hiding this comment.
Sounds good. It needs to be done for all Leg types
leonardehrenfried
left a comment
leonardehrenfried
left a comment
There was a problem hiding this comment.
I find this a very interesting feature and am happy to approve it.
If you don't want to give any guarantees about the future-proofing of the serialised form that is fine. I can add when it becomes an actual requirement, which at the moment it is not.
02b1015 to
0f8658a
Compare
0f8658a to
769c934
Compare
| * Enum for different types of LegReferences | ||
| */ | ||
| enum LegReferenceType { | ||
| SCHEDULED_TRANSIT_LEG_V1( |
There was a problem hiding this comment.
V1 = version 1? How will the versioning work here?
There was a problem hiding this comment.
We can have different types of references, and they can have different versions. Eg. we could add FREQUENCY_TRANSIT_LEG_V1 and FLEX_TRANSIT_LEG_V1 now, and if we at a later stage find out we need to adjust the serialization of the flex leg, we can add a FLEX_TRANSIT_LEG_V2, with updated serialization with the missing information.
| boolean searchBackward | ||
| ) { | ||
| TripPattern pattern = patternWithBoardAlightPositions.first; | ||
| int boardingPosition = patternWithBoardAlightPositions.second.first; |
There was a problem hiding this comment.
I know this might change in the future but this .second.first is a bit ambiguous
There was a problem hiding this comment.
I added custom record types for these.
1e503ba
3 participants
Summary
This PR adds an implementation for re-fetching legs, and fetching "alternative legs", i.e. trips which use the same origin/destination station and depart prior/after the current leg.
Unit tests
Module test added for the new functions.
Code style
✅
Documentation
Added documentation to the GraphQL schema.