Summary:
About to release React Native 0.72.1. This version of React Native has to depend on SocketRocket 0.7.0, released yesterday.
Cocoapods is failing to install dependencies with the following error:
```
In snapshot (Podfile.lock):
SocketRocket (= 0.7.0)
In Podfile:
FlipperKit/FlipperKitReactPlugin (= 0.182.0) was resolved to 0.182.0, which depends on
FlipperKit/Core (= 0.182.0) was resolved to 0.182.0, which depends on
SocketRocket (~> 0.6.0)
React-Core/RCTWebSocket (from `../react-native/`) was resolved to 1000.0.0, which depends on
SocketRocket (= 0.7.0)
React-CoreModules (from `../react-native/React/CoreModules`) was resolved to 1000.0.0, which depends on
SocketRocket
```
By bumping the SocketRocket dependencies and publishing a new version of FlipperKit, we would be able to release React Native.
Reviewed By: passy, cipolleschi
Differential Revision: D47125059
fbshipit-source-id: d0797880c502c14db9f0261c3e8abf2652e7bba2
Summary:
This PR updates the OpenSSL pod and thus updates the corresponding Folly and RSocket pods. The new OpenSSL pod has a support of arm64 artifact for iPhomeSimulators.This PR also updates the replaces the libevent pod which didn't work with arm64 arch for iPhoneSimulator.
## Changelog
- Update OpenSSL pod
- Update Folly dep
- Update RSocket dep
- Replace Libevent pod.
Pull Request resolved: https://github.com/facebook/flipper/pull/1892
Test Plan: CI
Reviewed By: mweststrate
Differential Revision: D26229304
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 46256d9cd3e0cf5aab6e477e612c3bcb77e31627
Summary: Updates the OpenSSL dependency. Enabling bitcode as the latest version of OpenSSL has bitcode support.
Reviewed By: mweststrate
Differential Revision: D24276537
fbshipit-source-id: 6f135659d64e8849dcf68266458a8f24ef795be7
Summary:
Currently user’s are being told to add a definition of the `FB_SONARKIT_ENABLED` macro and examples, including those in stock React Native templates, set this for the user by making use of a `post_install` hook in the user’s `Podfile`. This leads to confusion, fragile code [when a user’s project dir structure deviates from vanilla], and is ultimately not necessary as CocoaPods already has dedicated mechanisms to:
* specify build settings (through the `xcconfig` property);
* and selectively include certain pods only in certain build configurations (e.g. debug).
Finally, this PR also includes a commit [to fix the current builds](https://github.com/facebook/flipper/pull/1086/files#r418526812).
## Changelog
> Entirely control Flipper being enabled through inclusion in Podfile and optionally limiting to certain build configurations using the `:configuration` directive.
Pull Request resolved: https://github.com/facebook/flipper/pull/1086
Test Plan: I have built and ran the Sample application, as well as used this version of Flipper with a new RN app built from `master`.
Reviewed By: passy
Differential Revision: D21381828
Pulled By: priteshrnandgaonkar
fbshipit-source-id: edf6dae28eb02336a49e8230654d6186360ea8d6
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/992
Right now our sample app's fail to build when built against "Generic iOS Device", but it built successfully when built against simulator. Reason being all the simulators are 64 bit's, but when built against generic iOS device type, it didn't work for all the architecture as our Flipper and Flipper-Folly pod had 64bit architecture in their settings. But as soon as you build Flipper-Folly for standard architecture, RCU.cpp fails to build as that file is incompatible for lower standard architecture. Got the following error
{F233400670}
But, we do not need that file of Folly to build Flipper and RSocket. Thus in the podfile I have excluded it from its source. Also along with it I upgraded both Folly and RSocket to the latest releases.
Even with this changes i got one more problem, our openssl static library is not bitcode enabled for arm architecture, this error popped up when built against "Generic iOS Device". Right now I have disabled bitcode, the proper fix of this would be to find a dependency of openssl which is bitcode enabled. Its really hard to find the proper cocoapod dependency of openssl which is bitcode enabled. But disabling bitcode is not a big ask, also people will face this error only when they try to publish flipper in their release.
I discovered this problem from an issue posted in [RN](https://github.com/react-native-community/upgrade-support/issues/35), it also takes care of this issue.
Reviewed By: passy
Differential Revision: D20897590
fbshipit-source-id: 8c79d239572bb7efe2d65b2a7f1cfe8c608c1df4
Summary: Removed the swift files in Sample app and instead added swift library paths in search paths
Reviewed By: passy
Differential Revision: D19877848
fbshipit-source-id: fdaeba8ba4ed58216e413125b29fe20bad9d03f5
Summary: This releases glog and DoubleConversion under "Flipper" preappended name as it solves the issues with Flipper integration with RN under use_frameworks! keyword.
Reviewed By: passy
Differential Revision: D19392941
fbshipit-source-id: ebdcdc23fcce45cec9bfc6d4f18c14a734caf24f
Summary:
This diff fixes the broken sample app for xcode 11. Followed the remediation mentioned in the following links
https://github.com/Carthage/Carthage/issues/2825https://twitter.com/krzyzanowskim/status/1151549874653081601?s=21
Remediation:
Adding Dummy swift file and assigning `"LD_VERIFY_BITCODE": "NO"` solves the problem as suggested in the above links
Reviewed By: jknoxville
Differential Revision: D18420954
fbshipit-source-id: e87930790329ffb2bb92c40aa197552efeedecd3
Summary:
I have released pods for Folly and RSocket on cocoapods. Thus we won't need to host different versions of these pods on our repository. I haven't removed those pods from `Specs` folder, as the current users of `0.16.2` would still be referring the Specs folder on the master branch. I will remove the specs folder once, all our pods are on cocoapods and we no longer need to host any pods.
Pull Request resolved: https://github.com/facebook/flipper/pull/379
Reviewed By: jknoxville
Differential Revision: D14185931
Pulled By: priteshrnandgaonkar
fbshipit-source-id: ea285024123e41c2d110827e26f79a72ef22c008
Summary:
This PR updates the installation instruction. It missed few crucial information and thus the projects installing flipper as a dependency were facing issues. It addresses the issue #341. It also brings the sample application at par with the documentation.
Pull Request resolved: https://github.com/facebook/flipper/pull/343
Reviewed By: danielbuechele
Differential Revision: D13507298
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 5a4b23d79930cb7eeb491e359b616d3558e260fb
Summary:
Added a basic communication flows and a button to trigger notification
{F142016937}
Reviewed By: jknoxville
Differential Revision: D10492428
fbshipit-source-id: b65fc46b3be695852f9197771a253d9e8596f328
Summary:
I have a few details left, but its almost done. This PR addresses #145
- The NSUserDefaults plugin uses the SharedPreferences Desktop Part since we can reuse all of it.
- The NSUserDefaults plugin uses swizzling in order to be notified of what specific event changed at runtime.
- Added Test harness in both Sample Swift and Sample apps for iOS in order to test the plugin.
- Updated the documentation in `docs/shared-preferences-plugin.md` and` README.md`
I am open to suggestions since the desktop sharedPreferences version doesn't support deletion of preferences. Most likely I would have to modify the UI, and for that matter, I might as well build a user defaults desktop version
I wanted to add xiphirx in this MR since he developed the shared preferences plugin for Android and Desktop. I don't see a way to remove preferences from the flipper desktop app so I was wondering if you would be OK with me adding that.
Pull Request resolved: https://github.com/facebook/flipper/pull/291
Reviewed By: passy
Differential Revision: D10334685
Pulled By: priteshrnandgaonkar
fbshipit-source-id: d798c01a46df7ddecf713924799f046b560ea922
Summary:
Part of the Sonar -> Flipper rename
Intentionally left externally visible buck target as Sonar for now to minimize diff size.
Reviewed By: passy
Differential Revision: D9871684
fbshipit-source-id: 6926eb62c578a05cd895745c75ed7da3cfe965b5
Summary:
Solves #173
- [x] Add plugins in the sonarkit xcodeproj so that its easy to debug
- [x] Get rid off the c++ in the headers
- [x] Add example to hit network requests and validate
Have a look at the screen shot below ✨⭐️⚡️
<img width="1677" alt="screen shot 2018-08-02 at 12 46 07 pm" src="https://user-images.githubusercontent.com/3865908/43581809-22efe4fe-9652-11e8-9424-f279d07c5c81.png">
Pull Request resolved: https://github.com/facebook/flipper/pull/201
Reviewed By: danielbuechele
Differential Revision: D9132157
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 2b425506961f02eb2bf629c2bcab0da6e7ce5bb0
Summary:
Solves #203
- [x] Sample Objc and Swift apps now have default configs(i.e non-recursive header search paths)
- [x] Fix for the cocoapods default config by adding FBMacros.h file in `Core` subspec
- [x] Updated the Spec(0.6.15) so that 0.6.15 works for default configs
- [x] Updated the doc
Pull Request resolved: https://github.com/facebook/flipper/pull/205
Reviewed By: passy
Differential Revision: D9148358
Pulled By: priteshrnandgaonkar
fbshipit-source-id: e6d32d9cde7b100573bd9a9996f0ec850b269d28
Summary:
This PR adds support for using SonarKit clients in Swift apps. Fixes#13, fixes#87
1. Swift can't import Obj-C modules which have C++ headers. For this reason, we use SonarKit as an Obj-C++ wrapper around Sonar, which is written in C++. Due to search path misconfiguration, trying to import SonarKit into a Swift project would import `xplat/Sonar/SonarPlugin.h` instead of `iOS/SonarKit/SonarPlugin.h`, which caused `file not found` errors for C++ stdlib imports like #28 because new projects don't have their search paths set up correctly.
2. The network and layout plugins have C++ definitions (struct methods, classes) in some of their headers. This causes the compiler to get confused for Swift projects, because it only supports importing Objective-C files in umbrella headers, meaning that the `SonarKit` won't build.
1. I updated the `HEADER_SEARCH_PATHS` of SonarKit.podspec's build configuration to include `${PODS_ROOT}/Headers/Private/SonarKit/**` first, which alleviates the search path issue. The Obj-C `Sample` project seems to have worked around this by including a hardcoded `${PODS_ROOT}/SonarKit/**` search path in the pbxproj, which is why Sample works but new projects (like those referenced in #28) don't. I removed this since it's no longer necessary.
2. I added a `SampleSwift` app to demonstrate using Sonar with a Swift project.
3. Because the Podfiles for `Sample` and `SampleSwift` referenced podspecs using `:podspec` instead of a concrete version, Cocoapods wouldn't copy local header files (instead, it downloads them from the source). To enable local development of these sample apps using `:path`, I added a symlink to SonarKit.podspec in the root of the directory.
4. I changed SonarKit.podspec to use a tag-based `source`, since v0.0.1 pulls from the master branch of this repo.
The layout and network plugins still don't work with Swift - in order to fix this, we'll need to work on extracting the C++ out of their headers and writing Obj-C++ wrappers for them. I decided to push this off to a later PR since this one is quite large already.
This means that we need to be able to `import SonarKit` without importing all the network/layout plugin headers. In order to make this work, I made "SonarKit/Core" the spec's `default_subspecs`.
priteshrnandgaonkar, let me know if you have any thoughts on this implementation. You can verify that the SampleSwift app works by checking out this branch, `pod install`ing in the SampleSwift directory, and building it :)
Pull Request resolved: https://github.com/facebook/Sonar/pull/106
Reviewed By: jknoxville
Differential Revision: D8890010
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 449305bcc5cbeb5787c23f51b1ecb80a5cbdad32
