Android application environment configuration [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

开发者_StackOverflow中文版 Improve this question

In my Android application, I need to have different configurations for different environments such as development , UAT , Production.

I have 2 ways to implement it in my mind. Please enlighten me with your opinion.

1). By using 3 different .properties files OR 2). By creating a baseconfig class for shared configuration and extends from 3 configuration classes (I am not sure if it is a good idea)

Both methods will be loaded later into a static config class for easy access.

What are the Pros and Cons of each methods? Are there any other alternatives?

---

I think that best way is to have one active .configuration file, which for example you may store in assets folder. Idea about tree files does not seem to be good, since you need to pack all three .properties files to .apk despite the fact that you don't use two of those three files. Your code always reads same .properties file, and you decide which type of build you do by copying proper .properties file.

In your project, you may create configuration folder, in which you will have all three .properties files ready. Then you create, for example, three ANT tasks, each of them will copy one properties file to assets folder with same destination file name. You may do this also any other way (.bat on Windows, .sh on Linux, you may parametrize ANT task to have one task and property which says which file to pick...).

So, when you want to build production version, run task production, which will copy production .properties file for you. Then you build .apk. Of course, all this can be integrated into complete ANT build process where you may do step of copying .properties file at the beginning of the build procedure.

This way you get optimal size of the APK and always same code to handle .properties file. It is also suitable for automated building environments (Hudson, for example) where you may automate your build target "from outside".