* 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
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>`
* 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
* 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).
* 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
This change aims to support applications which run React Native's catalyst instance in the background, sometimes without an activity.
We're using this change today in an RN 0.27 application, which overrides `ReactActivity#createReactInstanceManager` to afford us control of the instance's lifecycle, so that we may run and launch without an `Activity` (i.e., in response to push notifications and other triggers).
If we agree with this approach, I'll update this PR with documentation/etc.
