Fix for Discrepancy in CostEstimate model for current android SDK (v1.0.3) (as reported on the lyft developer community forum) #7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR covers a fix for an issue reported early October on the Lyft developer community forum. Here is the link to the issue:
https://devcommunity.lyft.co/t/discrepancy-in-costestimate-model-for-current-android-sdk-v1-0-3/202
The commit that actually has this fix is bcde284.
In addition to the aforementioned fix, I have filled a few more gaps that were in the SDK, for example:
The SDK in general (and in particular, the MockLyftPublicApi) is now aware of 3 additional Lyft Products which I think were added as products since the last time this SDK was updated in February (see commits 7c61fee and bbe009e.):
LYFT_PREMIER
,LYFT_LUX
,LYFT_LUX_SUV
Added several more model types to the SDK for objects received and returned by the API; some of which are polymorphic (See
EtaLocation
which extendsLyftLocation
andLyftDriver
which extendsLyftUser
classes as examples). Other examples of models added include (but are not limited to) to (see commit: 395d14d ):MonetaryAmount
,RideHistory
,RideRequest
,RideRequestResponse
Added
LyftUserApi
and andLyftUserApiRx
, which is distinct from theLyftPublicApi
andLyftPublicApiRx
interface as in it exposes methods that require an access_token from a user -- whereas the LyftPublicApi exposes methods that do not require a user access_token (see commit: 395d14d.). In the same context, I have also modifiedApiConfig
andLyftApiFactory
and abstracted them in such a way that a user can request for a LyftUserApi retrofit client or a LyftPublicApi retrofit client seamlessly. In fact the underlying mechanics that differentiates between a User Api and Public Api retrofit client is the fact thatLyftApiFactory
will create anOkHttpClient
with aRequestInterceptor
that passes either the client token viaapiConfig#getClientToken()
(as is the case with aLyftPublicApi
) or theLyftApiFactory
will create anOkHttpClient
with aRequestInterceptor
that passes either the user access token via:apiConfig#getUserAccessToken()
. For more details see commit: 395d14d:LyftApiFactory.java
: line 27 (for Public Api)LyftApiFactory.java
: line 37 (for Public Api)LyftApiFactory.java
: line 72 (for Public Api)LyftApiFactory.java
: line 78-85 (for User Api)ApiConfig.java
: line 7 (for User Api)ApiConfig.java
: line 27-37 (for User Api)LyftApiFactory.java
: line 43-64 (for User Api)LyftApiFactory.java
: line 78-85 (for User Api)Exposed overloads to the getEtas method in the LyftPublicApi interface. Effectively exposing a way for users of the SDK to make calls to the getEtas end point without the need to pass parameters that are deemed optional by that endpoint. (see commit: 25fd37e.)
Will Love to get your thoughts and feedback.
Awah T-