search

grote / Transportr

Free Public Transport Assistant without Ads or Tracking
https://transportr.app
GNU General Public License v3.0
1.05k stars 189 forks source link

Switzerland: SBB Not work. #768

Closed Mannshoch closed 10 months ago

Mannshoch commented 3 years ago

Describe the bug If I use SBB as provider Transportr do not react on entry any citys.

To Reproduce Steps to reproduce the behavior:

  1. Go to Routeplaning
  2. Enter a city
  3. Nothing happend

Expected behavior Dropdown wit trainstations in Zürich appearr.

Versions (please complete the following information):

SBB API: https://data.sbb.ch/api/v2/console https://data.sbb.ch/api/v1/console

ialokim commented 3 years ago

Thanks for your report, I was able to reproduce the problem. Most probably, SBB changed something on their end so that PTE (the library Transportr uses under the hodd) is unable to access the information. You might consider opening a bug report over there as well.

sirtoobii commented 3 years ago

Hej @Mannshoch (and others) I've implemented timetable.search.ch as a SBB replacement. Are you interested to participate in a beta-test? If yes, please message me at tobias[dot]bossert[at]fastpath[dot]ch, I will then send you an apk of Transportr with the new Provider included

sirtoobii commented 3 years ago

Hej testers! Thank you for your feedback. A new release is available with the following fixes:

You can download the new beta (unofficial!) release here: https://sun.fastpath.ch/index.php/s/PLs3xc8j7nzGm4i

iGormilhit commented 3 years ago

@sirtoobii I tried your unofficial beta, and it works like a charm. Thanks.

grote commented 3 years ago

Note that PTE upstream has SBB removed. If you want it back in Transportr, one would need to reach out to PTE for the reasons and depending on the answer add it back to the PTE staging fork Transportr is using.

sirtoobii commented 3 years ago

The reason was the shutdown of SBB's hafas endpoint (https://github.com/schildbach/public-transport-enabler/issues/381). A merge of https://github.com/schildbach/public-transport-enabler/pull/383 would resolve the issue.

grote commented 3 years ago

Cool, then you could consider submitting it to https://gitlab.com/opentransitmap/public-transport-enabler/ to get it into Transportr quicker.

sirtoobii commented 3 years ago

Violà: https://gitlab.com/opentransitmap/public-transport-enabler/-/merge_requests/7

julianfairfax commented 2 years ago

Cool, then you could consider submitting it to https://gitlab.com/opentransitmap/public-transport-enabler/ to get it into Transportr quicker.

This seems to be the same source GNOME Maps uses, which is https://transport.opendata.ch/. By all means that should be merged then as it works fine with GNOME Maps.

julianfairfax commented 2 years ago

I know there's probably nothing you can do here, but I commented on the linked merge request again, because it should be merged. I hope once it is we'll get support here too

julianfairfax commented 2 years ago

Cool, then you could consider submitting it to https://gitlab.com/opentransitmap/public-transport-enabler/ to get it into Transportr quicker.

https://gitlab.com/opentransitmap/public-transport-enabler/-/merge_requests/7 has been merged. Does this mean we can get this into Transportr now?

ialokim commented 2 years ago

Yes, I'm currently looking into it. Is it a real SBB replacement in the sense that we could keep the old strings and logo or do we need to change them? If yes, please feel free to suggest something. Also: Is it covering whole Switzerland or only parts of it?

julianfairfax commented 2 years ago

Yes, I'm currently looking into it. Is it a real SBB replacement in the sense that we could keep the old strings and logo or do we need to change them? If yes, please feel free to suggest something. Also: Is it covering whole Switzerland or only parts of it?

I would say yes. I don't fully know that that, but it's what GNOME Maps uses and I'm pretty sure it works fine.

sirtoobii commented 2 years ago

Yes, I'm currently looking into it. Is it a real SBB replacement in the sense that we could keep the old strings and logo or do we need to change them? If yes, please feel free to suggest something. Also: Is it covering whole Switzerland or only parts of it?

I would say yes. I don't fully know that that, but it's what GNOME Maps uses and I'm pretty sure it works fine.

Yes, this covers whole Switzerland. Regarding the logo and strings: I think its best if we keep the SBB logo (to avoid user confusion) but maybe use "search.ch" as name. Moreover, I found nothing in this regard in their ToS

Mannshoch commented 2 years ago

The current implementation is able to cover all public transports in switzerland.

julianfairfax commented 2 years ago

Yes, I'm currently looking into it. Is it a real SBB replacement in the sense that we could keep the old strings and logo or do we need to change them? If yes, please feel free to suggest something. Also: Is it covering whole Switzerland or only parts of it?

I would say yes. I don't fully know that that, but it's what GNOME Maps uses and I'm pretty sure it works fine.

Yes, this covers whole Switzerland. Regarding the logo and strings: I think its best if we keep the SBB logo (to avoid user confusion) but maybe use "search.ch" as name. Moreover, I found nothing in this regard in their ToS

Personally I think we should also keep the name. As otherwise the logo and name would be mismatched. And the Swiss won't recognise search.ch

ialokim commented 2 years ago

Okay, so lets keep everything as is for now, that's also easiest :)

ialokim commented 2 years ago

I've tried to add the new provider, but at least on my Android emulator with Android 5.1 (API 22), Transportr crashes when selecting a station with

2022-07-18 01:34:27.782 3686-3776/de.grobox.liberario E/AndroidRuntime: FATAL EXCEPTION: ModernAsyncTask #1
    Process: de.grobox.liberario, PID: 3686
    java.lang.RuntimeException: An error occurred while executing doInBackground()
        at androidx.loader.content.ModernAsyncTask$3.done(ModernAsyncTask.java:164)
        at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:355)
        at java.util.concurrent.FutureTask.setException(FutureTask.java:222)
        at java.util.concurrent.FutureTask.run(FutureTask.java:242)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
        at java.lang.Thread.run(Thread.java:818)
     Caused by: java.lang.NoClassDefFoundError: de.schildbach.pte.-$$Lambda$CHSearchProvider$CANXaoklrIOChA4w5NFUoPkaH78
        at de.schildbach.pte.CHSearchProvider.queryDepartures(CHSearchProvider.java:166)
        at de.grobox.transportr.departures.DeparturesLoader.loadInBackground(DeparturesLoader.java:63)
        at de.grobox.transportr.departures.DeparturesLoader.loadInBackground(DeparturesLoader.java:35)
        at androidx.loader.content.AsyncTaskLoader.onLoadInBackground(AsyncTaskLoader.java:307)
        at androidx.loader.content.AsyncTaskLoader$LoadTask.doInBackground(AsyncTaskLoader.java:60)
        at androidx.loader.content.AsyncTaskLoader$LoadTask.doInBackground(AsyncTaskLoader.java:48)
        at androidx.loader.content.ModernAsyncTask$2.call(ModernAsyncTask.java:141)
        at java.util.concurrent.FutureTask.run(FutureTask.java:237)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587) 
        at java.lang.Thread.run(Thread.java:818) 

Similar things happen when searching for trips. It seems to be connected to the usage of anonymous functions in this provider, for example on the referenced line 166: https://gitlab.com/opentransitmap/public-transport-enabler/-/commit/9fb27a523c5e96a40261a12899aecca439918fbc#a6238f309ec31059e54599ca63e583410d7b57d8_0_166

I was suspecting Proguard to optimize this class away, but looking into the APK within IntelliJ shows the class as present. The same problem happens on both debug and release builds.

I don't have ideas how to solve this issue for now. If someone feels like looking into it, the current version can be found on branch release-2.1.5.

Btw, Android 12 (API 31) works as expected.

ialokim commented 2 years ago

see as reference:

ialokim commented 2 years ago

seems fixed with https://github.com/grote/Transportr/commit/092b6abb3a932344c3db3d31b9a07f98bc953d47

ialokim commented 2 years ago

seems fixed with 092b6ab

@sirtoobii actually after discussing with @grote we would prefer not enabling library desugaring in general since it might lead to other, difficult to diagnose, problems in the long run. Could you perhaps instead try to rewrite some lines of your PTE provider to make it java 6 compatible, basically removing lambda expressions / replacing them by usual for-loops?

sirtoobii commented 2 years ago

Could you perhaps instead try to rewrite some lines of your PTE provider to make it java 6 compatible, basically removing lambda expressions / replacing them by usual for-loops?

Done: https://gitlab.com/opentransitmap/public-transport-enabler/-/merge_requests/10 And here: https://github.com/schildbach/public-transport-enabler/pull/481

Mannshoch commented 2 years ago

For the Record, I found https://github.com/OpendataCH/Transport do jou use this API in Transportr?

sirtoobii commented 2 years ago

For the Record, I found https://github.com/OpendataCH/Transport do jou use this API in Transportr?

This implementation uses the same source as http://transport.opendata.ch/ (in german: https://opendata.ch/news/search-ch-rettet-transport-opendata-ch/#pll_switcher)

julianfairfax commented 2 years ago

Looking forward to seeing this in Transportr

julianfairfax commented 1 year ago

There hasn't been any activity on the GitLab issue for a bit now. What's going on?