Created
March 7, 2017 11:17
-
-
Save vamsipavanmahesh/c8d7d4ed33caf8c19bb4feecbc0908b8 to your computer and use it in GitHub Desktop.
Force updating the app
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Following is the strategy to force update the user. | |
Just like watsapp, how it's forcefully asking the user to update the app or app becomes unusable may be it for security reasons | |
or we want the users to experience new features. | |
There will be api called /settings which will give the version number {version: 1.5} . This is basically the minimum version | |
supported by us | |
Now the frontend Android app, will compare the current version of the app it's running. Suppose 1.6, now that 1.6 is greater than | |
1.5. The app is good to go, and it will function normally. | |
But say, the version number is 1.4. Now 1.4 < 1.5, the app should take the user to a screen saying, please update the app. | |
Is this a good approach? Can anyone suggest me if there are any best practices around it! | |
Thanks |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I would recommend a concept called content negotiation. Do remember HTTP is stateless. Therefor every request should have the same treatment. There is a great debate about API's and versioning. However many of the greatest minds overcomplicate their API. For instance with content negotiation one can default a version to
application/json
. For a version bump there is a spec that allows characters after the;
if used within the content type.Here is an in depth document on the matter. Worth the read even through the comments.
https://www.troyhunt.com/your-api-versioning-is-wrong-which-is
A link to Content Negotiation: https://en.wikipedia.org/wiki/Content_negotiation
And a link to the
Accept
header spec https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1