Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added walking options #991

Merged
merged 12 commits into from
May 10, 2019
Merged

Added walking options #991

merged 12 commits into from
May 10, 2019

Conversation

devotaaabel
Copy link
Contributor

This is currently blocked until testing on staging is complete.

@devotaaabel devotaaabel self-assigned this Apr 10, 2019
@devotaaabel devotaaabel force-pushed the devota-walking-options branch 2 times, most recently from 3cb42c8 to 6fa2fc8 Compare April 10, 2019 16:36
@@ -152,6 +174,12 @@
@Field("waypoints") String waypointIndices,
@Field("waypoint_names") String waypointNames,
@Field("waypoint_targets") String waypointTargets,
@Field("enable_refresh") Boolean enableRefresh
@Field("enable_refresh") Boolean enableRefresh,
@Query("walking_speed") Double walkingSpeed,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noticed that we're using @Query here instead of @Field and wondering if there are any implications 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Guardiola31337 My understanding is that @Field is only used for POST because it's @FormUrlEncoded, but if you think this shouldn't be the case let me know

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Guardiola31337 nevermind I just understood what you were saying. It's interesting because I thought they were supposed to be @Field but the example test passed with @Query... I'll update them anyway

if (walkingOptions() == null) {
walkingOptions(WalkingOptions.builder().build());
} else if (!DirectionsCriteria.PROFILE_WALKING.equals(profile())) {
throw new ServicesException("Walking options are for use with the walking profile");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the backend service return any error in this situation? If so, we should bubble up that error and not thrown an exception at this point.

* @since 4.6.0
*/
@AutoValue
public abstract class WalkingOptions {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we include these options as part of RouteOptions? If so, we should make sure that toJson / fromJson methods are implemented and serialization / deserializations work 👌

@@ -1,4 +1,4 @@
VERSION_NAME=4.5.0-SNAPSHOT
VERSION_NAME=4.6.0-SNAPSHOT
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed this when I was just releasing 4.6.0.
If you rebase this PR to master - you will not need this commit.

@osana osana added this to the v4.7.0 milestone Apr 15, 2019
@devotaaabel devotaaabel force-pushed the devota-walking-options branch 3 times, most recently from 66ecedc to 5b11c99 Compare April 24, 2019 17:58
@osana osana mentioned this pull request Apr 24, 2019
25 tasks
@devotaaabel devotaaabel force-pushed the devota-walking-options branch from f70b8d5 to 87cce2d Compare April 25, 2019 19:58
@osana osana removed this from the v4.7.0 milestone May 2, 2019
@devotaaabel devotaaabel force-pushed the devota-walking-options branch from 2f23f0f to b41ad6a Compare May 9, 2019 17:48
.profile(DirectionsCriteria.PROFILE_WALKING)
.walkingOptions(WalkingOptions.builder().alleyBias(2d).build())
.build();
assertTrue(directions.cloneCall().request().url().toString().contains("alley_bias=2.0"));

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it ok that this test is using a value that is out of bounds? valid values are from -1 to 1

/**
* A factor that modifies the cost when encountering roads or paths that do not allow
* vehicles and are set aside for pedestrian use. Pedestrian routes generally attempt to
* favor using these walkways and sidewalks. The default walkway_factor is 0.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May want to indicate what the range of bias values mean and their effect. Suggest adding something like: The allowed range of values is from -1 to 1, where -1 indicates indicates preference to _avoid_ pedestrian walkways, 1 indicates preference to _favor_ pedestrian walkways, and 0 indicates no preference. Same comment for alleyBias below.

@osana
Copy link
Contributor

osana commented May 9, 2019

@devotaaabel Make sure the @since tags are updated to 4.8.0

Copy link
Contributor

@Guardiola31337 Guardiola31337 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall this looks good @devotaaabel

Left some minor comments to address / discuss before merging here.

}

private Call<DirectionsResponse> post() {
// todo add walking options
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we revert these changes back? It seems walking supports POST too now.


@Nullable
Double walkingSpeed() {
if (hasWalkingOptions()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comment: Guard clauses normally represent the unexpected behavior i.e.

if (!hasWalkingOptions()) {
  return null;
}
return walkingOptions().walkingSpeed();

* @since 4.8.0
*/
@Nullable
public abstract Double walkingSpeed();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't options include the @SerializedName? That’s what the backend expects / generates

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

import static org.junit.Assert.assertEquals;

public class WalkingOptionsTest extends TestUtils {
private static final String JSON = "{\"walkingSpeed\":1.0,\"walkwayBias\":2.0,\"alleyBias\":3.0}";
Copy link
Contributor

@Guardiola31337 Guardiola31337 May 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This JSON isn’t something the backend would return they would return snake_case except for maxHikingDifficulty - wondering if we could ask to services team to make it snake_case too for consistency 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just 👀 that maxHikingDifficulty is not supported anymore and edited ☝️

Copy link
Contributor

@osana osana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be good for alpha. Let's give it a spin.

@devotaaabel devotaaabel merged commit 9d98760 into master May 10, 2019
@devotaaabel devotaaabel deleted the devota-walking-options branch May 10, 2019 01:15
@osana osana mentioned this pull request May 10, 2019
@osana
Copy link
Contributor

osana commented May 10, 2019

@devotaaabel
Thank you for working on this PR.
Can I ask you to add some more description on the functionality this PR adds?
I do not think we have an issue open so there is nothing to refer to either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants