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()`
Instead of `#import "CodePush.h"`, use `#import "<CodePush/CodePush.h>` and export CodePush.h from our module.
* [iOS][Build] Add `Headers` and `Copy Files` build phases
Due to changes in new release of `react-native@0.40.0`
there is `CodePush.h file not found` error occures.
To fix it I've added `CodePush.h` header file in `Headers`
and `Copy Files` build phases and changed
`codePushHeaderImportStatement` variable value from `#import "CodePush.h"`
to `#import <CodePush/CodePush.h>` in `postlink.js` file.
Fix https://github.com/Microsoft/react-native-code-push/issues/662
* readme: update iOS manual plugin installation/usage documentation
Due to changes in React Native v0.40.0 and changes in CodePush project Step 6. of iOS manual plugin installation (add “Header Search Paths”) is not needed anymore. Also changed path to `CodePush.h` file in `AppDelegate.m` to `#import <CodePush/CodePush.h>`
In case version of 'Android Plugin for Gradle'' is lower than 1.3.0
'$buildDir' has slightly different structure - 'merged' folder
does not exists so '${targetPath}' folder contains directly in 'res' folder.
Fix issue https://github.com/Microsoft/react-native-code-push/issues/584
* Update README for iOS Manual plugin installation
Wrong/incomplete path to Codepush iOS library set in the `Header Search Paths` causes Xcode to fail without specifying any errors.
The path to the library should be changed from
```
$(SRCROOT)/../node_modules/react-native-code-push
to
$(SRCROOT)/../node_modules/react-native-code-push/ios
```
Small detail but might cause a developer significant amount of time trying to pin down the cause of the build failure, especially when Xcode does not return any useful error.
The Xcode log when the header search path is wrong:
```
# Exit Status 65
Verify final result code for completed build operation
Build operation failed without specifying any errors. Individual build tasks may have failed for unknown reasons.
One possible cause is if there are too many (possibly zombie) processes; in this case, rebooting may fix the problem.
Some individual build task failures (up to 12) may be listed below.
```
Cheers!
* Update related screenshot for `Header Search Path`
Update related screenshot for `Header Search Path` configuration for manual iOS plugin installation
In issue #477 there was an issue when the project has, for some reason, multiple AppDelegate.m files (eg project sample files) within the ios subdir of an RN project.
This fix will give priority to the AppDelegate.m found inside any path that has the application name (as defined in package.json) in it. If it cannot find that, it will revert to previous behavior (the first element in the path array).
* Upgrade example app to RN 0.35.0
* Update supported versions in README
* Support RN 35 - make a copy of objects queued over the bridge if they are mutable
This line was added in React Native 0.35.0: https://github.com/facebook/react-native/blob/v0.35.0/Libraries/Utilities/MessageQueue.js#L194 (facebook/react-native@145109f). It essentially deep freezes (or makes immutable) any object sent from JS to Native over the bridge. This object is already pass-by-value to begin with, so I assume the purpose of this is to avoid any ambiguity or confusion that might occur if the object is modified while it is sitting in the message queue.
We do send a localPackage object over the bridge, which we modify afterwards. Because we only care about the value of this object at the moment that it is queued, the fix is to make a copy of it before sending it over the bridge.
This is relevant to issue #536 (RN version support).
On Android, prevent hash mismatches by ensuring the hashing algorithm ignores OS X metadata (.DS_Store and __MACOSX). This addresses #472, and mirrors #471, which is the iOS side of the fix.
This allows the server to maintain backward compatibility by distinguishing between different plugins (e.g. React Native/Cordova/Windows), as well as individual versions of these plugins, without needing to use the old SDK version (which refers to the acquisition SDK, which is shared between all plugins).
This will also enable us to resolve#514, by rolling out a CDN only for newer plugin versions. (On the Cordova end at the very least, some users have plugins installed that have a whitelist of acceptable endpoints).
* Upgrade example app to RN 0.34.1
* Fix Android reflection logic to support RN 0.34 (as reported in #536), while maintaining backward compatibility
* Bump package.json and update supported RN versions in README
