Switzerland: SBB Not work.

[Mannshoch]

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):

• Transportr Version: 2.1.2
• Device: Samsung S7
• Android Version: Lineageos 18

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

[ialokim]

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]

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]

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

• We recognize more transportation types now
• The nearby stations feature should work now
• The stationboard-feature should work for every station now
• No more "null" lines

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

[iGormilhit]

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

[grote]

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]

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]

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

[sirtoobii]

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

[julianfairfax]

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]

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]

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]

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]

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]

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]

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

[julianfairfax]

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]

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

[ialokim]

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]

see as reference:

• https://developer.android.com/studio/write/java8-support
• https://stackoverflow.com/questions/35934528/does-java-8-work-on-android-api-24-and-above-or-you-can-use-in-lower-api
• https://stackoverflow.com/questions/67976817/lambda-compatibility-with-android-api-21-24
• https://stackoverflow.com/questions/51188559/how-to-use-lambda-expression-in-android

[ialokim]

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

[ialokim]

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]

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]

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

[sirtoobii]

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]

Looking forward to seeing this in Transportr

[julianfairfax]

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