@appzung/react-native-code-push 9.0.2 → 10.0.0

package/android/app/src/main/java/com/{microsoft → appzung}/codepush/react/CodePushUpdateUtils.java

@@ -1,4 +1,4 @@
-package com.microsoft.codepush.react;
+package com.appzung.codepush.react;
 
 import android.content.Context;
 import android.util.Base64;

package/android/app/src/main/java/com/{microsoft → appzung}/codepush/react/CodePushUtils.java

@@ -1,4 +1,4 @@
-package com.microsoft.codepush.react;
+package com.appzung.codepush.react;
 
 import android.util.Log;
 

package/android/app/src/main/java/com/{microsoft → appzung}/codepush/react/DownloadProgress.java

@@ -1,4 +1,4 @@
-package com.microsoft.codepush.react;
+package com.appzung.codepush.react;
 
 import com.facebook.react.bridge.WritableMap;
 import com.facebook.react.bridge.WritableNativeMap;

package/android/app/src/main/java/com/{microsoft → appzung}/codepush/react/DownloadProgressCallback.java

@@ -1,4 +1,4 @@
-package com.microsoft.codepush.react;
+package com.appzung.codepush.react;
 
 interface DownloadProgressCallback {
     void call(DownloadProgress downloadProgress);

package/android/app/src/main/java/com/{microsoft → appzung}/codepush/react/FileUtils.java

@@ -1,4 +1,4 @@
-package com.microsoft.codepush.react;
+package com.appzung.codepush.react;
 
 import java.io.BufferedInputStream;
 import java.io.BufferedReader;

package/android/app/src/main/java/com/{microsoft → appzung}/codepush/react/ReactInstanceHolder.java

@@ -1,4 +1,4 @@
-package com.microsoft.codepush.react;
+package com.appzung.codepush.react;
 
 import com.facebook.react.ReactInstanceManager;
 

package/android/app/src/main/java/com/{microsoft → appzung}/codepush/react/SettingsManager.java

@@ -1,4 +1,4 @@
-package com.microsoft.codepush.react;
+package com.appzung.codepush.react;
 
 import android.content.Context;
 import android.content.SharedPreferences;

package/android/app/src/main/java/com/{microsoft → appzung}/codepush/react/TLSSocketFactory.java

@@ -1,4 +1,4 @@
-package com.microsoft.codepush.react;
+package com.appzung.codepush.react;
 
 import java.io.IOException;
 import java.net.InetAddress;

package/android/build.gradle

@@ -6,19 +6,9 @@ buildscript {
         mavenCentral()
     }
     dependencies {
-        classpath 'com.android.tools.build:gradle:1.3.0'
+        classpath "com.android.tools.build:gradle:7.2.1"
 
         // NOTE: Do not place your application dependencies here; they belong
         // in the individual module build.gradle files
     }
 }
-
-allprojects {
-    android {
-        namespace "com.microsoft.codepush.react"
-    }
-    repositories {
-        mavenLocal()
-        mavenCentral()
-    }
-}

package/android/codepush.gradle

@@ -69,9 +69,9 @@ gradle.projectsEvaluated {
 
         def nodeModulesPath;
         if (project.hasProperty('nodeModulesPath')) {
-            nodeModulesPath = "${project.nodeModulesPath}/react-native-code-push"
+            nodeModulesPath = "${project.nodeModulesPath}/@appzung/react-native-code-push"
         } else {
-            nodeModulesPath = findNodeModulePath(projectDir, "react-native-code-push")
+            nodeModulesPath = findNodeModulePath(projectDir, "@appzung/react-native-code-push")
         }
 
         def targetName = variant.name.capitalize()
@@ -95,7 +95,7 @@ gradle.projectsEvaluated {
 
             // mitigates Resource and asset merger: Duplicate resources error
             project.delete(files("${jsBundleDir}"))
-            
+
             jsBundleDir.mkdirs()
             resourcesDir.mkdirs()
 

package/android/gradle/wrapper/gradle-wrapper.properties

@@ -1,5 +1,5 @@
 distributionBase=GRADLE_USER_HOME
 distributionPath=wrapper/dists
+distributionUrl=https\://services.gradle.org/distributions/gradle-7.3.3-bin.zip
 zipStoreBase=GRADLE_USER_HOME
 zipStorePath=wrapper/dists
-distributionUrl=https\://services.gradle.org/distributions/gradle-2.4-all.zip

package/android/gradle.properties

@@ -1,20 +1,4 @@
-# Project-wide Gradle settings.
-
-# IDE (e.g. Android Studio) users:
-# Gradle settings configured through the IDE *will override*
-# any settings specified in this file.
-
-# For more details on how to configure your build environment visit
-# http://www.gradle.org/docs/current/userguide/build_environment.html
-
-# Specifies the JVM arguments used for the daemon process.
-# The setting is particularly useful for tweaking memory settings.
-# Default value: -Xmx10248m -XX:MaxPermSize=256m
-# org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
-
-# When configured, Gradle will run in incubating parallel mode.
-# This option should only be used with decoupled projects. More details, visit
-# http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects
-# org.gradle.parallel=true
-
-android.useDeprecatedNdk=true
+CodePush_minSdkVersion=16
+CodePush_targetSdkVersion=31
+CodePush_compileSdkVersion=31
+# CodePush_development=true # enable this when developing on the module outside a React Native app

package/docs/advanced-usage.md

@@ -0,0 +1,56 @@
+## Advanced usage
+
+### Multiple environments
+
+#### Staging / Production
+
+In a real-world scenario you would have `Staging` and `Production` apps that are different binaries, each using specific environment config (different package name, bundle identifier, API, feature flags etc). Create a release channel for each of these environments with `appzung release-channels create` and change the `CodePushReleaseChannelPublicId` on the native side with environment variables. You might want to use a module like [react-native-config](https://github.com/lugg/react-native-config) (or do it manually using build variants and configurations).
+
+```groovy
+// android/app/build.gradle
+android {
+    // ...
+    defaultConfig {
+        // ...
+        resValue 'string', "CodePushReleaseChannelPublicId", project.env.get("CODEPUSH_RELEASE_CHANNEL_PUBLIC_ID_ANDROID")
+    }
+}
+```
+
+```
+// ios/myapp/Info.plist
+
+<key>CodePushReleaseChannelPublicId</key>
+<string>$(CODEPUSH_RELEASE_CHANNEL_PUBLIC_ID_IOS)</string>
+```
+
+#### QA / Production
+
+In the case where you have a `QA` environment that is completely iso-prod (meaning you can swap the JS bundle between those two apps), you may take advantage of the `promote` feature:
+
+1. Release a CodePush update to your `QA` release channel using the `appzung releases deploy-react-native` command (or `appzung releases deploy` if you need more control)
+2. Let QA test the build
+3. Promote the tested release from `QA` to `Production` using the `appzung releases promote` command
+
+_NOTE: If you want to take a more cautious approach, you can even choose to perform a "staged rollout" as part of #3, which allows you to mitigate additional potential risk with the update (like did your testing in #2 touch all possible devices/conditions?) by only making the production update available to a percentage of your users (for example `appzung releases promote -r 20`). Then, after waiting for a reasonable amount of time to see if any crash reports or customer feedback comes in, you can expand it to your entire audience by running `appzung releases edit -r 100`._
+
+### Dynamic release channel assignment
+
+The above section illustrated how you can leverage multiple CodePush release channels in order to effectively test your updates before broadly releasing them to your end users. However, since that workflow statically embeds the release channel assignment into the actual binary, a staging or production build will only ever sync updates from that release channel. In many cases, this is sufficient, since you only want your team, customers, stakeholders, etc. to sync with your pre-production releases, and therefore, only they need a build that knows how to sync with staging. However, if you want to be able to perform A/B tests, or provide early access of your app to certain users, it can prove very useful to be able to dynamically place specific users (or audiences) into specific release channels at runtime.
+
+In order to achieve this kind of workflow, all you need to do is specify the release channel public ID you want the current user to synchronize with when calling the `codePush` method. When specified, this key will override the "default" one that was provided in your app's `Info.plist` (iOS) or strings resources (Android) files. This allows you to produce a build for staging or production, that is also capable of being dynamically "redirected" as needed.
+
+```javascript
+// Imagine that "userProfile" is a prop that this component received
+// which includes the release channel public ID that the current user should use.
+codePush.sync({ releaseChannelPublicId: userProfile.RELEASE_CHANNEL_PUBLIC_ID });
+```
+
+With that change in place, now it's just a matter of choosing how your app determines the right release channel for the current user. In practice, there are typically two solutions for this:
+
+1. Expose a user-visible mechanism for changing release channels at any time. For example, your settings page could have a toggle for enabling "beta" access. This model works well if you're not concerned with the privacy of your pre-production updates, and you have power users that may want to opt-in to earlier (and potentially buggy) updates at their own will (kind of like Chrome channels). However, this solution puts the decision in the hands of your users, which doesn't help you perform A/B tests transparently.
+2. Annotate the server-side profile of your users with an additional piece of metadata that indicates the release channel they should sync with. By default, your app could just use the binary-embedded key, but after a user has authenticated, your server can choose to "redirect" them to a different release channel, which allows you to incrementally place certain users or groups in different release channels as needed. You could even choose to store the server-response in local storage so that it becomes the new default. How you store the key alongside your user's profiles is entirely up to your authentication solution (for example Auth0, Firebase, custom DB + REST API), but is generally pretty trivial to do.
+
+_NOTE: If needed, you could also implement a hybrid solution that allowed your end-users to toggle between different release channels, while also allowing your server to override that decision. This way, you have a hierarchy of "release channel resolution" that ensures your app has the ability to update itself out-of-the-box, your end users can feel rewarded by getting early access to bits, but you also have the ability to run A/B tests on your users as needed._
+
+Are you using dynamic release channel assignments? Contact us at hello@appzung.com so that we may provide better integration.

package/docs/api-android.md

@@ -1,83 +1,22 @@
-### Java API Reference (Android)
+## Java API reference (Android)
 
-### API for React Native 0.60 version and above
+You can customize CodePush by placing these values in string resources.
 
-Since `autolinking` uses `react-native.config.js` to link plugins, constructors are specified in that file. But you can override custom variables to manage the CodePush plugin by placing these values in string resources.
+- **Release channel Public ID** - The default release channel's **public ID** that will be used to check updates. For example:
 
-* __Public Key__ - used for bundle verification in the Code Signing Feature. Please refer to [Code Signing](setup-android.md#code-signing-setup) section for more details about the Code Signing Feature.
-    To set the public key, you should add the content of the public key to `strings.xml` with name `CodePushPublicKey`. CodePush automatically gets this property and enables the Code Signing feature. For example:
-    ```xml
-    <string moduleConfig="true" name="CodePushPublicKey">your-public-key</string>
-    ```
+  ```xml
+  <string moduleConfig="true" name="CodePushReleaseChannelPublicId">sU0Eikse9JFCDLZmAT-_lUSwDWACrSGgTKCXyWqcE0</string>
+  ```
 
-* __Server Url__ - used for specifying CodePush Server Url.
-    The Default value: "https://codepush.appzung.com/" is overridden by adding your path to `strings.xml` with name `CodePushServerUrl`. CodePush automatically gets this property and will use this path to send requests. For example:
-    ```xml
-    <string moduleConfig="true" name="CodePushServerUrl">https://yourcodepush.server.com</string>
-    ```
+- **Public Key** - used for bundle verification in the Code Signing Feature. Please refer to [Code Signing](setup-android.md#code-signing-setup) section for more details about the Code Signing Feature.
+  To set the public key, you should add the content of the public key to `strings.xml` with name `CodePushSigningPublicKey`. CodePush automatically gets this property and enables the Code Signing feature. For example:
 
-### API for React Native lower than 0.60
+  ```xml
+  <string moduleConfig="true" name="CodePushSigningPublicKey">your-public-key</string>
+  ```
 
-The Java API is made available by importing the `com.microsoft.codepush.react.CodePush` class into your `MainActivity.java` file, and consists of a single public class named `CodePush`.
-
-#### CodePush
-
-Constructs the CodePush client runtime and represents the `ReactPackage` instance that you add to you app's list of packages.
-
-##### Constructors
-
-- __CodePush(String deploymentKey, Activity mainActivity)__ - Creates a new instance of the CodePush runtime, that will be used to query the service for updates via the provided deployment key. The `mainActivity` parameter should always be set to `this` when configuring your React packages list inside the `MainActivity` class. This constructor puts the CodePush runtime into "release mode", so if you want to enable debugging behavior, use the following constructor instead.
-
-- __CodePush(String deploymentKey, Activity mainActivity, bool isDebugMode)__ - Equivalent to the previous constructor but allows you to specify whether you want the CodePush runtime to be in debug mode or not. When using this constructor, the `isDebugMode` parameter should always be set to `BuildConfig.DEBUG` in order to stay synchronized with your build type. When putting CodePush into debug mode, the following behaviors are enabled:
-
-    1. Old CodePush updates aren't deleted from storage whenever a new binary is deployed to the emulator/device. This behavior enables you to deploy new binaries, without bumping the version during development, and without continuously getting the same update every time your app calls `sync`.
-
-    2. The local cache that the React Native runtime maintains in debug mode is deleted whenever a CodePush update is installed. This ensures that when the app is restarted after an update is applied, you will see the expected changes. As soon as [this PR](https://github.com/facebook/react-native/pull/4738) is merged, we won't need to do this anymore.
-
-- __CodePush(String deploymentKey, Context context, boolean isDebugMode, Integer publicKeyResourceDescriptor)__ - Equivalent to the previous constructor, but allows you to specify the public key resource descriptor needed to read public key content. Please refer to [Code Signing](setup-android.md#code-signing-setup) section for more details about the Code Signing Feature.
-
-- __CodePush(String deploymentKey, Context context, boolean isDebugMode, String serverUrl)__ Constructor allows you to specify CodePush Server Url. The Default value: `"https://codepush.appzung.com/"` is overridden by value specified in `serverUrl`.
-
-##### Builder
-
-As an alternative to constructors *you can also use `CodePushBuilder`* to setup a CodePush instance configured with *only parameters you want*.
-
-```java
-    @Override
-    protected List<ReactPackage> getPackages() {
-      return Arrays.<ReactPackage>asList(
-            new MainReactPackage(),
-            new CodePushBuilder("deployment-key-here",getApplicationContext())
-                .setIsDebugMode(BuildConfig.DEBUG)
-                .setPublicKeyResourceDescriptor(R.string.publicKey)
-                .setServerUrl("https://yourcodepush.server.com")
-                .build() //return configured CodePush instance
-      );
-    }
-```
-
-`CodePushBuilder` methods:
-
-* __public CodePushBuilder(String deploymentKey, Context context)__ - setup same parameters as via __CodePush(String deploymentKey, Activity mainActivity)__
-
-* __public CodePushBuilder setIsDebugMode(boolean isDebugMode)__ - allows you to specify whether you want the CodePush runtime to be in debug mode or not. Default value: `false`.
-
-* __public CodePushBuilder setServerUrl(String serverUrl)__ - allows you to specify CodePush Server Url. Default value: `"https://codepush.appzung.com/"`.
-
-* __public CodePushBuilder setPublicKeyResourceDescriptor(int publicKeyResourceDescriptor)__ - allows you to specify Public Key resource descriptor which will be used for reading Public Key content for `strings.xml` file. Please refer to [Code Signing](setup-android.md#code-signing-setup) section for more detailed information about purpose of this parameter.
-
-* __public CodePush build()__ - return configured `CodePush` instance.
-
-##### Public Methods
-
-- __setDeploymentKey(String deploymentKey)__ - Sets the deployment key that the app should use when querying for updates. This is a dynamic alternative to setting the deployment key in Codepush constructor/builder and/or specifying a deployment key in JS when calling `checkForUpdate` or `sync`.
-
-##### Static Methods
-
-- __getBundleUrl()__ - Returns the path to the most recent version of your app's JS bundle file, assuming that the resource name is `index.android.bundle`. If your app is using a different bundle name, then use the overloaded version of this method which allows specifying it. This method has the same resolution behavior as the Objective-C equivalent described above.
-
-- __getBundleUrl(String bundleName)__ - Returns the path to the most recent version of your app's JS bundle file, using the specified resource name (like `index.android.bundle`). This method has the same resolution behavior as the Objective-C equivalent described above.
-
-- __getPackageFolder()__ - Returns the path to the current update folder.
-
-- __overrideAppVersion(String appVersionOverride)__ - Sets the version of the application's binary interface, which would otherwise default to the Play Store version specified as the `versionName` in the `build.gradle`. This should be called a single time, before the CodePush instance is constructed.
+- **Server Url** - used for specifying CodePush Server Url (as an Enterprise customer we may setup a custom infra for your needs).
+  The Default value: "https://codepush.appzung.com/" is overridden by adding your path to `strings.xml` with name `CodePushServerUrl`. CodePush automatically gets this property and will use this path to send requests. For example:
+  ```xml
+  <string moduleConfig="true" name="CodePushServerUrl">https://codepush.yourdomain.com</string>
+  ```

package/docs/api-ios.md

@@ -1,31 +1,19 @@
-### Objective-C API Reference (iOS)
+## Objective-C API reference (iOS)
 
 The Objective-C API is made available by importing the `CodePush.h` header into your `AppDelegate.m` file, and consists of a single public class named `CodePush`.
 
-#### CodePush
+### CodePush
 
-Contains static methods for retreiving the `NSURL` that represents the most recent JavaScript bundle file, and can be passed to the `RCTRootView`'s `initWithBundleURL` method when bootstrapping your app in the `AppDelegate.m` file.
+Contains static methods for retrieving the `NSURL` that represents the most recent JavaScript bundle file, and can be passed to the `RCTRootView`'s `initWithBundleURL` method when bootstrapping your app in the `AppDelegate.m` file.
 
-The `CodePush` class' methods can be thought of as composite resolvers which always load the appropriate bundle, in order to accommodate the following scenarios:
+#### Methods
 
-1. When an end-user installs your app from the store (like `1.0.0`), they will get the JS bundle that is contained within the binary. This is the behavior you would get without using CodePush, but we make sure it doesn't break :)
+- **(NSURL \*)bundleURL** - Returns the most recent JS bundle `NSURL` as described above. This method assumes that the name of the JS bundle contained within your app binary is `main.jsbundle`.
 
-2. As soon as you begin releasing CodePush updates, your end-users will get the JS bundle that represents the latest release for the configured deployment. This is the behavior that allows you to iterate beyond what you shipped to the store.
+- **(NSURL \*)bundleURLForResource:(NSString \*)resourceName** - Equivalent to the `bundleURL` method, but also allows customizing the name of the JS bundle that is looked for within the app binary. This is useful if you aren't naming this file `main` (which is the default convention). This method assumes that the JS bundle's extension is `*.jsbundle`.
 
-3. As soon as you release an update to the app store (like `1.1.0`), and your end-users update it, they will once again get the JS bundle that is contained within the binary. This behavior ensures that CodePush updates that targetted a previous binary version aren't used (since we don't know if they would work), and your end-users always have a working version of your app.
+- **(NSURL \*)bundleURLForResource:(NSString \*)resourceName withExtension:(NSString \*)resourceExtension**: Equivalent to the `bundleURLForResource:` method, but also allows customizing the extension used by the JS bundle that is looked for within the app binary. This is useful if you aren't naming this file `*.jsbundle` (which is the default convention).
 
-4. Repeat #2 and #3 as the CodePush releases and app store releases continue on into infinity (and beyond?)
+- **(void)overrideAppVersion:(NSString \*)appVersionOverride** - Sets the version of the application's binary interface, which would otherwise default to the App Store version specified as the `CFBundleShortVersionString` in the `Info.plist`. This should be called a single time, before the bundle URL is loaded.
 
-Because of this behavior, you can safely deploy updates to both the app store(s) and CodePush as necesary, and rest assured that your end-users will always get the most recent version.
-
-##### Methods
-
-- __(NSURL \*)bundleURL__ - Returns the most recent JS bundle `NSURL` as described above. This method assumes that the name of the JS bundle contained within your app binary is `main.jsbundle`.
-
-- __(NSURL \*)bundleURLForResource:(NSString \*)resourceName__ - Equivalent to the `bundleURL` method, but also allows customizing the name of the JS bundle that is looked for within the app binary. This is useful if you aren't naming this file `main` (which is the default convention). This method assumes that the JS bundle's extension is `*.jsbundle`.
-
-- __(NSURL \*)bundleURLForResource:(NSString \*)resourceName withExtension:(NSString \*)resourceExtension__: Equivalent to the `bundleURLForResource:` method, but also allows customizing the extension used by the JS bundle that is looked for within the app binary. This is useful if you aren't naming this file `*.jsbundle` (which is the default convention).
-
-- __(void)overrideAppVersion:(NSString \*)appVersionOverride__ - Sets the version of the application's binary interface, which would otherwise default to the App Store version specified as the `CFBundleShortVersionString` in the `Info.plist`. This should be called a single time, before the bundle URL is loaded.
-
-- __(void)setDeploymentKey:(NSString \*)deploymentKey__ - Sets the deployment key that the app should use when querying for updates. This is a dynamic alternative to setting the deployment key in your `Info.plist` and/or specifying a deployment key in JS when calling `checkForUpdate` or `sync`.
+- **(void)setReleaseChannelPublicId:(NSString \*)releaseChannelPublicId** - Sets the release channel public ID that the app should use when querying for updates. This is a dynamic alternative to setting the release channel in your `Info.plist` and/or specifying a release channel in JS when calling `checkForUpdate` or `sync`.