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

Moving main url out of strings.xml #20

Closed
VarunBarad opened this issue Apr 27, 2019 · 4 comments
Closed

Moving main url out of strings.xml #20

VarunBarad opened this issue Apr 27, 2019 · 4 comments
Labels
status: approved issues where contributions are welcome

Comments

@VarunBarad
Copy link
Contributor

Is your feature request related to a problem? Please describe.
The main url for the website (https://dev.to) is stored as a string resource. It currently works because the url is not being used at any place where a string-resource can't be accessed. But later as things are moved over to native code, there will be requirement to use that url where it is not possible to access a string resource.
For example, Retrofit is the most popular networking library and it becomes easier to integrate Retrofit when we don't have the base-url in a string resource.

Describe the solution you'd like
We move the main url of the website to a Constants.kt file in which we store all such urls.

Additional context
The url I am mentioning is located in the linked file: https://github.com/thepracticaldev/DEV-Android/blob/master/app/src/main/res/values/strings.xml

@jeremy-wenzel
Copy link
Contributor

This is a good idea but I think the placement of the url should be elsewhere. I don't foresee it changing but having the url defined in the build.gradle and assigning during the build to be retrieved from the BuildConfig might be a better option. This allows the app to be a little more modular and still defines the url in a constants file that can be retrieved by anyone (android and java code). Just thinking out loud though.

@maestromac
Copy link
Contributor

Thanks for pointing this out @VarunBarad. I agree with @jhw866 : having it assigned at the higher level sounds more impactful.

@VarunBarad
Copy link
Contributor Author

I too agree with @jhw866 and suggest that we define both a BuildConfig (that value will be available in Java/Kotlin code) and a resourceConfig (this value will be available to access in xml resource files).
If everything is fine with this approach then I can make the change and open a PR.

@maestromac maestromac added the status: approved issues where contributions are welcome label May 3, 2019
@triage-new-issues triage-new-issues bot removed the triage label May 3, 2019
@maestromac
Copy link
Contributor

Resolved with #27

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: approved issues where contributions are welcome
Projects
None yet
Development

No branches or pull requests

3 participants