CODEWITHSUNDEEP
android
Jeeyoung Kim
Jeeyoung Kim

Reputation: 6098

Android - having multiple resource xml files depending on dev environment

I'm currently writing an android app, that interacts with an external server.

I want to make sure that during the development, Android makes connection to a test server instance, but the application should make connection to a production server otherwise.

Currently, URL of the server is stored in one of the xml files - res/values/strings.xml as <string name="server_url">XYZ.example.com</string>.

Right now, I'm just modifying the xml files in local machines depending on my situation.

What is the idiomatic way to handle case like this?

Upvotes: 2

Views: 2434

Answers (1)

gnac
gnac

Reputation: 1643

The XML files are pretty much it. An example would by the mapview api key.

To develop mapview apps you need a key based on your build certificate. Most folks build and test with a debug key and then deploy with a release key. You need to request a different api key for each build key. I keep both map api keys in my resource file, and then comment out the one I don't need when debugging.

An alternative would be to keep two strings in your strings file, and then use some programatic means of selecting which key to use. AdMob uses this type of approach, i.e. if you are testing, you add a test device to the add request. Since you don't want everyone in the world who uses the same phones as you to only see the test adds, you need to wrap the calls in a check for test versus release build. I control this with an integer resource value defined in an xml file. This ends up behaving similarly to a C/C++ DEBUG macro. I still have to change to value of the resource value, but I only have to do that in one place. Alternatively you could use comments to hide the test server: eg

 String server = context.getString(R.string.realserver);
 server        = context.getString(R.string.testserver);  //comment out this line prior to release

I am not a fan of comment/uncomment method because its to easy to forget, especially if you have multiple places where the resource is accessed.

If there is a better way to handle this, I too would be interested.

Upvotes: 1

Related Questions