Summary:
Device Id needs to be the same for multiple apps on the same device. This isn't true for this attribute, which is specific to the vendor of the app.
Apple has deprecated the API that gives you the device Id, so we can't discover it in the SDK alone.
However, this isn't a problem because we have a similar issue on android, and now Flipper desktop gives each device it's own deviceId during certificate exchange.
Removing this incorrect one so it's never used as a fallback, which would cause flipper to think the app is on a different device than the one it's running on.
Reviewed By: danielbuechele
Differential Revision: D9700552
fbshipit-source-id: 5467f6cb7d1f941af9df09fc6a03dbe34e6575e5
Summary:
Sonar was trying to convert folly dynamics containing NaN and Inf to json.
Folly doesn't allow this so we have to get rid of them before converting.
See https://fb.facebook.com/groups/230455004101832/permalink/483173632163300/ for more context.
`grep -r convertFollyDynamicToId fbsource/xplat/sonar` now returns results which all have `true` in the second parameter slot.
Reviewed By: danielbuechele
Differential Revision: D9570364
fbshipit-source-id: bf28b03e54b4987399e028a491d82451a8267d97
Summary:
V1 ios diagnostics complete.
This change adds a new section to the ios diagnostics screen that shows the current state of each step required to get sonar working.
The logs (transitions between states) are displayed below it.
SonarClient.mm is technically involved in the UI, by converting enums to emojis, I don't like this
but didn't get obj-C working with C enums so have left it like this for now.
Reviewed By: priteshrnandgaonkar
Differential Revision: D9378212
fbshipit-source-id: 091ce00e898a8038c680555123640b90d753fc09
Summary:
This diff adds FlipperStateUpdateListener in public headers, as SonarClient.h depends on it and the sample app depends on SonarClient.h.
This diff fixes the compilation error for Sample and SwiftSample
Ideally travis should have caught it. Fix for travis is coming.
Reviewed By: jknoxville
Differential Revision: D9462177
fbshipit-source-id: e3e0ec90f9083294d4a131989ec0eaee02b52791
Summary:
Some apps have a default background color, for example black, making the diagnostic screen fully black.
Fix this by making sure the bg is always white so the text is readable.
Reviewed By: passy
Differential Revision: D9400682
fbshipit-source-id: a45744f833cb7fe5ca7db4dcdacc09f304670032
Summary:
Adds an extremely barebones in-app screen for showing sonar diagnostics.
The UI is laughable, but it's wired up. Leaving proper design to a later commit.
Like in the android case, state is currently passed as a string, but will become something much more structured after this is in place.
Reviewed By: priteshrnandgaonkar
Differential Revision: D9218766
fbshipit-source-id: 4889ed79b928056a67b1e8cb8a40a9bd52e084f1
Summary:
Before this PR, travis used to build sample app which used a tagged release of SonarKit and Sonar. So travis used to never check the source code in master branch. This PR, instead uses local podspecs, which refers to the local source code, and thus travis would be testing the local source code.
Solves #237
Pull Request resolved: https://github.com/facebook/flipper/pull/244
Reviewed By: passy
Differential Revision: D9394955
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 7109a8baaeb8ff7e14d19ebe1d7c3bcb7e4bebd2
Summary: Releases a new iOS version 0.6.16. After landing this I will release 0.6.16 tag on github
Reviewed By: danielbuechele
Differential Revision: D9194965
fbshipit-source-id: 13d5e346d6d34a7bf7b6dfb568ca622d97660132
Summary: With the new swift support for network plugin, the sample swift app was not compiling as it didn't have the location of plublic header files
Reviewed By: danielbuechele
Differential Revision: D9194964
fbshipit-source-id: 210da3b4a921febc95a3ee8a6dc7788278c5db96
Summary:
Prior to this diff the OSS sonar project depended on folly's master branch instead of tags, which is not good as things can break, which broke recently. So this diff adds the folly dependency thru tags to avoid any future failures.
This diff releases a new folly dependency which relies on a tag
Reviewed By: danielbuechele
Differential Revision: D9194966
fbshipit-source-id: 0a0956f0bd457e375fcbb86b3fec412aeb759a47
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:
It was deleted in one of the previous commit and it broke the build
Pull Request resolved: https://github.com/facebook/flipper/pull/198
Reviewed By: passy
Differential Revision: D9117234
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 72d9d58a11683b8a51732b3f735ef1326ce56794
Summary:
9f807c introduced a new subspec in SonarKit.podspec, which caused Cpp header files to be included in `SonarKit-umbrella.h`, causing all non-ObjC++ project integrations to fail to build (see #190 for more info). SirArkimedes and I investigated this today and found the fix:
1. Make the `CppBridge` subspec's header files private
2. Add a hack to make Cocoapods copy `FBMacros.h` into `{PODS_ROOT}/Headers/Public/SonarKit`, since otherwise `#import "FBMacros.h"` in `SonarKit-umbrella.h` will fail to resolve in out-of-the-box projects.
I've put up a branch [here](https://github.com/noahsark769/sonar-testing-example-projects/tree/working_reference) which pulls the pod from this branch and verifies that the fix works.
Fixes#190
Pull Request resolved: https://github.com/facebook/Sonar/pull/192
Reviewed By: passy
Differential Revision: D9049420
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 9383016975607e897085323d64ad44a068199918
Summary:
This diff only moves the core of sonarkit to the xplat.
- This diff uses `fb_xplat_cxx_library` as a buck rule in xplat as it is the recommended way
- Updated few imports in the files which were not compiling with new buck function
- Due to the new way of import the OSS would break, so fixed it by changing the `podspec` file
Reviewed By: passy
Differential Revision: D8937414
fbshipit-source-id: 6e12cd049bedb496e7a6820be85b2535e70ba09b
Summary:
Fixing T31692652.
I couldn't reproduce this on my local tests - (tried non-utf chars, deleted memory, onverted vectors that are erased).
My guess - an illegal string cannot be converted to NSSString and thus we return nil when the folly::dynamic type is STRING.
See task for additional details.
Reviewed By: nubbel
Differential Revision: D8952714
fbshipit-source-id: c87af523efca1b96a4cf3d5d26fa5c16ed5cd773
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
Summary:
This diff adds the support to automate iOS releases. This diff adds two scripts, one for updating all the `podspecs`, and `podfiles` with updated version number. The script also updates the version used in sample and getting started doc file.
The second script publishes a github tag.
Following will be the process for iOS release:-
1. From `fbobjc/Libraries/SonarKit/Scripts` run `sh public-ios-podspec-update.sh`, it will update all the podspecs, podfiles and docs with updated version number. Commit it and land this
2. Once the above changes are landed and synced to github, run `sh push-new-github-tag.sh` from `fbobjc/Libraries/SonarKit/Scripts` to push the tag on github
As a follow up on this diff, ideally, we should trigger second script automatically when the 1st task changes are synced to github.
Reviewed By: jknoxville
Differential Revision: D8879958
fbshipit-source-id: 8f0dc9200e8f64578af33e1446629f09c16c43f2
Summary: The receiving callbacks are executed from a thread that doesn't have an autorelease pool. That results in autoreleased objects leaking
Reviewed By: schaitoff
Differential Revision: D8889915
fbshipit-source-id: 07e9129954e6f9afea56473b590125c63ecd7092
Summary:
This diff uses `tag` instead of master branch and also updates the version number to the desktop sdk.
Pull Request resolved: https://github.com/facebook/Sonar/pull/152
Reviewed By: danielbuechele
Differential Revision: D8820016
Pulled By: priteshrnandgaonkar
fbshipit-source-id: ff2e554be55254b77c4e130b35b7299abbafa77d
Summary:
We currently give sonar one event base from java / obj-c code to use for scheduling tasks.
This causes a problem, because we schedule reconnect tasks on the event base, and then these tasks interact with rsocket which schedules it's own tasks.
The problem is that we're passing rsocket the same event base. So the reconnect code executes and blocks waiting for rsocket to connect.
But rsocket can never connect because it never executes because that thread is blocked, so we get deadlock.
Fixing it by giving both processes their own event base / thread.
Reviewed By: danielbuechele
Differential Revision: D8748355
fbshipit-source-id: b0ad2172087f0103180677438f427c831db7f42c
Summary:
We currently give sonar one event base from java / obj-c code to use for scheduling tasks.
This causes a problem, because we schedule reconnect tasks on the event base, and then these tasks interact with rsocket which schedules it's own tasks.
The problem is that we're passing rsocket the same event base. So the reconnect code executes and blocks waiting for rsocket to connect.
But rsocket can never connect because it never executes because that thread is blocked, so we get deadlock.
This is the first step which just changes the interface to pass two event bases.
The consumers will be changed to pass in different threads next.
Reviewed By: danielbuechele
Differential Revision: D8748350
fbshipit-source-id: 481d6f23644f28fd0f1c786252605287019c999c
Summary:
This PR brings us one step closer for publishing SonarKit.podspec to the public Cocoapods master repository. This solves [#93](https://github.com/facebook/Sonar/issues/93).
- [X] `SonarKit.podspec` now lints by passing the `--sources` flag and the `--use-libraries` flag. `pod spec lint SonarKit.podspec --sources=https://github.com/facebook/Sonar,master --allow-warnings --use-libraries` Same for `pod repo push`.
- [X] `SonarKit.podspec` is now also published to the CocoaPods Private repo. What does this mean? It means that we no longer need to manually define all of `SonarKit` dependencies in the Podfile. It only takes `SonarKit` consumers to add this line `source 'https://github.com/facebook/Sonar.git'` on top of any Podfile, and `SonarKit` will be installed by just defining it with `pod SonarKit`.
- [X] We are publishing a Cocoapods Private Repo in the meantime we don't have all of our dependencies updated and published to the CocoaPods master repo. The CocoaPods Private Repo contains updated dependency podspecs that will need to be published to the CocoaPods master repo in the near future. That will be the next action item in order to have SonarKit.podspec published as well.
- [X] Sample App Podfile has been refactored, much simpler and cleaner.
- [X] SonarKit Framework project now pulls its dependencies from the cocoapods master repository and the temporary private repository instead of the local podspecs. I am able to compile the SonarKit framework project now, before I was unable to.
- [X] Local third party podspec dependencies have been removed.
emilsjolander priteshrnandgaonkar noahsark769 feel free to contribute or expose any concerns.
Closes https://github.com/facebook/Sonar/pull/107
Reviewed By: danielbuechele
Differential Revision: D8694271
Pulled By: priteshrnandgaonkar
fbshipit-source-id: dcccf70d917cad1e27606a29c0b921883bf9a76f
Summary:
This diff repaces the faulty sonarkit.xcodeproj with the current one. I think ship it synced the xcodeproj which was generated by buck.
Closes https://github.com/facebook/Sonar/pull/96
Reviewed By: emilsjolander
Differential Revision: D8538609
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 9eb049a9770c40b652f999ace9b82207e3a395e5
