AbstractHafasProvider: Added the option to also receive trips with ca…

[crazystairs]

…ncelled legs

queryTrips(...) and queryMoreTrips(...) can be called with an additional boolean which if set true keeps the functions from omitting trips where the product does not stop at departure or arrival stops of one or more legs.
This enables users of public-transport-enabler to display every connection as they would appear in the network's own web services. Untravelable trips can be found by checkout for departureCancelled and arrivalCancelled of departureStop and arrivalStop of each trip's legs.

The old behaviour is preserved by having query_Trips(...) with the old signatures call the new functions with query_Trips(..., false).

[schildbach]

This PR seems to add only a property. Does it actually have any effect on parsed data? To me it seems not, or am I wrong?

[crazystairs]

At least with BahnProvider calling query_Trips(..., true) also gives you cancelled trips which you then can (or rather have to) filter and handle differently.
Yes, the commit mostly adds the throwing around of booleans. The interesting part is just this line:
if (realtimeStatus != 2 || includeTripsWithCancelledLegs) // Verbindung fällt aus

[ialokim]

I would be quite interested in such a functionality, but giving it a first try I realized this would result in a breaking-change in the method signature for queryTrips and queryMoreTrips. One option would be to really change the signature and mark the old one as deprecated.

The other (a bit hacky) option would be to include a new OPTION in the NetworkProvider interface which could be set if one wants to query cancelled trips too.

What do you think @schildbach ?

[schildbach]

@ialokim I'm not too concerned with breaking method signatures, as PTE isn't even versioned yet. However, I'm more concerned with the sheer number of parameters of that method. Maybe we should move all "auxillary parameters" into a separate TripOptions class first (in a separate PR)?

[ialokim]

Maybe we should move all "auxillary parameters" into a separate TripOptions class first (in a separate PR)?

Sound reasonable. Do you want me to look into this?

[ialokim]

Maybe we should move all "auxillary parameters" into a separate TripOptions class first (in a separate PR)?

See the PR at #216