I'm devolping an android app that heavily uses Rest Services.
For developing and debugging, I run the Rest server locally (on my notebook). At home, I have static IP Adresses and therefore, I can put
a static String in my build.gradle.
But if I work from somewhere else, I always have to check my notebook's ip address and edit my build.gradle.
Now I'm curious: Is there a way to insert the current local IP address into my build.gradle automatically?
android {
...
buildTypes {
debug {
...
resValue "string", "host_name", "192.168.0.102" // <--- should be set automatically
}
release {
...
resValue "string", "host_name", "example.com/rest/"
}
}
You can use Groovy methods to find the local IP address:
resValue "string", "host_name", InetAddress.localHost.canonicalHostName
Alternatively you also could use hostAddress instead of canonicalHostName.
I'm adding an awser because I'll probably need this in the future
In build.graddle of the project add into default config the buildConfigField line :
defaultConfig {
applicationId "com.foo.bar"
minSdkVersion 25
targetSdkVersion 25
buildConfigField 'String', 'IP_LOCAL_SERVER', "\"${InetAddress.localHost.hostAddress}\""
}
Then in you code you can call
localIP = BuildConfig.IP_LOCAL_SERVER;
Related
I need to create a mobile app artifact for multiple env. The goal is to promote the same artifact across multiple envs (dev, qa, preprod and prod). The mobile artifact uses a saas url which changes from env to env. Please let me know the best practice to do so.
Currently when the artifact passes qa I create another artifact for pre-prod and finally for prod which is time-consuming and prone to mistakes.
I am thinking of creating an active env url and release version api. What is the best practice?
Thanks,
I think android-flavors will solve your problem.
I look like these examples below.
flavorDimensions "default"
productFlavors{
dev{
applicationId "com.amitgupta.trust_app_android.dev"
}
staging{
applicationId "com.amitgupta.trust_app_android.staging"
}
qa{
applicationId "com.amitgupta.trust_app_android.qa"
}
production{
applicationId "com.amitgupta.trust_app_android.production"
}
}
You make also use different URLs based on Different environment.
flavorDimensions "version"
productFlavors {
QA {
buildConfigField "String", "BASE_URL", '"http://qa.com/api/"'
}
production {
buildConfigField "String", "BASE_URL", '"http://production.com/api/"'
}
}
Please, look at these for its implementation.
https://medium.com/#hsmnzaydn/configuration-product-flavors-and-build-variants-in-android-bb9e54d459af
https://www.journaldev.com/21533/android-build-types-product-flavors
For iOS:
You can make use of Schemes and Build configurations in Xcode. Here's the official documentation: https://developer.apple.com/library/ios/recipes/xcode_help-project_editor/Articles/BasingBuildConfigurationsonConfigurationFiles.html
I hope this will be of any help.
The following is true if you use gradle:
For top level build.gradle, define appId parameter:
allprojects {
ext {
appId = 'com.my.app'
}
}
For app module's build.gradle, define flavors and use the above parameter:
android {
def globalConfig = rootProject.extensions.getByName("ext")
productFlavors {
dev {
applicationId globalConfiguration["appId"] + ".dev"
...
buildConfigField "String", "YOUR_ENDPOINT", "\"https://my.dev.env/\""
}
qa {
applicationId globalConfiguration["appId"] + ".qa"
...
buildConfigField "String", "YOUR_ENDPOINT", "\"https://my.qa.env/\""
}
}
Build app using specific flavor + use BuildConfig.YOUR_ENDPOINT in code.
How do I take an environment variable at build-time and make it available as R.string.api_key at app runtime?
A typical pattern is to put the string in gradle.properties:
API_KEY=whatever-it-is
If you really want it to be a string resource, you can then use resValue in build.gradle:
defaultConfig {
// other stuff here
resValue "string", "api_key", API_KEY
}
(as values in gradle.properties get exposed as global variables to your Gradle script)
Or, if you need the value in Java code, you could use buildConfigField:
defaultConfig {
// other stuff here
buildConfigField "String", "API_KEY", '"'+API_KEY+'"'
}
then reference it as BuildConfig.API_KEY.
And, of course, do not check gradle.properties into version control.
I'd like to have different configurations for debug and release versions. For the most part, By configuration I mean having different string constants,
e.g. connection strings. Additionally I'd like to have a running configuration to be connected to a build configuration, so that when I select 'release' from the running dropdown, the correct version is automatically built. Is that even possible? Is there a way to use a different string resource file based on build configuration?
There is a product flavors functionality available in android studio. You have to add different flavors for your application in the app level build.gradle file. You can set them as follows:
productFlavors {
sandbox {
versionCode 1
versionName "1.0"
applicationId "com.abc.sandbox"
buildConfigField 'String', 'HOST', '"http://api/v1/"'
}
development {
versionCode 1
versionName "1.0"
applicationId "com.abc.development"
buildConfigField 'String', 'HOST', '"http://api/v1/"'
}
production {
versionCode 1
versionName "1.0"
applicationId "com.abc.production"
buildConfigField 'String', 'HOST', '"http://api/v1/"'
}
}
You can run respective flavor by selecting it from build versions before running your application.
You can create a separate strings.xml for debug mode and add your strings to it.
Right click res folder in your projects direcotry -> new -> Android Resource File.
In the new window, Enter filename (strings.xml or any other file you need), select debug in Source Set as shown in image, click OK.
Add your required data here in this new file as,
<string name="same_key_as_in_original">Value</string>
I need your help. I wish to add the build name of my app to the gradle file. The thing is I do NOT want it to be visible to user on the market, so this:
versionName "3.1.0.5486"
does not suits me. But I need it in a way so I can read it via code (In the about screen for example) and increment it each build. How can you advise me?
Just use standard versionCode parameter. You can read it from code using
BuildConfig.VERSION_CODE.
You can set the version code and name inside the defaultConfig element in the build.gradle:
defaultConfig {
versionCode 1
versionName "1.0"
}
And use it as is:
String.format(getString(R.string.some_text_with_int_placeholder), BuildConfig.VERSION_CODE);
If you want create your own variable just use buildConfigField, something like:
buildTypes {
debug {
buildConfigField "int", "FOO", "42"
buildConfigField "String", "FOO_STRING", "\"foo\""
buildConfigField "boolean", "LOG", "true"
}
}
And access it via BuildConfig.FOO
Hi I'm trying to implement android app flavor (free and full) to live wallpaper. In eclipse, I used to use this following code to open live wallpaper preview from my own android Activity:
Intent intent = new Intent();
intent.setAction(WallpaperManager.ACTION_CHANGE_LIVE_WALLPAPER);
String pkg = WallpaperService.class.getPackage()
.getName();
String cls = WallpaperService.class.getCanonicalName();
intent.putExtra(
WallpaperManager.EXTRA_LIVE_WALLPAPER_COMPONENT,
new ComponentName(pkg, cls));
But now it does not work correctly as the free and full flavor are using same package name with just different applicationId in android studio. The problem is when it starts either in free or full version, it will goto full version no matter how, regardless of what flavor it is. I specify app flavor using applicationId in project gradle like this:
productFlavors {
free {
applicationId "com.kkl.app.free"
}
full {
applicationId "com.kkl.app"
}
}
How do we make it to get the correct package name that matches the app flavor?
You can call getPackageName() in your Activity to get Android packageName. This will be packageName from manifest file i.e. the one equal to current applicationId.
Method documentation can be found here.
Fixed by using the following:
intent.setAction(WallpaperManager.ACTION_CHANGE_LIVE_WALLPAPER);
String pkg = getPackageName();
String cls = WallpaperService.class.getCanonicalName();
intent.putExtra(
WallpaperManager.EXTRA_LIVE_WALLPAPER_COMPONENT,
new ComponentName(pkg, cls));
Special thank to Lingviston
You can do a lot with flavors, but what you are trying to do is far simpler than anyone has answered.
First you have a build variant to select your flavor for debugging and running. So use this, otherwise all your debugging will use default main release.
Secondly, you don't have to get package name, just use a build config flag or check flavor. I.E.
android {
signingConfigs {
releaseA35Demo {
storeFile file("$projectDir/../yaskeystore.jks")
storePassword System.getenv('YOUR_APP_STUDIO_STORE_PASSWORD')
keyAlias System.getenv('YOUR_APP_STUDIO_KEY_ALIAS')
keyPassword System.getenv('YOUR_APP_STUDIO_KEY_PASSWORD')
}
}
flavorDimensions 'default'
productFlavors {
a35Demo {
dimension 'default'
applicationId "com.appstudio35.yourappstudio"
buildConfigField "String", "SERVER_URL", '"http://fakeNumbers.compute-1.amazonaws.com:3006"'
buildConfigField "int", "BUSINESS_ID", "1"
versionCode 1
versionName "0.01.01-b1"
minSdkVersion 21
}
a35DemoDev {
dimension 'default'
applicationId "com.appstudio35.yourappstudio.dev"
buildConfigField "String", "SERVER_URL", '"http://fakeNumbers2.compute-1.amazonaws.com:3006"'
buildConfigField "int", "BUSINESS_ID", "2"
versionCode 1
versionName "0.01.01-b1"
minSdkVersion 21
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
productFlavors.a35Demo.signingConfig signingConfigs.releaseA35Demo
productFlavors.a35DemoDev.signingConfig signingConfigs.releaseA35Demo
}
}
}
Then simply reference it in code like:
BuildConfig.BUSINESS_ID
Wherever you need it. Just make sure you don't accidentally use the BuildConfig of a library project when it auto imports the BuildConfig.
Next way is if you want to check your flavor you can simply do
BuildConfig.FLAVOR to see which one you are on. However, keep in mind there are some compiler warnings about using it because you are checking against a flavor and the BuildConfig assumes it will ALWAYS be whatever you are currently in for the Build Variant dropdown, Which is not true, you can ignore this always true or always false warning, I assure you it works.
Lastly your package issue is just because you are debugging the wrong build variant. I'll add an image so you can see where to change that.
Hope that helps.