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: The selected device, app and plugin are not persisted over a reload using `redux-persist`.
Reviewed By: jknoxville
Differential Revision: D8836481
fbshipit-source-id: 3ace1a950a200255d5daf77791d706ede0ff2138
Summary:
Deselect plugin when app disconnects, but store the information that the users had the app selected. When the app conencts again, restore the user's selection.
This also stores the device seleced by the user and reselects the device if it connects.
Reviewed By: xiphirx
Differential Revision: D8833948
fbshipit-source-id: ad3ef54681550ae674bdd4e695d677aea5c14588
Summary: If the app youre inspecting doesnt have extra ax info then the layout inspector has a bad time
Reviewed By: sjkirby
Differential Revision: D9038286
fbshipit-source-id: e3c1736cba13b870cf7ff648377c822fba4446d0
Summary: Highlights the element corresponding to the view talkback is focused on in green in the ax tree (and updates live as talkback moves).
Reviewed By: blavalla
Differential Revision: D9021542
fbshipit-source-id: c3bf6f5625aacb0cd054032b33a50541b88b2eaf
Summary: Moves SonarKitLayoutPlugin to xplat, keeping just the buck file in the `fbobjc` which directs to `xplat `
Reviewed By: passy
Differential Revision: D8967016
fbshipit-source-id: 9ac99beffee1332f38eb3984958b536eefc74e19
Summary: Show plugins in alphabetical order in the main sidebar, so you can more easily find the one you're insterested in.
Reviewed By: passy
Differential Revision: D8995900
fbshipit-source-id: 2ce4a4f4ac7491378e09da8b6ada3f60102a36cb
Summary:
For those not familiar with android and iOS development practices, adding basic build instructions.
Pull Request resolved: https://github.com/facebook/Sonar/pull/185
Reviewed By: passy
Differential Revision: D8991468
Pulled By: jknoxville
fbshipit-source-id: 990dc1217c7b5275d143b915c1b4872b271f4c94
Summary: Adds an optional 'depressed' param to Button. If set to true, displays the Button as if it was depressed. Used to add a set of togglable buttons in which all or none can be selected.
Reviewed By: jknoxville
Differential Revision: D8903854
fbshipit-source-id: ff39bed91514e420b49cb75fe57e490fa641b810
Summary: Shows basic relationship between the AX and nonAX tree litho nodes. When a litho component is selected from the nonAX tree, it's corresponding hostView or lithoView (root of the component tree) is highlighted in the AX tree giving priority to the hostView if it exists. If a hostView is selected in the AX tree, it's corresponding component is selected in the non-AX tree. If a lithoView is selected from the AX tree, it's corresponding lithoView is highlighted in the non-AX tree. This means that each hostView has a one-to-one highlighting between the two trees but lithoViews will have many nodes in the main tree that map to one node in the AX tree (which is accurate to litho components rendering but we may need to change in the future if it is not clear).
Reviewed By: jknoxville
Differential Revision: D8972205
fbshipit-source-id: d136f5b594d0ac1b66a82b35dc7b085186829fc4
Summary: When expanding one tree, the other tree also expands. This expanding jumps over fragments (which are not in the accessibility tree) so that the trees can stay in sync even when there are extra wrappers in the main tree. Need to figure out functionality for litho components (these simply don't expand together right now since the relationship between the trees at these nodes are less obvious).
Differential Revision: D8943229
fbshipit-source-id: 289c3511a6495508b45a62da13ae4c50209e6118
Summary: Per title. CI is unhappy.
Reviewed By: jknoxville
Differential Revision: D8991974
fbshipit-source-id: db7b9161b814fbbae0849d3ee3d551a7a8588985
Summary:
Pull Request resolved: https://github.com/facebook/Sonar/pull/184
Move all files in xplat//sonar-client to xplat//sonar/xplat.
xplat//sonar-client is now deleted and all references updated to point to the new location.
Why?
So that internal file structure matches github file structure.
Reviewed By: priteshrnandgaonkar
Differential Revision: D8966740
fbshipit-source-id: 503da608e4385dc1563c56082eb7a1f48525bdc7
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: Adds warning if plugin is ignored due to user not being the part of gatekeeper. As it will help us to better support our users
Reviewed By: passy
Differential Revision: D8952074
fbshipit-source-id: a5b995c778989deb08972081b19313303f8bfabb
Summary:
This is a big one. Moves all oss plugins to a new place and leaves
stub targets in place. No logic changes. Everything apart from
BUCK files should be unchanged.
Reviewed By: jknoxville
Differential Revision: D8951045
fbshipit-source-id: 8054fb4028181d5cc4a240b1908dab6471cf0a27
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:
Those hadn't been updated as part of the move and cause runtime
failures.
Reviewed By: priteshrnandgaonkar
Differential Revision: D8931211
fbshipit-source-id: bc874eeea39134d6da9e16f6771bf0d3d3c02473
Summary:
Important because we still run into soloader incompatibilities due
to the transitive dependency of Litho on Yoga on SoLoader. Sigh.
Reviewed By: priteshrnandgaonkar
Differential Revision: D8931213
fbshipit-source-id: 7e2de85deb5975dbe3f25e8145a9226d6684357c
Summary:
This partially fixes [#132](https://github.com/facebook/Sonar/issues/132)
Yoga.podspec and YogaKit.podspec are being removed from the private repository since now they exist in the CocoaPods master repository
Pull Request resolved: https://github.com/facebook/Sonar/pull/156
Reviewed By: passy
Differential Revision: D8890062
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 15ae1345c9816c1fff324cbdaff188f8ee521373
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:
Force device type from BaseDevice to AndroidDevice, because we need to access adb inside AndroidDevice.
In long term, we should use DeviceShell from BaseDevice, but that need much more changes.
Differential Revision: D8876082
fbshipit-source-id: 0772a0ac361c5e3eca9c7a590281ffa786501e15
Summary: SonarConnection should have an `error` function; this stubs out the mock to have this, allowing creation for tests.
Reviewed By: jknoxville
Differential Revision: D8878130
fbshipit-source-id: 9e0f45dac4ba31ee650dfd46dcee51207cc7a9b4
Summary: Move to xplat while ensuring that the buck target alias is still valid from fbandroid.
Reviewed By: priteshrnandgaonkar
Differential Revision: D8890129
fbshipit-source-id: 97ad8eac35780715e84a2620aae4e6ed566385c9
Summary:
:third-party doesn't actually export anything. So we don't need to
explicitly depend on it as it messes with the POM generation otherwise.
Reviewed By: jknoxville
Differential Revision: D8913636
fbshipit-source-id: d0da6ed4c47e8d6b7986ec9f12960c9323ad1640
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: Switches the tree to use the view hierarchy for Litho nodes rather than Litho component hierarchy since Accessibility services interact with the views rendered. Includes a few more properties in the accessibility sidebar and updates to the segmented sidebar based on derived/non-derived properties for all views. Also adds functions to the AccessibilityUtil to be able to work on the accessibility sidebar while still leaving the non-accessibility sidebar unchanged. Eventually the accessibility panel will be removed from 'normal' mode and the original functions will no longer be necessary.
Reviewed By: blavalla
Differential Revision: D8881739
fbshipit-source-id: 9ce37e8f18025538cba2c86c0895ee38d13d024b
