Add Flixbus provider

[dotlambda]

I'm currently working on adding a provider for Flixbus, a german/european provider of long distance buses, but I'm having some issues that I'd like to discuss before putting any larger effort into it:

• They don't have a public documentation of their API, so the only way one can get information about it is by using mitmproxy to analyze their app or website (an excerpt of network traffic generated by the iOS app can be found here). This poses two problems:
  • I'm not sure if using the API or providing an implementation of an API client would be strictly legal. Their answer to an email stated that a public API is not going to happen ("für uns nicht in Frage kommt").
  • There's no guaranty of API stability or availability, but I guess since they don't want to lose customers stuck with an old version of the app this should be a non-issue.
• There doesn't seem to be a way to search for stations neither by name nor by location. The way the iOS app seems to solve this is by retrieving a list of all stations served and storing it locally. I'm going to investigate if maybe the Android app does this differently but otherwise, we'll have to either retrieve the list and cache it for a certain (relatively large) time or process this list of >1MB in size each time (that seems undoable to me). What's your opinion on this? I know that OkHttp can deal with caching, so somebody using pte could provide the path to the cache directory when instantiating a provider that makes use of it.

I'd be happy if @schildbach and @grote could comment on this :-)

[schildbach]

Hey, that's great!

Almost all of the providers started with reverse engineering, and still do (even though in some cases there is some incomplete but official documentation). Yes, maintaining the provider will continue to take effort.

I am not a lawyer, but my understanding is if the data is published by the public transit authority you (an app) can forward it to the user as long as it doesn't take ownership of the data. Otherwise, web browsers or terminal clients would not be legal.

I take it the number of stops FlixBus serves is tiny, compared to the typical number of train or bus stops. So I think downloading the entire list of stops is a valid approach for now. We currently do not use caching with okhttp, but it would be easy to do I guess.

[dotlambda]

The API doesn't seem to provide line numbers (not even the website does), so would it be ok to make the line argument of the Public constructor nullable? I'm not very proficient in Java, so I don't know what @Nullable does when put in front of an argument or a variable declaration. Is the checkNotNull() function the old way of doing it?

[dotlambda]

If anyone is interested in what I've done so far, you can have a look here.

[schildbach]

For now, just remove the checkNotNull() if its easier for you. @Nullable is just a hint for your IDE to show an error if you potentially pass a null as a not-nullable argument.

We'll will have to decide if we keep it like that or if we just provide dummy line numbers. If we allow null in this field the various apps will need to provide dummy appearances of lines without any number.

[grote]

How about using "FLIX" as a line number for all lines with the flix colors?

[dotlambda]

Flixbus also only supports searching by day, not by time and doesn't support searching by arrival date. Should we add new capabilities for that?

[grote]

How about just ignoring the time and arrival/departure value for now?

[grote]

You could also remove all trips before the specified time manually after receiving the result and only show what is after the time to the user.

[schildbach]

Yeah, just ignore the time for now. For now, I'd also not remove trips from the result. Let's see how it works out, we can optimize later.

[dotlambda]

Since Flixbus operates in multiple countries, a station can have different names depending on which language version you request. The language is choosen via the Accept-Language header. Is there already a provider that is available in multiple languages? Else, what would be the proper way to deal with that? I think since a supplemental header shouldn't hurt any of the other API endpoints, we could simply add an optional argument to the AbstractNetworkProvider that sets the appropriate (standardized) header via httpClient.setHeader(). I'm however not sure what the should be passed to the constructor: something like en-US or more like English (United States).