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

[Android] Add support for Build Variants to react.gradle #4686

Closed
wants to merge 1 commit into from
Closed

[Android] Add support for Build Variants to react.gradle #4686

wants to merge 1 commit into from

Conversation

AndrewJack
Copy link
Contributor

This PR adds support for Android Gradle Build Variants when generating the JS bundle.

Before: only supported "bundleDebugJsAndAssets" and "bundleReleaseJsAndAssets"

Now: all variants are supported
Examples: "bundleDevDebugJsAndAssets", "bundleStageAlphaJsAndAssets", or "bundleBetaJsAndAssets"

The Gradle script will automatically create bundle tasks for each build variant found in a project.

@facebook-github-bot
Copy link
Contributor

By analyzing the blame information on this pull request, we identified @foghina, @tdzl2003 and @mkonicek to be potential reviewers.

@facebook-github-bot
Copy link
Contributor

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

@facebook-github-bot
Copy link
Contributor

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Dec 9, 2015
@mkonicek
Copy link
Contributor

What is stage alpha?

@AndrewJack
Copy link
Contributor Author

@mkonicek it's an example of a build variant that could be used. "stage" would be the flavor and "alpha" would be the build type.

The script finds all the build variants and creates bundle tasks for them, improves upon the previous hardcoded "bundleDebugJsAndAssets" and "bundleReleaseJsAndAssets" tasks

@mkonicek
Copy link
Contributor

Thanks for the explanation but still need more context. Where would you use the output of bundleStageAlphaJsAndAssets and bundleBetaJsAndAssets? Would you upload them to the Play store?

What's the difference between bundleDevDebugJsAndAssets and bundleDebugJsAndAssets?

@AndrewJack
Copy link
Contributor Author

Where would you use the output of bundleStageAlphaJsAndAssets and bundleBetaJsAndAssets? Would you upload them to the Play store?

A: The output could be used for testing or uploaded to a tool such as hockey app for internal dogfooding

What's the difference between bundleDevDebugJsAndAssets and bundleDebugJsAndAssets?

A: The difference here is the Gradle config. The first uses flavors and build types, and the second only uses build types.

The tasks will perform the same action however the use of build variants are useful for Android developers who are dogfooding and developing an app. I have explained in greater detail below.

Build types only
To dogfood my app I may want to install the release, alpha, and debug version at the same time. On Android I can only install one app with the same applicationId. To overcome this I can change the applicationId per build type using the Android Gradle build variants.

The config would look like this:

android {
  buildTypes {
    debug {
      applicationIdSuffix ".debug"
    }
    alpha {
      applicationIdSuffix ".alpha"
    }
    release {
      ...
    }
  }
}

This will generate the tasks:

  • bundleDebugJsAndAssets
  • bundleAlphaJsAndAssets
  • bundleReleaseJsAndAssets

Flavor + Build types
Flavors add on to this functionality. They can be used for different server environments (dev, stage, prod) or free/pro versions of an app.

I may want to install the alpha app in the stage environment and install the debug app in the stage environment. I can only achieve this with this configuration.

The config would look like this:

android {
  productFlavors {
    dev {
      applicationId = "com.example.dev"
    }
    stage {
      applicationId = "com.example.stage"
    }
    prod {
      applicationId = "com.example"
    }
  }

  buildTypes {
    debug {
      applicationIdSuffix ".debug"
    }
    alpha {
      applicationIdSuffix ".alpha"
    }
    release {
      ...
    }
  }
}

This will generate the tasks:

  • bundleDevDebugJsAndAssets
  • bundleDevAlphaJsAndAssets
  • bundleDevReleaseJsAndAssets
  • bundleStageDebugJsAndAssets
  • bundleStageAlphaJsAndAssets
  • bundleStageReleaseJsAndAssets
  • bundleProdDebugJsAndAssets
  • bundleProdAlphaJsAndAssets
  • bundleProdReleaseJsAndAssets

@@ -18,6 +19,10 @@ apply plugin: "com.android.application"
* // whether to bundle JS and assets in debug mode
* bundleInDebug: false,
*
* // whether to bundle JS and assets in another build variant
* // bundleInStageAlpha: true,
* // bundleInBeta: true,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mkonicek I assume you are referring to this? I could change it to something more generic like bundleIn{variantName}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add a bit more info here, like explaining the properties, and may be a link on how to configure build variants,

e.g. -

// whether to bundle JS and assets in a build variant (if you have build variants configured, see <link>)
// the configuration property is in the format `bundleIn${productFlavor}${buildType`
// bundleInStageAlpha: true,
// bundleInBeta: true,

@facebook-github-bot
Copy link
Contributor

@AndrewJack updated the pull request.

@AndrewJack
Copy link
Contributor Author

Updated react config comments in build.gradle

@mkonicek
Copy link
Contributor

OK thanks for the explanation, get the flavors some. However, I feel like this adds a lot of complexity into the template and the code will have to be maintained. Not everyone might necessarily need these features - no one has been asking about these so far.

Do you think it would make more sense to publish this as a blogpost somewhere and people can easily add it to their build files if needed?

@satya164
Copy link
Contributor

@mkonicek Even if we don't want to merge the build flavours features to the core, I like how the file has been refactored to remove duplicate code. For example the bundleDebugJsAndAssets and bundleReleaseJsAndAssets had almost the same code.

@AndrewJack
Copy link
Contributor Author

Ok, that makes sense, but I agree with @satya164.
Adding the build variants are optional, without adding in extra variants the output is exactly the same as before, but with added flexibility.

@AndrewJack
Copy link
Contributor Author

Maybe a separate React Native Gradle plugin would be useful? That would keep the template simple but allow the plugin to be improved separately.

@facebook-github-bot
Copy link
Contributor

@AndrewJack updated the pull request.

@mkonicek
Copy link
Contributor

mkonicek commented Jan 6, 2016

OK I played around with Gradle variants today and finally understand variants and flavors somewhat.

I like how this removes code duplication, keeps the existing behavior and adds extensibility.

@foghina Are you happy with this being merged?

@@ -18,6 +19,12 @@ apply plugin: "com.android.application"
* // whether to bundle JS and assets in debug mode
* bundleInDebug: false,
*
* // whether to bundle JS and assets in a build variant (if configured).
* // See https://sites.google.com/a/android.com/tools/tech-docs/new-build-system/user-guide#TOC-Build-Variants
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mkonicek
Copy link
Contributor

mkonicek commented Jan 6, 2016

Slightly related PR here: #5160

@AndrewJack
Copy link
Contributor Author

I will make the requested changes today.
When #5160 is merged I'll update to include those changes too.

name: "$bundleJsAndAssetsTaskName",
type: Exec) {
group = "react"
description = "bundle Js And assets for ${targetName}."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: uppercase S, lowercase A ("bundle JS and...")

@foghina
Copy link
Contributor

foghina commented Jan 7, 2016

This is pretty amazing, sorry for taking a long time to review. Thanks for the PR! We should merge #5160 today so you can rebase on top of that and get this merged as well.

@facebook-github-bot
Copy link
Contributor

@AndrewJack updated the pull request.

1 similar comment
@facebook-github-bot
Copy link
Contributor

@AndrewJack updated the pull request.

@facebook-github-bot
Copy link
Contributor

@AndrewJack updated the pull request.

@mkonicek
Copy link
Contributor

mkonicek commented Jan 7, 2016

Thanks for rebasing this so quickly! I see you're making updates, let me know when we should merge :)

@facebook-github-bot
Copy link
Contributor

@AndrewJack updated the pull request.

1 similar comment
@facebook-github-bot
Copy link
Contributor

@AndrewJack updated the pull request.

@AndrewJack
Copy link
Contributor Author

@mkonicek All done, just had to test it.

commandLine "cmd", "/c", "react-native", "bundle", "--platform", "android", "--dev", "true", "--entry-file",
entryFile, "--bundle-output", jsBundleFile, "--assets-dest", resourcesDir
} else {
commandLine "react-native", "bundle", "--platform", "android", "--dev", "true", "--entry-file",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't --dev be false in release build?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How to we want to handle this?

  • Another config value
  • if release then --dev false

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if release then dev false is sensible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

combination of both isn't too hard

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AndrewJack dunno. can't think of a scenario where someone will want production build to have dev warnings. Also if someone does, he can always manually change it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@satya164 I would use it for a tester build, to get more logs out of a build.
Its easy to add if someone needs it, so I will just add the "if release option".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AndrewJack sound good.

@facebook-github-bot
Copy link
Contributor

@AndrewJack updated the pull request.

workingDir reactRoot

// Set up dev mode
def devEnabled = !targetName.toLowerCase().contains("release")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dev mode can be made configurable like this:

def devEnabled = config."devMode${targetName}" ?: !targetName.toLowerCase().contains("release")

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@foghina
Copy link
Contributor

foghina commented Jan 8, 2016

Sick PR!

@facebook-github-bot shipit

@facebook-github-bot
Copy link
Contributor

Thanks for importing. If you are an FB employee go to https://our.intern.facebook.com/intern/opensource/github/pull_request/1655573684725605/int_phab to review.

@ghost ghost closed this in bd7d10e Jan 8, 2016
christopherdro pushed a commit to wildlifela/react-native that referenced this pull request Jan 20, 2016
Summary:
This PR adds support for Android Gradle [Build Variants](https://sites.google.com/a/android.com/tools/tech-docs/new-build-system/user-guide#TOC-Build-Variants) when generating the JS bundle.

**Before**: only supported "bundleDebugJsAndAssets" and "bundleReleaseJsAndAssets"

**Now**: all variants are supported
Examples: "bundleDevDebugJsAndAssets", "bundleStageAlphaJsAndAssets", or "bundleBetaJsAndAssets"

The Gradle script will automatically create bundle tasks for each build variant found in a project.
Closes facebook#4686

Reviewed By: svcscm

Differential Revision: D2815856

Pulled By: foghina

fb-gh-sync-id: 4518de70d178205bc3e5044d2446b56c40298da2
grabbou pushed a commit to react-native-community/cli that referenced this pull request Sep 26, 2018
Summary:
This PR adds support for Android Gradle [Build Variants](https://sites.google.com/a/android.com/tools/tech-docs/new-build-system/user-guide#TOC-Build-Variants) when generating the JS bundle.

**Before**: only supported "bundleDebugJsAndAssets" and "bundleReleaseJsAndAssets"

**Now**: all variants are supported
Examples: "bundleDevDebugJsAndAssets", "bundleStageAlphaJsAndAssets", or "bundleBetaJsAndAssets"

The Gradle script will automatically create bundle tasks for each build variant found in a project.
Closes facebook/react-native#4686

Reviewed By: svcscm

Differential Revision: D2815856

Pulled By: foghina

fb-gh-sync-id: 4518de70d178205bc3e5044d2446b56c40298da2
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants