`CodePushHash.json` file name breaks flow type checking.
To fix the issue we need to delete `CodePushHash.json` file and
use `CodePushHash` file name instead to store the hash value.
Relates to https://github.com/Microsoft/react-native-code-push/issues/577
* Update README.md
When I fail to supply a CODEPUSH_KEY variable for debug, the build fails. This pull fixes the example code. I also added a comment letting developers know to expect errors from CodePush in debug mode. (This behavior is surprising, but I believe is by design.)
* Tweak comment
Remove `assetsDir` variable, as `generateBundledResourcesHash.js` should output `CodePushHash.json` to `jsBundleDir${targetName}` folder, and not the hardcoded `$buildDir/intermediates/assets/${targetPath}` one.
* Improved logic for searching plist file path for iOS postlink.js
Added Xcode package for parsing xcodeproj file and retrieving correct plist file related to the project. This should also fix issue described here: https://github.com/Microsoft/react-native-code-push/issues/661
* Improved logic for searching plist file path for iOS postlink.js
Added logic to narrow xcode 'getBuildProperty' function results to specified Product_Name property. This should help us to chsose correct project from pbxproj file when we have several projects defined.
* Added logic to try to get 'Release' build of ProductName matching the package name first and if it doesn't exist then try to get any other if existing
Added support react-native-windows dotNet
Added example for react-native-windows UWP based
Added example for react-native-windows dotNet based
Project structure:
CodePush.Shared - shared code between UWP and dotNet
CodePush - UWP specific code
CodePush.Net46 - dotNet specific code
For UWP solution it needs to be added the following projects:
CodePush.Shared
CodePush
For dotNet solution it needs to be added the following projects:
CodePush.Shared
CodePush.Net46
Examples:
Examples\CodePushDemoApp\windows\CodePushDemoApp.sln the solution contains both examples (UWP and dotNet).
Notes
Example for ARM configuration has not been tested. Since there is no changes in UWP part of implementation, there is low risk of failure.
In this implementation we tried to reuse UWP library as much as possible. The following issues are relevant for both platforms:
ZipFile.ExtractToDirectory is not reliable and throws exception if:
folder exists already
path is too long (> 250 chars)
Un-zipping is quite long operation. Does it make sense for async?
await UpdateUtils.UnzipBundleAsync(downloadFile.Path, unzippedFolder.Path);
AsyncTasks are executed on a single thread to avoid common application errors caused by parallel execution.
So to make it possible to use tools like AsyncStorage while CodePush downloading an update we should use
`asyncTask.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR);` code instead of `asyncTask.execute()`
