User request:

"recently discovered your awesome android app! A small q - do you know how to make the voice navigation keep working even if the screen timesout? If I force the screen on it works - but then drains battery quite quickly."

https://twitter.com/sim0nw/status/1273872031864500229

This issue is to track upgrading the osmdroid dependency, which I've started looking at.

There's quite a lot of changes after 4.3, so my thought was to work through iteratively by first upgrading to 5.0.1, resolving issues, and then moving on to 5.1 and 5.2. From experimentation:

Upgrading to 5.0.1

In this version, the main non-backward-compatible change that affects us at compile time appears to be the removal of the org.osmdroid.http package, which was done in this commit. From the commit message, it appears to be a desire to move away from Apache HttpClient towards UrlConnection. I can see more than one option on how to proceed:

1. Continue using Apache HttpClient and implement our own form of the HttpClientFactory classes that have been removed from osmdroid.
2. Migrate our code that makes REST requests to use UrlConnection instead.

From reading around blogs, StackOverflow etc I don't think (1) is the way forward, as it seems that Google is not really supporting Apache HttpClient going forward. Quote from http://android-developers.blogspot.co.uk/2011/09/androids-http-clients.html:

Apache HTTP client has fewer bugs on Eclair and Froyo. It is the best choice for these releases. For Gingerbread and better, HttpURLConnection is the best choice. New applications should use HttpURLConnection; it is where we will be spending our energy going forward.

Since our minSdkVersion is already 14 (Ice Cream Sandwich) it seems to make sense for us to go down the UrlConnection route, but I'd be grateful for opinions from the maintainers. @jezhiggins @mvl22, what are your thoughts on the above - and, indeed, do you have any better ideas?

We occasionally get feedback about this, e.g. the following excerpt from a review:

Would be better if the map rotated with travel direction

A brief search on the internet threw up this page: https://stackoverflow.com/questions/37575522/osmdroid-how-to-rotate-osm-map-as-per-devices-direction which suggests this isn't too infeasible to achieve; bearing in mind we're currently on the latest version of osmdroid it's probably worth having a go.

On a Play Store review, a user has suggested "numbered waymarkers to avoid going the wrong way when routes cross."

Something to be looked into, and considered.

CycleStreets is currently available only in English. It would be great to support other languages.

The following strings files all need localisation:

• https://github.com/cyclestreets/android/blob/master/cyclestreets.vNext/src/main/res/values/strings.xml
• https://github.com/cyclestreets/android/blob/master/libraries/cyclestreets-core/src/main/res/values/strings.xml
• https://github.com/cyclestreets/android/blob/master/libraries/cyclestreets-core/src/main/res/values/arrays.xml
• https://github.com/cyclestreets/android/blob/master/libraries/cyclestreets-fragments/src/main/res/values/strings.xml
• https://github.com/cyclestreets/android/blob/master/libraries/cyclestreets-track/src/main/res/values/strings.xml
• https://github.com/cyclestreets/android/blob/master/libraries/cyclestreets-view/src/main/res/values/strings.xml

For each of the files described in the header comment of this PR, you will need to put a file named the same but placed in a corresponding values-XX directory that you create. XX corresponds to the country code you're translating into.

A couple more details:

• Only the values of XML objects should be translated. The name attributes should not be translated as these are what the app uses to identify the text entry.
• Any entry marked with the XML attribute translatable=false should, as the attribute suggests, not be translated - and in fact must not be included in the localised files at all, otherwise the builds will fail.

Please check for errors locally, by running ./gradlew lint or similar, to ensure that there are no errors before you submit your PR, as this will save everyone from wasted time. If for whatever reason you can't do this, please ensure you check the status of automated build that runs when your PR is raised, and fix any errors promptly.

Would you be able to have a look over this and give me feedback?

Functionally it works, but I still need to test battery life as the other day when using it my battery went dead after less than 40 minutes (I would normally expect an hour in LiveRide). I hope to test pre- and post- versions this week. I know I could use tools but I'd like to do it for real :-)

Also I haven't done the unit tests yet.

Thanks!

Test remaining journey.pdf

I wasn't able to pull in the datetime as a string as implied in the api documentation - I had to make it a long in order to get it to work. I've added a test for datetime in RetrofitApiClientTest.testGetPhotos and got the unit test to work by editing photos.json and adding in the datetime in there. I added the correct datetime in long format for the photo which was being tested on (the last one in photos.json) and a dummy datetime (123) for the others. Let me know if there is a different way to update the photos.json file rather than manually editing it as I have done.

We should do this.

We'll need to decide whether we want open or closed beta testing. (see https://support.google.com/googleplay/android-developer/answer/3131213?hl=en-GB).

I'm finding that when I upload a photo, it'll often be uploaded twice, rather than just once. I think it may be more likely to happen when I'm using mobile data, and the phone thinks there is an error on the upload, so tries again.

If you hit http://www.cyclestreets.net/api/journey.json?key=redacted&plan=leisure&itinerarypoints=0.125325,52.219285&distance=30&reporterrors=1

the error message that comes back is:

{
  "error": "Too short: journeys must be longer than 4 metres. (Your requested journey was  metres)."
}

It looks to me like the server is failing to pass back the requested distance value in this error message.

If accepted, I believe this will finish and close #391.

This makes use of the SVG kindly provided by @si-the-pie, with some theming for enabled/disabled to match what we use in the app.

Seeing as how pictures are worth a thousand words, I've just pasted screenshots running in the emulator, before and after, with and without highlighting. I turned on the lock-screen-on button as well for comparison.

Before

After

Note that we can't make the icon any bigger inside the floating action button (as FABs have a deliberate white boundary around them).

Feedback please @jezhiggins, @mvl22 and others if you care to?

To fix #497 and #515

These images show an example of a journey which has a cycling-then-walking (turn right then turn left) segment pair, followed by a walking-then-cycling (turn left then turn right) segment pair. The segments are kept as 2 segments, but the first of the pair has the combined instruction (e.g. turn right then turn left) and the street of the second segment of the pair (e.g. "Crossing"). The second segment of each pair just has its original instruction.

If the 2 segments are both cycling or both walking then they are melded into one segment as previously.

I've done the same for Bridges (see #497 for fudged example).

I've added tests (SegmentTest) for cycling/walking pairs. The original tests for melding into one segment are still in LiveRideVoiceTest.

I attempted to fix #515 by making the footprints black, but they still don't show, e.g. on left turn. I think a separate ImageView will be needed but I'll leave that for now. In this example the footprints show:

but in this example they don't show on the left turn unless that instruction is selected:

Often when I try and select an item in the Itinerary, the app crashes and the logcat shows similar message to here:

https://stackoverflow.com/questions/54047971/android-8-1-9-0-removeviewview-is-not-supported-in-adapterview

The footprints, which indicate that a segment is a walking segment in the Itinerary, don't show unless a segment is selected, because they are white on a white background. It would be nice to be able to see these even if a segment isn't selected.

Our elevation chart currently looks like the screenshot below. There were a number of brutal 25% segments both in the ascent and descent of the first pass I did this morning, which it might have been nice to know more about beforehand 😆

My idea is to introduce highlighting, something like:

• yellow for >=5%
• orange for >=10%
• red for >=15%
• black for >=20%

I haven't yet dug into examples of the data, but probably, achieving this would involve applying a rolling filter on the distance/elevation data arrays, and requiring something like a minimum of 25m distance averaging any of the above gradients for the colouring to be applied, so we don't have artefacts of data-rounding errors making 2m segments being highlighted.

I think this is the result of an Android change a little while ago - I remember reading about how they were changing Intents etc.

Experienced it yesterday on my Pixel 4a (Android 12) when my brother sent me a link https://cycle.st/j82724336 and it just went into Chrome without giving me the option of Cyclestreets. I had to resort to manually entering the route number instead, which was annoying.