-
Notifications
You must be signed in to change notification settings - Fork 117
Split Directions models from the implementation into a separate module #1104
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
Conversation
|
Muse analysis has completed. New issues were detected with line numbers outside of the pull request change set:
|
| * @since 3.0.0 | ||
| */ | ||
| @Nullable | ||
| public abstract List<VoiceInstructions> voiceInstructions(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AutoValueImmutableFields: AutoValue instances should be deeply immutable. Therefore, we recommend returning ImmutableList instead. Read more at http://goo.gl/qWo9sC
|
Muse analysis has completed. New issues were detected with line numbers outside of the pull request change set:
|
ecbd861 to
e8e9506
Compare
| * @since 3.0.0 | ||
| */ | ||
| @Nullable | ||
| public abstract List<VoiceInstructions> voiceInstructions(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AutoValueImmutableFields: AutoValue instances should be deeply immutable. Therefore, we recommend returning ImmutableList instead. Read more at http://goo.gl/qWo9sC
|
Muse analysis has completed. New issues were detected with line numbers outside of the pull request change set:
|
| * @since 3.0.0 | ||
| */ | ||
| @Nullable | ||
| public abstract List<VoiceInstructions> voiceInstructions(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AutoValueImmutableFields: AutoValue instances should be deeply immutable. Therefore, we recommend returning ImmutableList instead. Read more at http://goo.gl/qWo9sC
|
Muse analysis has completed. New issues were detected with line numbers outside of the pull request change set:
|
| * @since 3.0.0 | ||
| */ | ||
| @Nullable | ||
| public abstract List<VoiceInstructions> voiceInstructions(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AutoValueImmutableFields: AutoValue instances should be deeply immutable. Therefore, we recommend returning ImmutableList instead. Read more at http://goo.gl/qWo9sC
|
Muse analysis has completed. New issues were detected with line numbers outside of the pull request change set:
|
…ns models dependencies compile only
…ns models dependencies compile only
| * @since 3.0.0 | ||
| */ | ||
| @Nullable | ||
| public abstract List<VoiceInstructions> voiceInstructions(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AutoValueImmutableFields: AutoValue instances should be deeply immutable. Therefore, we recommend returning ImmutableList instead. Read more at http://goo.gl/qWo9sC
|
Muse analysis has completed. New issues were detected with line numbers outside of the pull request change set:
|
be669f7 to
6cbbe8b
Compare
6cbbe8b to
cc3371c
Compare
|
Muse analysis has completed. New issues were detected with line numbers outside of the pull request change set:
|
| * @since 3.0.0 | ||
| */ | ||
| @Nullable | ||
| public abstract List<VoiceInstructions> voiceInstructions(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AutoValueImmutableFields: AutoValue instances should be deeply immutable. Therefore, we recommend returning ImmutableList instead. Read more at http://goo.gl/qWo9sC
|
Muse analysis has completed. New issues were detected with line numbers outside of the pull request change set:
|
Instead of writing wrappers and mappers internal to Navigation SDK, we could modify
mapbox-javaand split models (likeRouteLegorLegStep) from the implementation (likeMapboxDirectionswhich makes the HTTP requests).Models would be released as one artifact, while the implementation would be another. This way, the whole Nav SDK could reuse the models passed form both onboard and offboard routers while only the
MapboxOffboardRouterwill depend on actual communication details (Retrofit, OkHttp).This approach would simplify the setup by having only one source of directions DTOs while not blocking future modularisation options.
The code in the
mapbox-javarepo does a moderately good job of separating models into separate packages and I think we could make this switch into 2 artifacts seamless, without breaking semver.cc @abhishek1508 @LukasPaczos @korshaknn